Комментарии 86
Хорошая статья
Могу только добавить, что этот факт
Добавлю, что обнаружение ошибок — это одна из основных задач, но не основная! Цель тестировщика — проверить, что ПО соответствует требованиям, работает как задумано и качественно выполняет свои задачи.
активно использую, когда собеседую QA. К сожалению, подавляющее большинство кандидатов именно ищет ошибки :(
Откуда это - даже сказать сложно. Но даже люди с претензиями на позиция лида не знают, зачем они вообще есть
подавляющее большинство кандидатов именно ищет ошибки
и правильно делают
Откуда это - даже сказать сложно
от Майерса, вестимо. Собеседующий лидов не читал Майерса?
Ну дайте почитать :)
Вообще грустно, оказывается, некоторые не только не знают, но и упорствуют в своем незнании
Я поясню. Поиск ошибок не имеет смысла в качестве цели, так как QA команда не отвечает на простой вопрос: софт выполняет требования или нет?
А если нет ответа на этот вопрос, то неясно,чего делать с текущим релизом. Можно идти в прод или нет.
Это вкратце. Поэтому тестировшики, которые идут не от требований, на соответствие которым надо проверять релиз, а ищут баги - просто занимаются не тем. Потому что пропускают требования и оказывается, что-то вообще не протестировано. Либо в релизе есть настолько очевидные баги, что аж стыдно, но QA искренне не понимает, а он тут причем. Я ж вон сколько нашел
Но ... я лично вас не нанимаю, можете и дальше искать баги
Это прелестно, нанимающий лидов не слышал об основных принципах тестирования, один из которых говорит о том, что тестирование демонстрирует наличие дефектов, а не их отсутствие
Видите ли, дя еще раз приведу абзац из статьи
Добавлю, что обнаружение ошибок — это одна из основных задач, но не основная! Цель тестировщика — проверить, что ПО соответствует требованиям, работает как задумано и качественно выполняет свои задачи
Обратите внимание, что использовано слово "ЦЕЛЬ".
И ЦЕЛЬ - это именно проверка на соответствие требованиям :)
А вот одной из ЗАДАЧ, для достижения ЦЕЛИ и является поиск ошибок. Хотя тоже не совсем. ЗАДАЧЕЙ является отработка тест кейсов, в результате которых могут быть найдены баги.
А ПРИНЦИП, на который вы сослались - говорит банально о том, что тестирование не гарантирует отсутствие ошибок, что и так понятно
---------------------
Но если вы не видите разницы между целью, задачей и принципом - мне будет сложно вам пояснить суть вопроса в рамках оьщения на данном ресурсе
О том, что тестирование не гарантирует отсутствия ошибок говорит другой принцип - заблуждение об отсутствии ошибок
А тот принцип говорит, о другом. Если взять конкретное требование - если уж собеседующему лидов так нравится это слово - расхождение выявленное в процессе его тестирования - или, по другому баг - вещь неоспоримая. Вот AR, вот ER и они различны. Т.е. мы уверенно говорим - баг есть!
Если же AR и ER в нашей проверке совпали - т.е. требованиет "проверено" - мы не можем сказать - бага нет!
Что касается целей - собеседующий лидов лихо машет шашкой и своим "определением" лихо лишает права на существование исследовательского тестирования, unit-тестирования, тестирования самих этих требований... etc
Я не совсем понял, почему вы до сих пор обсуждаете принципе в контексте целей?
Ну правда, вы не видите разницы между целью и принципом?
----------------------------
Про определение - я напомню, что требования бывают как функциональные, так и не функциональные. И QA валидирует решение на соответствие ВСЕМ требованиям
Поэтому установка такой цели никак не может ничего лишить права на существование
Более того, то что вы пишете, QA лид обязан явно учесть в тестовой стратегии, как факт, почему что-то надо делать или почему чего-то не надо делать
------------------------
Я вам поясню по простому. QA команда делает test report. Если в нем явно с самого верху не указана готовность релиза к выходу на следующий этап в виде списка требований, который валидированы и с каким результатом - он уже бесполезен от слова совсем. Потому что совершенно неясно что делать дальше всей команде
А уже потом можно написать, сикоко нашли багов, какой категории, сколько переоткрыли и все остальное
Вот к примеру так указано, что баги есть. Ок, допустим есть критические. Понятно, что дальше идти не стоит (я упрощаю). А если нет, но не ясно, чего тестили и что хотели тестить - ясно что ничего не ясно
Также когда вы идете от требований, вы думаете как их покрыть, какие тестовые данные собрать, какие тестовые системы подключить и т.д.
Здесь два принципиальных момента
1) Если багов нет - приложение пойдет на прод ровно в том самом виде, в каком и пришло в тестирование. Т.е. польза от тестирования даже не нулевая - она отрицательная, т.к. были затраты на это самое тестирование и задержка деплоя. Информация о том какое там у вас тестовое покрытие очешуенное и тесты зелёненькие - по большому счету никому не нужна - всем нужно рабочее приложение
2) Аббревиатура QA уже настолько набила аскомину нормальным пацанам от тестирования, что для неё уже начали придумывать всякие эвфемизмы - например, quality assistans. Потому что quality assurance - это вовсе не то, чем должен, будет, может заниматься нормальный тестировщик
всем нужно рабочее приложение
Все верно, но только это :)
Вот QA и нужны, чтобы это проверить. А чтобы проверить самих QA - надо хотя бы знать, что именно они делали, а что нет.
Но если QA ищет "баги", то вряд ли он тут помощник. Но я допускаю, что есть команды, где QA держать для других целей
Потому что quality assurance - это вовсе не то, чем должен, будет, может заниматься нормальный тестировщик
Ну, все в мире относительно. Как говорится, врач в психушке это тот, на ком халат.
Но отдельно взятый индивидум может решать, что он "наполеон".
Самые сложные баги, которые я исправлял, были прописаны в требованиях. Так что на мой взгляд, тестировщик должен не формально следовать спецификации, но и попутно её валидировать от имени пользователя.
Эээ, поиск багов это одна из целей тестирования. Если по факту приложение/сайт работает не как написано в требованиях, то это в основном квалифицируется как баг. Баги бывают и в требованиях. Помимо этого баги ещё нужно искать вне требований, так сказать.
Баги можно искать и даже найти и в продукте, который вообще не соответствует требованиям. Поэтому первоочередной целью является именно проверка соответствия продукта этим самым требованиям, что уже и включает в себя поиск дефектов. Но сам поиск дефектов - это одна из задач проверки соответствия, но не самоцель.
Насчет багов вне требований - да, но это вторичная задача, которую стоит делать уже после проверки соответствия требованиям и основных сценариев использования.
Что в ней хорошего?
Только ленивый не писал статью о мифах по тестированию, и это было еще актуально лет 10 назад.
Какие то мифы безусловно актуальны, но работать они никак не мешают, и перечислять их незачем
Это как спор о курице и яйце. Оба утверждения верны
1) цель тестирования, проверка соответствия требованиям (а как это проверить? правильно, читая требования и ища нескостыковки в реализации)
2) Цель тестирования - поиск багов (а как это проверить? правильно, читая требования и ища несостыковки в реализации)
Оба утверждения верны, нельзя считать ошибкой, если кандидат на собеседовании назвал то определение, которое вам меньше нравится.
При этом, лично мне нравится именно второе определение, что цель тестирования это поиск багов. Я объясню:
В первом утверждении говорится, что цель тестирования это проверка соответствия требованиям. Это подразумевает, что мы на первое место ставим именно требования, до буковки вчитываемся в него и досконально тестируем все кейсы, которые описаны в требованиях. В остальном, придумывание каких то других кейсов, выходящих за рамки требований, на втором плане и не так уж важны
Во втором утверждении, когда цель тестирования это поиск багов. Сразу подразумевается критическое мышление и к реализации и К ТРЕБОВАНИЯМ! Тут уже больше опираешься на знание продукта, знание его конечного пользователя и опираешься именно на это и тестирование начинается именно с поиска багов в самих требованиях. В данной парадигме требования это не конституция и не библия, на которую надо опираться и принимать за чистую монету. В данной парадигме требования это тоже часть нашего продукта, которая тоже скорей всего содержит какие то баги, несостыковки, функционал, неудобный для конечного пользователя
Поэтому, у меня мнение отличное от вашего. Я думаю, чем выше уровень тестировщика, тем больше он должен быть нацелен на поиск ошибок (опираясь на знание конечного пользователя), а не тупо брать за чистую монету требования и проверять соответствие реализации
Поясню :)
Готовность релиза к проду == соответствие требованиям и принятие заказчиком тех багов, которые есть здесь и сейчас
Знание того, что найдено и типа исправлено 100500 никакой подсказки на тест идти или нет в прод не дает
Прэтому люди, которые ищут баги не могут в принципе выполнять функцию "контроля качества". Мнение об их особой гениальность, так как они творчески и абсолютно никому не надо могут выискивать что-то там - ложно
------
Теперь про тупо брать требования :) Суть в том, что для того чтобы разложить требования на действия для проверки решения на соответствие им нужна как раз высокая квалификация
Если требование функциональное - вам надо подумать, какие тестовые данные взять, проанализировать зависимости, выписать тест кейсы и т.д.
Если не функциональное, к примеру "система должна поддерживать не менее 1000 пользовательских сессий", то одна такая строчка открывает целый фронт работ и знаний
А искатели багов обычно просто чего-то находят и радуются, пока прод не завалится парк ращ и им наваляют вербально, а может и не только
------
Ваша ошибка в том, что в требованиях не прописаны ВСЕ тест кейсы. Это задача вашей команды их выписать и придумать, как эффективно их пройти, а если вы не можете - ну сорян :)
Да не торопитесь вы так, месье, уже заговариваться начали
А здесь у нас будет третий принцип, о котором наполеоны мценского уезда конечно не слышали - исчерпывающее тестирование невозможно
А здесь у нас будет третий принцип, о котором наполеоны мценского уезда конечно не слышали - исчерпывающее тестирование невозможно
Конечно, но к этому нужно стремиться, а не искать баги там где нравится :)
Просто есть те, кто делает работу там где надо, а есть те, кто делает то что хочет и там где проще/интереснее
На работу лучше брать первых, а не "творческих" вторых :)
---------------
А вы уже осознали разницу между "принципом", "целью" и "задачей"? Или просто решили, что это все одно и тоже?
ISTQB CTFL Syllabus Версия 2018
1.1.1 Основные цели тестирования
...
Обнаружение отказов и дефектов
...
Не благодарите меня, месье
1.1.1 Typical Objectives of Testing For any given project, the objectives of testing may include:
• To prevent defects by evaluate work products such as requirements, user stories, design, and code
• To verify whether all specified requirements have been fulfilled
• To check whether the test object is complete and validate if it works as the users and other stakeholders expect
• To build confidence in the level of quality of the test object
• To find defects and failures by reducing the level of risk of inadequate software quality
• To provide sufficient information to stakeholders to allow them to make informed decisions, especially regarding the level of quality of the test object
• To comply with contractual, legal, or regulatory requirements or standards, and/or to verify the test object’s compliance with such requirements or standards
Но вы как то, если уж ссылайтесь, но стоит это делать на языке оригинала и полностью
Мне перевести некоторые моменты, или не надо?
ISTQB-CTFL_Syllabus_2018_v3.1.1 - если что, взято отсюда
Еще раз поясню. У вас почему то мышление как у джуна или мидла, что для вас "готовность релиза к проду == соответствие требованиям".
Такая установка как у вас приемлема, только если вы работаете в компании, которая занимается аутсорсом тестирования. То есть, приходит какой то внешний заказчик, приносит вам требования и ваша задача протестировать продукт по этим требованиям и отдать его заказчику. А что уж дальше происходит с продуктом вам пофиг, вы перекидываете ответственность на того, кто вам требования дал
Если вы работаете в обычной компании, которая не аутсорсом занимается, а сама придумывает/разрабатывает/тестирует/поддерживает продукт, то для такого тестировщика главной целью должно быть не "лишь бы требования соблюсти и в прод выкинуть", а цель должна быть в разработке качественного продукта
Может на написание этих требований поставили джуна аналитика, а я тестировщик с 10 летним опытом и глубоким знанием своего продукта и своих пользователей? а может опытный аналитик, но писал требования после жесткого запоя?
Цель хорошего тестировщика не требования формально соблюсти, а выпустить качественный продукт (для чего вообще придется потрудится и сначала все баги из требований вычистить)
У вас почему то мышление как у джуна или мидла, что для вас "готовность релиза к проду == соответствие требованиям".
У меня мышление человека, которого потом спросят за "выход в прод" :)
А требования, как раз и определяют что есть "качество". Поэтому залог успеха, это понять что надо сделать и это сделать, с соблюдением. в том числе нефункциональных требований. Котроые тоже написать для себя заранее
Видите ли, вы пишете про "качество"
Цель хорошего тестировщика не требования формально соблюсти, а выпустить качественный продукт
но что это в вашем понимании? "Мамой клянусь"? Как-то маловато. "не нашел за два дня новых багов?" - тоже нет :)
Получется, для вас (как минимум вы то не расписали), качество - это нечто такое, что получается само по себе, надо просто поискать баги. А вот и нет. Задача QA покрыть требования и удостовериться что они выполнены. Иначе у вас нет точки отсчета этого качества.
----------------
И да, если вы, покрывая требования, увидели в них косяки или противоречия, о которых сообщили команде - значит вы хорошо выполнили свою предварительную работу.
А если вы этого не увидели, либо увидели но не сказали - то вы тогда и предварительную часть в виде анализа требований выполнить не можете :)
Цель хорошего тестировщика не требования формально соблюсти, а выпустить качественный продукт
И еще, по этому же самому месту. Вы не путайте "свою шерсть с государственной". Задача "выпустить качественный продукт" - это задача ВСЕЙ команды, а не группы QA. Не надо брать на себя общее, сорян. Вы, как QA, отвечаете четко за проверку этого качества на конечном этапе. И если окажется, что не проверили, то к вам будет первый вопрос "почему не увидели". А потом и по цепочке к остальным, девам и аналитикам, возможно к архитектору.
Это очень хитрый прием, размазывать свою личную ответственность в общей и заявлять, что мы как QA отвечаем за качественный продукт. Не-не-не, только за проверку. А чтобы проверить, надо знать, как качество выглядит, как его померять и сравнить с ожидаемым
--------------------
Поэтому, если будет баг на проде, то каждый будет разбюираться в своем направлении, почему БА не описал, ДЕВ не сделал, а QA - не нашел. И если, к примеру, окажется, что требование было, то как минимум BA отскочил, а вот лиды DEV и QA могут приготовиться думать, как делать так, чтобы не вышло в следующий раз
Вы почему то под целью тестирования "найти баги" подразумеваете, что тестировщик не будет вообще смотреть требования, а будет как обезьянка тыкать кнопки рандомно, лишь бы что то сломать
На самом деле, при собеседовании, если так человек ответил про цель, то не валить его надо, а задать уточняющий вопрос, что он под этим подразумевает и как он баги искать будет
Если это не совсем зеленый джун, то он вам правильно ответит, что "найти все баги" - это значит обеспечить так, чтобы наш продукт полностью соответствовал требованиям, а так же запросам пользователей (это например, если видите косяк в требованиях или знаете, как улучшить пользовательский опыт, то с предложением об улучшении идете к вышестоящему)
Так что, цели "обеспечить соответствие требованиям" и "найти все баги" это одно и тоже, но только разное настроение у этих определений.
Проверить соответствие требованиям - более позитивное определение, которое подразумевает, что у нас все отлично все работает и всего лишь надо проверить, что отрабатывает корректно по требованиям
Найти все баги - негативное определение, которое сразу уже настраивает тестировщика на то, что в нашем продукте баги точно есть и их нужно лишь найти. Для этого надо вычитывать требования и тщательно искать несоответствия
Последнее определение лично мне больше нравится, так как более настроено на плодотворную работу. Хотя, как я и писал уже много раз, оба определения по смыслу означают одно и тоже: проверка соответствия требованиям. Отличие лишь в том, с каким настроением к этой работе подойдем
Вы почему то под целью тестирования "найти баги" подразумеваете, что тестировщик не будет вообще смотреть требования, а будет как обезьянка тыкать кнопки рандомно, лишь бы что то сломать
Если вы ставите цель "проверить на соответствие требованиями", то автоматически эта цель достижима если достижимы цели:
"требования известны"
"требования полны"
"требования непротиворечивы"
"требования покрыты тест кейсами"
"тест кейсы пройдены"
Понятно список целей "второго" уровня может быть дополнен, но уже тут понятно, что главная цель достижима только если те, что я указан также достижимы при правильной методике тестирования.
На самом деле, при собеседовании, если так человек ответил про цель, то не валить его надо, а задать уточняющий вопрос, что он под этим подразумевает и как он баги искать будет
Вот даже в этой фразе видно, что не с той стороны вы хотите есть слона. задачи искать баги нет от слова совсем. Тестировщик идет от требований и проверяет выполнение требований. Баг - это негативный результат проверки соответствия, который можно воспроизвести
"найти все баги" - это значит обеспечить так, чтобы наш продукт полностью соответствовал требованиям
Прикол в том, что требования конечны, а баги нет. И когда мы идет от требований, то критерий "готовности продукта" является КОНСТРУКТИВНЫМ. Т.е. есть список требований, они покрыты тестами и проверены. Что такое все баги - совершенно неконструктивное определение. Вот как поймете, что все баги найдены? Ответ, никак.
Важно, чтобы задача ставилась и измерялась конструктивным образом и тогда будет понятно. как ее делать
Последнее определение лично мне больше нравится, так как более настроено на плодотворную работу. Хотя, как я и писал уже много раз, оба определения по смыслу означают одно и тоже: проверка соответствия требованиям.
А мне надо, чтобы он был настроен на полноту :) Потому что второй подход никак не защищает от того, что что-то будет забыто вообще. Не надо настраиваться, что там есть баги. надо настроиться на то, чтобы проверить ВСЕ и НИЧЕГО не забыть.
Т.е. именно психологически есть сосиску с правильной сторооны, откуда она конечна.
ну вы же сами в конце пишете: "Надо настроиться на то, чтобы проверить ВСЕ" и при этом пишите, что задача найти ВСЕ баги вас не устраивает, так как она не конечна.
А разве "проверить ВСЕ" конечная задача? Нет, проверить ВСЕ не возможно, так как вы, как минимум, не сможете воспроизвести все комбинации железа и программного обеспечения, которые будут у пользователей на компьютерах и которые могут повлиять на работоспособность разработанного продукта
"
Если вы ставите цель "проверить на соответствие требованиями", то автоматически эта цель достижима если достижимы цели:
"требования известны"
"требования полны"
"требования непротиворечивы"
"требования покрыты тест кейсами"
"тест кейсы пройдены"
"
Тоже самое будет, если поставить цель "Найти баги". Как человек найден баги, если у него нет требований? Скорей всего никак. Для оформления бага надо знать ожидаемый результат.
А для того, чтобы получить ожидаемый результат, надо чтобы требования были известны, полны, непротиворечивы. Если какие то в голову приходят идеи/улучшения/критика текущего функционала/интерфейса, это доносится аналитику и если аналитик согласится и внесет это в требования, тогда они так же тестируются
Как я уже писал, цель "проверить соответствие требованиям" - слишком узкая и вот она как раз таки не подразумевает, что требования должны быть полными.
К примеру, у вас есть сайт, на который пользователи заходят, загружают картинку с компьютера и она сохраняется в базе с тем именем, с которым загружено.
Требования звучат так: нельзя загружать картинку, если в базе уже есть картинка с таким именем.
Если идти с целью "проверить соответствие требованиям", то достаточно нескольких кейсов, например: а) в базе нет картинки с таким именем, значит загрузить новую можно б) в базе есть картинка с таким именем, загрузить новую нельзя.
В целом, требования проверены, можно отдавать в прод
Если идти с целью найти баги, то естественно надо первые кейсы два проверить (когда картинка есть и картинки нет). А раз подошли к задаче уже с критическим настроем, то сразу в голову приходят мысли о том, как можно это все сломать и где разраб накосячить мог.
Например, что будет, если два пользователя начали одновременно загружать картинки с одинаковым именем? Или например, я по опыту знаю, что в начале и конце строк обычно обрезаются лишние пробелы, а не накосячил ли с этим разраб?
и что вообще имел ввиду аналитик под фразой "с таким же именем"? а если регистр разный? а если загрузка с разных устройств/браузеров, на которых разная кодировка? а если в названии вставится какой то спец символ, который поломает проверку? а не накосячил ли разраб с проверкой пустых имен и файлов с названием null.[расширение]
ну вы же сами в конце пишете: "Надо настроиться на то, чтобы проверить ВСЕ" и при этом пишите, что задача найти ВСЕ баги вас не устраивает, так как она не конечна.
Конечно нет, потому что каждый найденный баг предпоследний, а вот требования конечны :)
Тоже самое будет, если поставить цель "Найти баги". Как человек найден баги, если у него нет требований? Скорей всего никак.
А вот в этом и есть сомнения, так как цель "найти баги" неконструктивна и не измеряема в контексте прогресса в ее достижении. А если так, то и планирование тестирование скорее всего невозможно
Да и в целом, мне вообще баги не интресуют :)
Как я уже писал, цель "проверить соответствие требованиям" - слишком узкая и вот она как раз таки не подразумевает, что требования должны быть полными.
Зато выполнима и достаточна :) И "поиск багов" вне эой цели можно делать бесплатно ради собственно "развития". Про неподразумевает - вот поэтому то я к таким кандидатам отношусь подозрительно. Если ставится цель "проверить на соответствие требованиям", но как цель следующего уровня не ставится цель "убедиться что требования известны, полны и непротиворечивы" - то это уже практически клиника.
Ну как можно проверять на соответствие тому, что не знаешь, либо противоречиво?
Например, что будет, если два пользователя начали одновременно загружать картинки с одинаковым именем?
А у вас и так на столе есть требование "многопользовательского режима" :) Просто ваш пример все лиш означает проверку того, что два требования выполняются совместно. А теперь собираем все такие сочетания и думаем :)
Прикол как раз в том, что требования не должны проверяться только независимо от других требований. И еслти для вас факт того, что иногда надо из проверять "совместно" - это уже "высшая математика тестирования", то как вы понимаете - это грустно
а если регистр разный? а если загрузка с разных устройств/браузеров, на которых разная кодировка? а если в названии вставится какой то спец символ, который поломает проверку? а не накосячил ли разраб с проверкой пустых имен и файлов с названием null.[расширение]
Вот и прекрасно. Вы проверили кучу edge cases, которые могу и не случиться примерно никогда, но куда важнее проверить на совметимость браузеров, ресайзинг окна и вообще разные устройства, размер картинки, а картинки ли это.
А вот чтобы это проверять, надо выписать себе требования на совместимость, кроссплатформенность, безопасность и ограничения
И ещше много чего. И потом тестить.
И уже потом, если будет время, поиграться с вашими примерами
Вот поэтому "искатели багов" пусть ищеть баги, а QA - пусть проверяю на соответствие требованиями
не не не, .вы со своими проверками на ресайзинг окна, на размер картинки, на формат картинки ушли уже не туда.
Для простоты я привел пример только одной конкретной строчки требований на уникальность имени файла, которую вам надо проверить. Вот у вас есть требование:
Если в базе данных уже есть картинка с таким именем, то загружать картинку новую нельзя (для простоты даже опустим требования к ошибке. Просто она должна быть в каком то виде, вам надо именно протестировать уникальность)
Объясните на этом конкретном примере, в чем именно будет отличие работы двух разных тестировщиков с целью проверки соответствия требованиям и с целью найти баги? в чем отличие подходов? в чем отличие кейсов? в чем отличие результатов тестирования? ну и самое главное, по вашему мнению, в чем минус цели по поиску багов?
Как я писал уже, лично по моему мнению отличие тут именно в "настроении", один подход более позитивный, другой более негативный по настрою. Но суть и результат тестирования будут одинаковыми
Если в базе данных уже есть картинка с таким именем, то загружать картинку новую нельзя (для простоты даже опустим требования к ошибке. Просто она должна быть в каком то виде, вам надо именно протестировать уникальность)
Смотрите, вы осознанно не хотите понять суть "тестирования на соответствие требований". И лишний раз показываете, почему люди которые так думают, не могут быть наняты, как минимум на позицию лида (которых я собеседую).
Как обычный QA - бог с ним, лид нанял и пусть сам с ним панькается
В реальном проекте так не бывает. Всегда есть нефункциональнгеы требования, а также другие требования, которые вступают во взаимодействие с конкретным требованием. Как только появился браузер, сразу ОБЯЗАНЫ возникнуть вопросы на тему:
кроссбраузерной поддержки
совместимости с устройствами разных типов
безопасности (вы даже не написали, требуется ли авторизация/аутентификация для загрузки файла)
Поэтому, В ЛЮБОМ случае даже одно ваше требования должно быть дополнено тем, что я написал
И в этом разница. Задача QA
выписать для себя требования, даже те, которых не написано явно
определиться со стратегией тестирования
и дальше согласно стратегии тестировать
Ваша задача идет на уровень обычного теста на знание методики покрытия тест кейсами, проще говоря на "повыпендриваться". Но цель таких задач на собесе именно проверить кругозор.
Если кандидат замыкается на функуциональном тесте - это говорит о его низком потолке, по сути - это начальный уровень джуна, который может превратится в уровень миддла, если окажутся в наличии тех. знания (что бывает крайне редко)
==============
По вашему подходу я могу все проверить, но потом кто-то откроет сайт з загрузкой файла на мобильном и все ... все получат люлей. Или загрузит вместо картинки что-то дай бог не зловредное
И в этом разница, так как тестер, начиная от требований должен покрыть все (либо не все, но получив люлей исправится), а "искатель багов" просто потратит денбги проекта, чтобы заказчик нашел очевидный баг, который тот просто не принял во внимание, так как был занять выдумыванием 100500го кейса к уже известного ему требования
Вот вы сейчас сами всё с ног на голову перевернули =D
До этого вы писали, что при "проверке на соответствие требованиям" тестировщик должен четко проверить соответствие требованиям и четко по ним проверить все кейсы, а при цели "найти баги" тестировщик будет тратить время команды на то, что вообще в требованиях не описано и цель "найти баги" не достижима, так как она не конечна
Сейчас же, когда я попросил на конкретном примере показать отличие этих подходов, вы написали: "с целью проверки соответствия требованиям тестировщик должен будет покрыть ВСЁ, а не только то требование которое у него есть. А искатель багов будет топтаться с известным ему требованием и 100500 кейсов на это требование придумывать" =D
Давайте уж определимся на конкретном примере, кто у нас по требованиям идет, а кто не по требованиям, у кого конечная цель, а у кого нет
Сейчас же, когда я попросил на конкретном примере показать отличие этих подходов, вы написали: "с целью проверки соответствия требованиям тестировщик должен будет покрыть ВСЁ, а не только то требование которое у него есть.
Я просто еще раз процитирую себя
Если вы ставите цель "проверить на соответствие требованиями", то автоматически эта цель достижима если достижимы цели:
"требования известны"
"требования полны"
"требования непротиворечивы"
"требования покрыты тест кейсами"
"тест кейсы пройдены"
Сорян, но ... ну если вы не читаете, зачем пишете?
Вот ответ на ваш вопрос, если вы перед тестированием не проверили полноты - как лид вы получаете жирнейший неуд
и еще раз повторюсь, вы сами действуете как искатель багов, а не как человек, который проверяет соответствие требованиям
Я вам дал четкую строку требований на уникальность имен и вы не кинулись на проверку соответствия требованиям, а критически отнеслись к ним и сразу же выдали два кейса с возможными багами (загрузка с мобилок, загрузка файла другого формата) и сразу же как искатель багов начали предъявлять претензии к этим требованиям
Скорей всего, как опытный тестировщик, вы бы пошли к аналитику с перечнем узких мест, которые вы видите в функционале и которые не описаны в требованиях: различные устройства и браузеры, кодировка, многопоточная загрузка, загрузка файлов другого формата и тд.
То есть, типичный искатель багов это тот, кто еще на момент прочтения требований уже видит возможные проблемы
и еще раз повторюсь, вы сами действуете как искатель багов, а не как человек, который проверяет соответствие требованиям
Давайте не навешивать ярлыки :)
Тем более я явно "предложил" сделать step back, и сначала определить все требования, их непротиворечивость, а пот ом уже писать тест кейсы
Я еще раз приложу свою же цитату
Если вы ставите цель "проверить на соответствие требованиями", то автоматически эта цель достижима если достижимы цели:
"требования известны"
"требования полны"
"требования непротиворечивы"
"требования покрыты тест кейсами"
"тест кейсы пройдены"
Где вы тут видите "критически отнеслись к ним и сразу же выдали два кейса с возможными багами"?
Я вам выдал те ТРЕБОВАНИЯ, которые необходимо ДОУТОЧНИТЬ перед началом тестирования. В любом случае
Мы еще в вашем примере (точнее я) бесконечно далеки от написания тест кейсов
"По вашему подходу я могу все проверить, но потом кто-то откроет сайт з загрузкой файла на мобильном и все ... все получат люлей. Или загрузит вместо картинки что-то дай бог не зловредное "
И ваш последний абзац вас и выдал, вы сами идете по цели "поиска багов", а не просто "проверка соответствия требованиям"
И ваш последний абзац вас и выдал, вы сами идете по цели "поиска багов", а не просто "проверка соответствия требованиям"
Это просто жизненные ситуации, когда "искатели багов" пропускают очевиднейшие ошибки, так как просто не тестировали это вообще
А причина в том, что не проверяли требования на полноту
А способ этого избежать - именно проверка на полноту
"требования полны" - точно так же недостижимая цель, как и "найти все баги"
Чтобы требования были полны, в них должны быть описаны ожидаемые результаты вообще всех кейсов, которые вы только придумаете. Включая, поведение на ресайз окна, описание всех сочетаний конфигураций, где обязательно должен работать функционал и тд и тп
Если у вас требования полны и покрывают ВСЕ возможные кейсы, то количество кейсов для проверки соответствия требований будет точно такое же, как у тестировщика цель которого найти все баги, а значит и качество тестирования и количество найденных багов и время тестирования, все будет абсолютно одинаковое при обоих подходах. То есть вывод такой , как я и писал, это абсолютно одинаковые по смыслу цели тестирования, отличается только общий настрой подхода к задаче
Как я в самом своем первом сообщении писал "Во втором утверждении, когда цель тестирования это поиск багов. Сразу подразумевается критическое мышление и к реализации и К ТРЕБОВАНИЯМ! Тут уже больше опираешься на знание продукта, знание его конечного пользователя и опираешься именно на это и тестирование начинается именно с поиска багов в самих требованиях. В данной парадигме требования это не конституция и не библия, на которую надо опираться и принимать за чистую монету. В данной парадигме требования это тоже часть нашего продукта, которая тоже скорей всего содержит какие то баги, несостыковки, функционал, неудобный для конечного пользователя "
"требования полны" - точно так же недостижимая цель, как и "найти все баги"
На самом деле нет
Нефункциональные требования конечны, если вы конечно обладаете соответствующим бэкграундом. Если нет - ну тогда давайте на этой точке закончим
Функциональные же дополнются edge cases и негативными, и тут как раз работает ваш пример, но он лиш частично закрывает вопрос полноты
Психологически, раз уж вы хотите идти в этом направлении - то как раз важно сосредотачиваться сначала требованиях, и уже потом, согласно стратегии покрывать фичи тест кейсами и сценариями.
"Это просто жизненные ситуации, когда "искатели багов" пропускают очевиднейшие ошибки, так как просто не тестировали это вообще "
дак кто в итоге больше багов пропустит, тот у кого цель "НАЙТИ ВСЕ БАГИ" или тот, у кого цель просто проверить соответствие требованиям? =DD
вы помоему начинаете уже защищать тех, кто ищет все баги, а не кто только соответствие требованиям проверяет
дак кто в итоге больше багов пропустит, тот у кого цель "НАЙТИ ВСЕ БАГИ" или тот, у кого цель просто проверить соответствие требованиям?
Я не знаю, зачем вы пытаетесь перекрутить. Суть "поиска багов" в прохождении тестовых сценариев/кейсов, который покрывают требования. По сути поиска багов нет от слова совсем
Это если упростить :)
Но если требования в голове тестировщика не полны, но значит они не покрыты кейсами, значит не протестированы, значит ВЕРОЯТНОСТЬ того, что там будут баги намного выше
Так понятнее?
Вы пишите лучше на конкретных примерах, в чем подход с поиском всех багов хуже, чем подход с проверкой соответствий требованиям. Иначе, в одном сообщении пишите, что плюс проверки соответствий требованиям - быстро проверил и отправил в прод, а искатель багов будет 100500 кейсов придумывать помимо требований и долго тестировать все кейсы
То пишите, что при проверке соответствий требованиям тестировщик обеспечит полноту требований и проверит ВСЕ кейсы, а искатель значит кучу кейсов вообще пропустит и много чего не станет проверять
Вот мой конкретный пример, только не уходите в демагогию, а постарайтесь его разобрать:
Есть сайт по покупке неких вещей, вам нужно протестировать кнопку "Оформить заказ". Аналитик вообще бешеный, на 50 страницах вордовского файла описал вам самые полные требования к этой кнопке: ее название, РАЗМЕР, ее поведение, все комбинации железа и ПО, где эта кнопка корректно должна отрабатывать. В общем, самые исчерпывающие требования.
И есть два тестировщика, которые по этим требованиям протестировали вообще ВСЕ кейсы, какие только возможно придумать.
По требованиям все отлично, все кейсы проходят, требования полны и полностью соблюдены.
Первый тестировщик, цель которого проверка соответствия требованиям, закрывает задачу и отпускает в прод
Второй тестировщик "искатель багов", понимает, что по требованиям все отлично и работает, НО при разрешениях экранов более 2К кнопка такая маленькая, что скорей всего каждый второй пользователь будет промахиваться, психовать и, условно, каждый сотый будет просто закрывать сайт и не оформлять из за этого заказ. Так как он искатель багов, он даже такой мелкий вроде бы баг заводит (хотя полностью соответствующий требованиям, так как размер кнопки прописан) и идет к вышестоящим разбираться, не наделали ли мы ерунды и точно ли такое надо в прод релизить??
Вот какой подход вам лично ближе, проверка соответствия требованиям или искатель багов? и какого из этих тестировщиков вы хотели бы к себе в команду?
Сразу напишу, что у первого тестировщика тоже есть плюс в том, что он проверил полноту требований и проверил кейсы и при этом не стал тратить время на визит к вышестоящему по поводу субъективого восприятия удобства кнопки. Место тоже такому тестировщику есть. Если потом что то не так пойдет в проде, будет отток клиентов, то получит за это аналитик, который размер кнопок написал
Второй тестировщик "искатель багов", понимает, что по требованиям все отлично и работает, НО при разрешениях экранов более 2К кнопка такая маленькая
Требования к usability также являются таковыми, которыми надо будет дополнить уже написанные :)
Поэтому первый также это проверит и заявит :)
Видите ли, ваш пример идет от того, что вы НЕ ВЫПОЛНЯЕТЕ работу про проверке полноты, а поэтому ... ну вы не очень понимаете, как это работает.
Т.е. вы опять СОЗНАТЕЛЬНО пропускаете момент, когда QA ДОБАВЛЯЕТ в требования для себя то, что не написано. Не важно, сколько написал аналитик, 50 страниц или одну фразу.
Пока проверка на ПОЛНОТУ не прошла - нельзя идти дальше.
Но если вы этого не делаете или не понимаете, а это очевидно из цитаты
Первый тестировщик, цель которого проверка соответствия требованиям, закрывает задачу и отпускает в прод
Т.е. я вам уже могу наверное в пятый раз проциттировать сам себя
Если вы ставите цель "проверить на соответствие требованиями", то автоматически эта цель достижима если достижимы цели:
"требования известны"
"требования полны"
"требования непротиворечивы"
"требования покрыты тест кейсами"
"тест кейсы пройдены"
Но вы все равно скатываетесь в тест по написанному аналитиком, пропуская выделенный пункт :)
Я не могу вам помочь, пока вы сами не поймете, что надо делать на выделенном пункте. И ваш пример как раз показывает, что нет, не понимаете :(
Сразу напишу, что у первого тестировщика тоже есть плюс в том, что он проверил полноту требований
У вас ошибка тут. Проверка на полноту - это не только проверка того, что написано в сторке или ТЗ. Это дополнение, можно только для себя. К примеру, вы можете не требовать аналитика вписать эти требования, но отметить что использованный компонент не соответствует дизайн гайдам платформы либо бренд буку клиента и зарегать баг на эту тему.
Конструктивно в вас может быть свой check list, который условно дополнительно применяется под конкретную технологию и обеспечивает полноту по "общим" требованиям или таким, что подразумеваются неявно. И не обязательно пинать аналитика в данном случае, так как понятие юзабилити сложно формализуемо.
Оно просто есть и все
=D
"К примеру, вы можете не требовать аналитика вписать эти требования, но отметить что использованный компонент не соответствует дизайн гайдам платформы либо бренд буку клиента и зарегать баг на эту тему
Конструктивно в вас может быть свой check list, который условно дополнительно применяется под конкретную технологию и обеспечивает полноту по "общим" требованиям "
ЕЩЕ РАЗ, дак ЧЕМ же тогда по вашему отличается цель "проверка соответствия требованиям" и цель "найти все баги"?
Причем, по вашим же словам, в проверке соответствия требований - требования не настолько уж обязательны, не все требования аналитика просить добавить, а юзабилити вообще трудно описуемо в требованиях и юзабилити баги как то по наитию надо искать?
При этом, цель "найти все баги" для вас настолько плохая, что вы готовы даже с сеньором попрощаться, если он ее озвучит. ХОТЯ, "найти все баги" точно так же подразумевает, что нам известны все требования. Иначе цель не достижима, так как не зная требований вы все баги и не найдете
Или, все таки, как я вас пытаюсь убедить, цели тестирования эти абсолютно одинаковые и влияют только на общий настрой? Может лучше вместо пустого вопроса про цель тестирования спросить, какие кейсы, в каком порядке и почему именно так собеседуемый будет тестировать?
ЕЩЕ РАЗ, дак ЧЕМ же тогда по вашему отличается цель "проверка соответствия требованиям" и цель "найти все баги"?
Есть контроль полноты требований и traceability. Если требования полны и без противоречий, они покрываются кейсами и в обратную строну можно проверить что все покрыто, значит кейсы тоже полны.
Конечно, какой-то edge case может быть пропущен (никто не идеален), но как минимум четко понятно, как покрыты требования
Поэтому задача конечна и может быть контруктивно спланирована, проконтролирована и выполнена
Когда "ищутся баги" - как проверить полноту?
Давайте я так попробую: полнота
При этом, цель "найти все баги" для вас настолько плохая, что вы готовы даже с сеньором попрощаться, если он ее озвучит
Конечно, так как она неконструктивна и не может быть разбита на дочерние цели.
ХОТЯ, "найти все баги" точно так же подразумевает, что нам известны все требования
Нет, но вы по ходу не поймете. Я уже пытался вам пояснить, что список требований конечен, а список багов - нет. Но ... тут либо есть понимание разницы между конечным и бесконечным множествами, либо нет
Может лучше вместо пустого вопроса про цель тестирования спросить, какие кейсы, в каком порядке и почему именно так собеседуемый будет тестировать?
Можно, но для этого надо уметь написать тестовую стратегию, которая в свою очередь предполагает умения собрать требования, чтобы под них определиться с покрытием, методами и т.д.
А обычно, если кандидат не понимает базы, то от решения задачи разработки тестовой стратегии он бесконечно далек.
В вашем случае, если вы сами спросите себя, как вы пишете этот документ, но будет довольно таки интересно, как вы обошли момент проверки требований на полноту и непротиворечивость
Вот мне правда стало интересно, как вы это делаете
Еще раз напишу то, о чем писал 10 минут назад.
"Цель - проверка соответствия требованиям узкая и имеет место быть, только когда вы реально открываете требования, четко по ним идете и сверяете все кейсы.
Как только вы вышли ЗА рамки требований (проверяете полноту требований, тестируете то, что не описано в требованиях, тестируете сами требования) - вы уже не "проверяете соответствие требований", а искатель багов "
Так вот, как вы проверяете полноту требований?? Вы действуете как искатель багов, ищите узкие места системы, потенциально опасные/сложные кейсы, функционал вообще не описанный в требованиях и тд и на основе этого добиваетесь полноты требований
И дальше, когда все требования полны, нормально описаны и сами не содержат ошибок - тут, что "проверяльщик соответствия требованиям", что "искатель багов" будут проверять одни и те же кейсы, которые в требованиях описаны. Отличий никаких
Так вот, как вы проверяете полноту требований?? Вы действуете как искатель багов, ищите узкие места системы, потенциально опасные
Нет конечно. Надо уточнить, к примеру, какая ожидается пользовательская нагрузка? Какие требования к безопасности? Какие требования к доступности?
В целом, я вам уже писал - тут требуется технический бэкграунд, чтобы такие требования понимать и, что еще более важно, значть что не написано, чтобы задать вопросы
К примеру у меня по одному из проектов опросник по нефункциональным требованиям занял 200 строк. Т.е. 200 требований, которые были верифицированы с заказчиком
Но я по должности хочу к закачику напрямую, тестировщик понятно эти вопросы может задать по ходу разработки тестовой стратегии
------------------
И вы мне не ответили на вопрос "как вы пишете тестовую стратегию, не собрав требования и не убедившись в их полноте"? Мне кажется без ответа на этот вопрос сложно идти в разговоре дальше
сбор требований, проверка полноты требований, тестирование самих требований - все это выходит за рамки вашей задачи по проверке соответствия требованиям.
Проверка соответствия требованиям - это когда вам приносят готовые требования и задача только проверить соответствие. Все остальное, выходящее за рамки, является поиском багов (либо можете новое определение придумать)
Лично у меня проверка соответствия требованиям это уже заключительный этап, а первый - самый сложный и самый ответственный, это тестирование требований (что к проверке соответствия требованиям не имеет отношения)
Давайте проще
вы в какой момент пишете тестовую стратегию относительно действий над "требованиями"?
начинаете ли вы тесы до написания тестовой стратегии?
Ну и для примера, как вы поступите, если нет требований по безопасности, отказоустойчивости, производительности. Забьете, будете искать баги, или просить дать требования?
Цель - проверка соответствия требованиям узкая и имеет место быть, только когда вы реально открываете требования, четко по ним идете и сверяете все кейсы.
Как только вы вышли ЗА рамки требований (проверяете полноту требований, тестируете то, что не описано в требованиях) - вы уже не "проверяете соответствие требований", а искатель багов
Цель - проверка соответствия требованиям узкая и имеет место быть, только когда вы реально открываете требования, четко по ним идете и сверяете все кейсы.
О-о-о, ну наконец-то
Вот тут и ошибка, вы все равно сначала добавляете требования, а потом их проверяете
Вы не можете выйти за рамки требований от слова совсем :)
а теперь перечитайте мой самый первый комментарий, в котором написано, что "искатель багов" и цель "проверка соответствий требованиям" - это по сути в практике одно и то же, отличается лишь настроем, с которым подходим к этому тестированию
А если уж вы так любите к людям придираться на собеседованиях и очень хочется разделить эти два понятия, то:
Цель тестирования "проверка соответствия требованиям" - четко сформулированная конкретная фраза, которая говорит нам о том, что нужно просто взять готовые требования и по ним проверять соответствие реализации
Эта конкретная цель не подразумевает, что "вообще то надо сначала требования сами тестировать", "вообще то надо за рамки требований выходить и не все туда в требования писать", "вообще то надо юзабилити и подобное без требований как то по наитию тестировать и баги писать. Это все ваши уже придумки и вы такими придумками четкую поставленную задачу "проверить соответствие требованиям" превращаете в "поиск всех багов" (и в реализации и в самих требованиях)
четкая поставленная задача - проверить соответствие требованиям, вполне подходит на уровень джуна и мидл-. Там нужно всего лишь взять готовые требования и, даже не сильно еще погрузившись в продукт, можно по самим требованиям накидать кейсов и чисто по ним пройтись. Там не требуется что то от себя придумывать, пытаться аналитика подловить на сложных кейсах, тут достаточно не пропустить кейсы и полностью покрыть требования
Цель найти все баги, уже подходит больше для мидл+ и синьора, так как подразумевает не только четкую задачу "взять и проверить соответствие", а более обширную задачу с тестированием самих требований и выход за рамки требований (как в юзабилити например)
Цель тестирования "проверка соответствия требованиям" - четко сформулированная конкретная фраза, которая говорит нам о том, что нужно просто взять готовые требования и по ним проверять соответствие реализации
Ну блин, вы таки сознательно пропускаете
Давайте на примере. Ну как вы можете. к примеру, проверить соответствие решения требованиям безопасности, не получив эти требования
Ну к примеру, нет требований. Что дальше? Ну какие вы баги будете искать?
Понятно, можно найти совсем уж тривиальные типа паролей в открытом виде в базе. А дальше? Забить и "искать баги"
--------------------------
Давайте на этом примере. Требований нет. Что дальше?
Вот давайте на этом примере. Не нравится, давайте по доступности, или по производительности. Вот реально интересно, как вы будете искать баги
Отличный пример!
только вот вы не можете прийти к человеку со словами "проверь безопасность авторизации на нашем сайте в соответствии с требованиями" и не дать ему хоть какие то требования, это иначе бессмысленная задача. Он спросит, в соответствии с требованиями то какими?
Хоть какие то ему требования дадите, например, требования очень плохие и всего одна строчка "пароль должен быть не менее 12 символов". Через полчаса тестировщик закрывает задачу, на проде у вас все ломается, куча дыр безопасности. Вы прибегаете к нему и спрашиваете, ты че натворил? почему куча багов и дыр безопасности?
Что он вам ответит? Я полностью выполнил поставленную задачу, протестировал вход на наш сайт по требованиям, которые вы мне дали! я провел исчерпывающее тестирование граничных значений и проверил все кейсы, которые только можно было придумать.
Вы сами начинаете проверять и правда, реализация полностью соответствует требованиям, только пароль 12+ символов является валидным. Ну и кого тут нужно увольнять??
Аналогичная ситуация, вы приходите к тестировщику "искателю багов" и говорите аналогично: "проверь безопасность авторизации на нашем сайте, найди все баги" и уходите. Допустим, даже этот тестировщик плохой и вообще никаких требований не стал уточнять. НО, он же искатель багов и критически изначально настроен, он понимает, что в авторизации точно есть огромное количество багов. И начинает рассуждать: тааак, надо почитать, что такое авторизация и какие там типичные ошибки бывают. Тааак, самое банальное - вход вообще без пароля. Еще что? ну например слабый пароль могут подобрать перебором, а какие ограничения у нас вообще на это? а что если трафик перехватят, мы вообще пароли в зашифрованном виде передаем или просто текстом?
Да, задача была размыто поставлена. Да, много времени на нее потратит человек, но ооочень сильно глубже протестирует задачу. В итоге закончит только тогда, когда вы его остановите (так как тестирование безопасности обширная задача), либо когда уж совсем иссякнут идеи для кейсов
В общем, у искателя багов при отсутствии требований мы можем получить самое плохое - это затягивание сроков. У того, кто только проверял соответствие, получим очень плохое качество и большое количество пропущенных багов
только вот вы не можете прийти к человеку со словами "проверь безопасность авторизации на нашем сайте в соответствии с требованиями" и не дать ему хоть какие то требования, это иначе бессмысленная задача. Он спросит, в соответствии с требованиями то какими?
По прежнему остается вопрос, на который вы так и не отвечаете "А как вы опишете тестирование безопасности в стратегии тестирования?"
Требований нет, но вы как лид должны решить. Либо вы тестируете это и тогда просите дать требования, либо нет. И так и со всем.
--------------
Проблема в том, что вы ничего не протестируете. Банально потому, что "искатель багов" (как минимум если у вас при слове безопасность возникает кейс с паролем) не найдет ничего
Безопасность - это идентификация, аутентификация, авторизация, конфиденциальность, целостность, и еще иногда аудит. Это как бы бызовая база, которую можно и нужно раскрывать
Или вы думаете, что аналитик вам должен расписать все? Да нет, часто этро либо не возможно, либо где-то указано в технических соглашениях, либо в рахитектуртных документах, либо в стандартах ИТ Безопасности клиента
Но если вы не знаете об этом, как вы об этом спросите?
Ну вы даже аналогию привели настолько "примитивную", что аж грустно.
А потом оказывается, что все было описано в тех. доке, но тестер даже не открывал, так как типа "не его".
-----------------------
Все таки, что со стратегией, ответ будет?
Смешно же =D вы изначально патовую ситуацию даёте, когда очень сложная узкоспециализированная задача даётся абсолютно без требований, даётся тестировщикам, которые в безопасности ноль вообще и ещё нет аналитиков, которые могли бы расписать требования. Вывод тут один, вы плохой руководитель, а тестировщики в другую компанию уйдут =D
Возьмём средний вариант, более жизненный, когда у вас два одинаковых хороших сеньор тестировщика, которые базово разбираются в безопасности, но естественно у них нет каких то глубоких знаний об этом
Вы к ним приходите и говорите, что нужно протестировать безопасность, требований нет и никто вам их не подскажет.
Что ответят сеньоры?
Тот, у которого цель "проверка соответствиям требований" скажет, я вам что, кнопкотык какой то что ли? Я вам искатель багов что ли? Вот вам список вопросов, подготовьте 40 страниц с четкими полными требованиями на безопасность, потом приступлю к работе. Пока не будет требований, работа моя не возможна. То, что у вас нет аналитиков, которые это распишут, это не моя проблема. Жду 40страниц с ответами
А что ответит сеньор, который "искатель багов"? Скажет, вот вам тот же самый список вопросов. Понимаю, что нет аналитиков и не будет, кто подробно распишет требования, но вы насколько сможете, распишите ответы. Все, на что не сможете ответить, не так страшно. Я и без полных требований почитаю в интернете best practices, и не идеально конечно, но хоть в каком нибудь виде протестирую и хотя бы часть багов смогу откопать
И какой подход вам больше нравится?
В данном случае нужен будет тот, кто умеет и понимает, как это делать
Но в любом случае - я так понимаю, вы тут не очень в теме, без требований тут никуда, "поиск багов" не поможет
Давайте заканчивать, вы все равно не придете, как минимум в ходе этой дискусии к важности полноты требований и проверки именно их
Ну прям классный тестировщик, который пока не дождется полных требований (хотя сам написал, что их никто не даст) даже не притронется к задаче и даст продукту выйти с примитивными багами, которые и без требований можно было найти =D
Классный тестировщик
соберет требования их разных источников, включая нормативные документы как заказчика, так и других сторон
проверит, что все есть
покроет тест кейсами
Суть в том, что требования определяют фронт работ СИСТЕМНО. Каждое требование согласно стратегии покрывается кейсами и тестируется на соответствующем окружении
Ну я даже не знаю, как еще пояснить
Ну вы в отпуск едете, или в командировку. Удобно ж написать список чего взять и потом проверить, что все взяли
Так и с требованиями. Вы получаете фронт работ для проверки.
Вы сами поставили ситуацию, в которой тестировщик, который "проверяет соответствие требований" не имеет никаких требований и не имеет аналитика, который смог бы ответить на вопросы и значит и значит такой тестировщик бесполезен
Сами же пишете, что поступили бы как искатель багов, стали бы читать в инете, искать какие то бест практис и тд.
Но....почему то продолжаете утверждать, что хороший тестировщик тот, у кого цель тестировать соответствие требованиям (что подразумевает только полноту требований, а иначе мы отказываемся вообще тестить)
А искателя багов на собесе завалили бы..
Сами же пишете, что поступили бы как искатель багов, стали бы читать в инете, искать какие то бест практис и тд.
Все вы читаете между моих строк свои мысли :)
Искать ТРЕБОВАНИЯ, которые надо покрыть. Вопрос не в том, чтобы искать. Все знать нельзя, но важно знать, что искать
И искать надо именно это
(что подразумевает только полноту требований, а иначе мы отказываемся вообще тестить)
Нет, конечно. Если можно применить некие стандарты - то просто они применяются как требования. Если стандарты применить нельзя, равно как и "общепринятые" подходы - тогда просим дополнительно предоставить либо явно пишете - если не датите, есть явные риски, что в этом месте решение не будет протестировано на соответствие требованиям.
Т.е. вы не отказываетесь, а явно указываете, что "вот это не будет проверено"
А искателя багов на собесе завалили бы..
Вы никак не возьмете в толк, что методологически искатель багов не в состоянии гарантировать качество. Чисто потому, чо нет гарантий что он покрывает даже известные требования
Тоооо есть, у вас нет требований, нет аналитика, кто все распишет. Вы сами что то там почитали в интернете, сами себе придумали требования, сами по ним же потестили... И считаете, что вы уже не искатель багов, а тестирование у вас было четко по требованиям? =D
А как тогда по вашему искатели багов будут работать, они просто открывают сайт и клацают enter, пока что нибудь не сломалось? 😀
Вы сами в очередной раз описали работу искателя багов, который при невозможности получить требования, сам изучает бест практис и пытается по ним найти баг, но продолжаете утверждать, что это у вас четкое тестирование по требованиям 😀
Тоооо есть, у вас нет требований, нет аналитика, кто все распишет. Вы сами что то там почитали в интернете, сами себе придумали требования, сами по ним же потестили... И считаете, что вы уже не искатель багов, а тестирование у вас было четко по требованиям? =D
Ну смотрите, вам обязательно все сводить к крайним случаям. К примеру: Human Interface Guidelines | Apple Developer Documentation
Чисто тыкнул для прикола, как пример. Вы упоминали юзабилити, вот прирмер гайда. Совершенно законно взять его для проверки юзабилити
Либо другого вендора платформы
И таких примеров валом
Вы сами в очередной раз описали работу искателя багов, который при невозможности получить требования, сам изучает бест практис и пытается по ним найти баг,
Не "бест практис", а именно требования. Именно их, а не что-то еще :)
Что прикольно - тут паральлено бегает "камрад" под столом, так вот для стандартных требований (типа проведения пентеста), есть куча тулов :) Т.е. найдя требования, вы можете найти и "бест практис" в виде тулинга и/или методологии
Как вы никак не поймете, что "требования вперед", мне аж интересно
Вы мне 10 раз уже написали о том, что круто только "тестирование в соответствии с требованиями", так как это подразумевает, что тестировщик изначально добьется полных требований, полностью их покроет, а значит можно сказать, что все кейсы протестированы и качество продукта обеспечено
Но тут же пишете, что вообще то полнота требований не обязательна (а значит уже качество тестирования по такой методике не измеримо и доверия не заслуживает) и можно вообще самому нагуглить какие нибудь требования, самому решить, что мы теперь их как постулат используем. Потом к заказчику придем, скажем, я вот нагуглил какие то требования, по ним проверил и мне теперь деньги давайте?
И ещё раз спрашиваю, по вашему, искатель багов то как тестирует в такой ситуации? Не точно ли так же, как вы описали, гуглит тебе самые вещи, что и вы? Как ожидаемый результат то получается?
Но тут же пишете, что вообще то полнота требований не обязательна
Я уже не знаю, где я такое пишу. Наверное вам удается прочитать что-то не только между строк, но и где-то сбоку
можно вообще самому нагуглить какие нибудь требования, самому решить, что мы теперь их как постулат используем.
Нагуглить то можно, другое дело, что опираться на них вы можете по согласованию. Либо спросить, почему дизайн не соответствует, если есть рекомендация.
Это просто пример тестирования юзабилити, я к примеру был свидетелем таких дискуссий, и дизайн гайд как раз был способом их разрулить. Иначе в части юзабилити сложно найти какие-либо точки отсчета, которые могли бы всех удовлетворить
Вы ж сами с юзабилити начали :) Иначе ... как вы хотите обосновать баг. "Не нравится"???
И ещё раз спрашиваю, по вашему, искатель багов то как тестирует в такой ситуации? Не точно ли так же, как вы описали, гуглит тебе самые вещи, что и вы?
А зачем он гуглит? У вас боязнь называть то, что вы ищете "требования"?
Обычно искатель багов колупает то, что ему интресно, а потом получает люлей, так как надо было читать доку :)
-----------------
Ну и ... еще одна попытка. Тестирование требует системного подхода, потому что полнота очень важна. Направление "от требований" показывает наличие системности в голове, что в конечном итоге дает успех. А если системности нет - ну чего еще от QA ждать.
Но это больше требования к лиду, все остальное проходит обычно мимо меня, поэтому как там набирают остальных - мне не критично
Требования - это то, что вам дал заказчик/руководитель/аналитик
Когда у вас есть требования и реализация не сходится с ними, то вы автоматически создаёте баг и обсуждаете его, либо, если реализация устраивает, то аналитик свои требования поправит, если реализация не устраивает, то разраб правит согласно требованиям. НО, факт в том, что баг точно есть и либо требования, либо реализацию надо править
Если вы что то стороннее находите и пусть даже это будет требования от эпл по юзабилити, пусть все другие компании именно на них строят свои продукты, для вас это требованиями НЕ является. Эпл под вас точно свои правила править не будет, а разраб послать может с таким багом. С чего он должен исправлять свою работу по каким то правилам из интернета?
Вот вы сначала вышестоящему принесите эти "общие" правила, пусть посмотрят, если их устроят эти правила и разрешат использовать в качестве требований, только тогда они становятся непосредственно требованиями.
И я ещё раз напишу: все это опять же выходит за рамки "проверки соответствий по требованиям". А следовательно, вы не должны целью тестирования ставить такое узкое определение
Плакал и читал, читал и плакал... От смеха
В тестирование безопасности вы вообще зря полезли, месье
Как представил себе пентестера, тестирующего по требованиям, так и сполз под стол
Как представил себе пентестера, тестирующего по требованиям, так и сполз под стол
Ну вылезайте уже
В реальности
There are five penetration testing standards: Open Source Security Testing Methodology Manual[24] (OSSTMM), Open Web Application Security Project (OWASP), National Institute of Standards and Technology (NIST00), Information System Security Assessment Framework (ISSAF), and Penetration Testing Methodologies and Standards (PTES).
На практике, заказывая пен. тест (его обычно делают специализированные конторы), вы указывает стандарт, можете указать тулы и нужно ли делать тест "черный/белый" ящик
Но пент. тест очень специфичен и в реальности, очень далек от проверки требований ИТ Безопасности.
Поэтому скорее весело читать, что вы его вообще упомянули
Ну вот мы и дошли ещё до одного принципа - тестирование зависит от контекста
Так скоро придем к пониманию, что опыт харьковской галерки, работающей на польского фермера... ээээ... простите, вендора - это ещё не весь опыт мира
Контекст опредедяется в тестовой стратегии ;)
Но мне больше интересно, какле имеет отношение пентест к дискуссии?
Или вы просто переключились на что-то другое?
Вы как-то скачете то туда, то сюда. Я уже потерялся. То документ надр за вас почитать (перевели кстати), то про пентест поговорить, тут вообще контекст появился и польские фермеры
А по стратегии такой вопрос: у меня нет даже варианта, что я откажусь тестировать, как вы предлагаете.
Если такие условия, что я мало разбираюсь в теме, но требований нет и точно мне никто не даст их. Я захожу на хабр, ищу все статьи на данную тему, изучаю и тестирую так, как позволяет ситуация
Я не могу просто бросить тестирование только потому что никто не может полные требования дать
Все гораздо проще с точки зрения глубинных знаний - любая научная теория должна быть фальсифицируемой. Если спроецировать требование фальсифицируемости на разработку ПО - мы получим такой атрибут качества, как тестируемость
Ну и далее по аналогии - чтобы сделать заключение об истинности какой-либо теории ее не "доказывают" - не проверяют по "требованиям", ее пытаются фальсифицировать - т.е. найти в ней "баги" - противоречия. Если этого сделать не получается - теория с высокой вероятностью является истинной
В общем-то, это конечно забавно "искать баги" мимо требований. Как минимум мы просто не будем знать что является багом, а что нет. Где-то кнопка должна быть красной, а где-то зелёной - и это нормально. Но, если вместо красной кнопки будет зелёная - это баг. Но, без требований мы никак не можем об этом знать
А если сказать, что ошибка, дефект (баг) и сбой - это не одно и то же ....
Почему люди вообще считают, что бывает какая-то легкая работа? На любой работе приходится работать, вот что я могу сказать.
Обыватель вообще слабо представляет себе отличие тестировщика от верстальщика. Для обывателя все айтишники на одно лицо - главное, чтобы утюг могли починить
Больше всего мифов о тестировании у самих тестировщиков - правильное положение рук в следствии (которое ведут Колобки?) это наглядно демонстрирует
Просто есть два типа тестировщиков, которые умеют программировать и которые не умеют. И между ними пропасть.
Начал изучать тестирование (курс на степике,пока бесплатный,ютуб, книга Назиной) и питон( тоже самое- ютуб,книги). В надежде,что может быть смогу уйти в IT. Из-за проблем с ногами- болят,а работа у меня физическая и комп(оператор на заводе). И вы тут так меня воодушевили. И мне УЖЕ 45 лет. Короче,мне ничего не светит и нет смысла.
Светит, жизнь у всех только одна, если интересно, нужно делать, начал изучать, не бросай! Артем Русов и Ольга Назина хорошо вводят в курс дела о тестировании, и рассматривают популярные инструменты, посоветовал бы сразу практиковать во время просмотра, так сказать трогать инструменты. Плюс книга Куликова поможет в некоторых моментах разобраться. Возраст это вообще не показатель, смотрят какой ты специалист, а не сколько тебе лет :) Для начала, после изучения направлений, нужно определиться куда ты хочешь, что тебе интересно. Выбрал одно из возможных и максимально прокачиваешься в нём, ведь лучше знать одно на отлично, чем всё и на плохо. Если у тебя хватает самоконтроля, все курсы и книги можно найти в бесплатном доступе, если же не хватает, лучше взять платный, с контролем исполнения и обратной связью(конечно не первый попавшийся). Никто программистом, певцом, автослесарем и т.д. не рождается, всему учатся. Если у тебя желание есть, всё у тебя получится! Добра тебе!
Я тебе гарантирую, что систематически занимаясь этим делом, ты таки получишь работку. Не слушай дурачков, все получится!
И да, ни курсы, ни образование не играет роли.
Главное , чтобы голова была на плечах, а твои знания упираются только в твой труд.
Маленькие , но систематичные усилия помноженные на время, дают великий результат.
Если долбить тему каждый день, то она рано или поздно поддастся
Если есть желание, продолжайте. Желательно или курсы со стажировкой, или знакомых в ИТ иметь, чтобы на первую работу устроиться. Я перешла в ИТ через школу со стажировкой. Со мной вместе аналогично коллега из другой отрасли, 50 лет - автотестированием на Java удаленно занимается, в хорошей компании. Брат 40 лет устроился почти так же - прошел курсы, дальше мы помогли ему с первой работой. Его руководство довольно, он развивается дальше.
Очень хорошая статья для рекомендаций прочтения в телеграм каналах.
Спасибо!
Вы ещё про саппортов напишите, вот где днище: это когда у тебя диплом It-шника, но получаешь ты меньше чем плиточник, да ещё и работаешь сутками, и перспективы роста - никакой.
Работа дворника не только мести улицу, но и наблюдать за порядком во дворе, а так же содержать в порядке инвентарь.
Дворникам требуется образование ну и конечно же софт и хард скилы - без них никуда.
Дворника не заменишь всякими автоматизированными клининг системами, особенно у нас в Сибири.
Работа дворника не так скучна и однообразна как кажется: то алкоголики во дворе подерутся и их разнимать надо, то пожар случится и пожарным надо помочь, а иногда и подхалтурить можно подняв холодильник на этаж - в общем не соскучишься!
Дворники не влияют на ЖКХ?! - еще как влияют! Вот Михалыч разок сказал, что пока форму новую не купят на работу не выйдет!..и сразу купили - вот оно как...
Про коммуникативные навыки вообще молчу - кто здоровается и разговаривает СО ВСЕМИ во дворе?..правильно - Дворник!
Да и в творческом плане дворники не обделены - бывают шины старые на клумбах так расставят, смотришь и думаешь, ну чем не Версаль!
Наличие диплома по ИТ или прохождение специальных курсов и сертификаций даст тестировщику преимущество в поиске работы и повышении профессионального уровня.
Нет, не даёт никакого преимущества. До всего можно отлично найти самоучкой без курсов и образования.
Тестировщики полностью заменяемы автоматизированными тестами
И да, и нет. Поддержка и написание новых тестов действительно требует человека и QA, ответственный за это, действительно необходим. Но я так же знаю много примеров на практике, когда команда тестирования сокращалась в несколько раз после покрытия ручного тестирования автоматизацией в 95% и более. Я не согласен с такой реальностью, но для небольших компаний - это естественное урезание расходов.
А так вы описываете мифы, которые лет 10 уже никто не озвучивает, это уже давно в прошлом.
Найти всё что угодно можно. Но реальность показывает на то, что с дипломом (и конечно с пониманием сути) проще залететь в хороший проект и более менее зп нормальную :) ну т.е. есть разница, допустим, так сошлось два кандидата на один проект залетают, один с дипломом второй без(самоучка), одному на позиции джуна 50к платят, а второму 25к, и не потому что так заведено, а потому что самоучка сам не знает свою цену, и так же работодатель пока не убедиться что он будет приносить прибыль, оценить оплату его труда не может :) А так да, в плане устроиться на работу и без диплома можно, да и с дипломом не всегда спецами выходят :)
И ещё , как это лет 10 не озвучивают? Я живу в регионе, и скажу что как раз всё это озвучивают до пены изо рта до сих пор :) А ещё, удаленнка - это вообще больная тема многих, "да ну, как это работать не ходя на работу?", "Да, что вы там производите? А это руками можно потрогать? Нет? Так это ерунда какая-то", и т.д. А сами, - " Алиса, какая завтра погода? ... Включи мой плейлист." XD Хотя да в МСК, да и в других крупных городах люди, о таком не разговаривают, просто некогда :)
К сожалению, в статье много текста от chatGPT. Некоторые пункты вообще полностью написаны им.
Есть здравые мысли, но любой понимающий человек увидит как мало здесь конкретики.
Лучше у chatgpt спрашивать идеи, может быть советы по структурированию статьи, но писать абзацы своим языком.
Если цель - не просто награфоманить пустого контента, конечно)
ох уж эти нейросеточные посты, самим не тошно?
Мифы о работе тестировщиков, на которые всегда один ответ: «Ага, конечно. Ты полностью прав»