Требования - это то, что вам дал заказчик/руководитель/аналитик
Когда у вас есть требования и реализация не сходится с ними, то вы автоматически создаёте баг и обсуждаете его, либо, если реализация устраивает, то аналитик свои требования поправит, если реализация не устраивает, то разраб правит согласно требованиям. НО, факт в том, что баг точно есть и либо требования, либо реализацию надо править
Если вы что то стороннее находите и пусть даже это будет требования от эпл по юзабилити, пусть все другие компании именно на них строят свои продукты, для вас это требованиями НЕ является. Эпл под вас точно свои правила править не будет, а разраб послать может с таким багом. С чего он должен исправлять свою работу по каким то правилам из интернета?
Вот вы сначала вышестоящему принесите эти "общие" правила, пусть посмотрят, если их устроят эти правила и разрешат использовать в качестве требований, только тогда они становятся непосредственно требованиями.
И я ещё раз напишу: все это опять же выходит за рамки "проверки соответствий по требованиям". А следовательно, вы не должны целью тестирования ставить такое узкое определение
Вы мне 10 раз уже написали о том, что круто только "тестирование в соответствии с требованиями", так как это подразумевает, что тестировщик изначально добьется полных требований, полностью их покроет, а значит можно сказать, что все кейсы протестированы и качество продукта обеспечено
Но тут же пишете, что вообще то полнота требований не обязательна (а значит уже качество тестирования по такой методике не измеримо и доверия не заслуживает) и можно вообще самому нагуглить какие нибудь требования, самому решить, что мы теперь их как постулат используем. Потом к заказчику придем, скажем, я вот нагуглил какие то требования, по ним проверил и мне теперь деньги давайте?
И ещё раз спрашиваю, по вашему, искатель багов то как тестирует в такой ситуации? Не точно ли так же, как вы описали, гуглит тебе самые вещи, что и вы? Как ожидаемый результат то получается?
Тоооо есть, у вас нет требований, нет аналитика, кто все распишет. Вы сами что то там почитали в интернете, сами себе придумали требования, сами по ним же потестили... И считаете, что вы уже не искатель багов, а тестирование у вас было четко по требованиям? =D
А как тогда по вашему искатели багов будут работать, они просто открывают сайт и клацают enter, пока что нибудь не сломалось? ?
Вы сами в очередной раз описали работу искателя багов, который при невозможности получить требования, сам изучает бест практис и пытается по ним найти баг, но продолжаете утверждать, что это у вас четкое тестирование по требованиям ?
Вы сами поставили ситуацию, в которой тестировщик, который "проверяет соответствие требований" не имеет никаких требований и не имеет аналитика, который смог бы ответить на вопросы и значит и значит такой тестировщик бесполезен
Сами же пишете, что поступили бы как искатель багов, стали бы читать в инете, искать какие то бест практис и тд.
Но....почему то продолжаете утверждать, что хороший тестировщик тот, у кого цель тестировать соответствие требованиям (что подразумевает только полноту требований, а иначе мы отказываемся вообще тестить)
Ну прям классный тестировщик, который пока не дождется полных требований (хотя сам написал, что их никто не даст) даже не притронется к задаче и даст продукту выйти с примитивными багами, которые и без требований можно было найти =D
А по стратегии такой вопрос: у меня нет даже варианта, что я откажусь тестировать, как вы предлагаете.
Если такие условия, что я мало разбираюсь в теме, но требований нет и точно мне никто не даст их. Я захожу на хабр, ищу все статьи на данную тему, изучаю и тестирую так, как позволяет ситуация
Я не могу просто бросить тестирование только потому что никто не может полные требования дать
Смешно же =D вы изначально патовую ситуацию даёте, когда очень сложная узкоспециализированная задача даётся абсолютно без требований, даётся тестировщикам, которые в безопасности ноль вообще и ещё нет аналитиков, которые могли бы расписать требования. Вывод тут один, вы плохой руководитель, а тестировщики в другую компанию уйдут =D
Возьмём средний вариант, более жизненный, когда у вас два одинаковых хороших сеньор тестировщика, которые базово разбираются в безопасности, но естественно у них нет каких то глубоких знаний об этом
Вы к ним приходите и говорите, что нужно протестировать безопасность, требований нет и никто вам их не подскажет.
Что ответят сеньоры?
Тот, у которого цель "проверка соответствиям требований" скажет, я вам что, кнопкотык какой то что ли? Я вам искатель багов что ли? Вот вам список вопросов, подготовьте 40 страниц с четкими полными требованиями на безопасность, потом приступлю к работе. Пока не будет требований, работа моя не возможна. То, что у вас нет аналитиков, которые это распишут, это не моя проблема. Жду 40страниц с ответами
А что ответит сеньор, который "искатель багов"? Скажет, вот вам тот же самый список вопросов. Понимаю, что нет аналитиков и не будет, кто подробно распишет требования, но вы насколько сможете, распишите ответы. Все, на что не сможете ответить, не так страшно. Я и без полных требований почитаю в интернете best practices, и не идеально конечно, но хоть в каком нибудь виде протестирую и хотя бы часть багов смогу откопать
только вот вы не можете прийти к человеку со словами "проверь безопасность авторизации на нашем сайте в соответствии с требованиями" и не дать ему хоть какие то требования, это иначе бессмысленная задача. Он спросит, в соответствии с требованиями то какими?
Хоть какие то ему требования дадите, например, требования очень плохие и всего одна строчка "пароль должен быть не менее 12 символов". Через полчаса тестировщик закрывает задачу, на проде у вас все ломается, куча дыр безопасности. Вы прибегаете к нему и спрашиваете, ты че натворил? почему куча багов и дыр безопасности?
Что он вам ответит? Я полностью выполнил поставленную задачу, протестировал вход на наш сайт по требованиям, которые вы мне дали! я провел исчерпывающее тестирование граничных значений и проверил все кейсы, которые только можно было придумать. Вы сами начинаете проверять и правда, реализация полностью соответствует требованиям, только пароль 12+ символов является валидным. Ну и кого тут нужно увольнять??
Аналогичная ситуация, вы приходите к тестировщику "искателю багов" и говорите аналогично: "проверь безопасность авторизации на нашем сайте, найди все баги" и уходите. Допустим, даже этот тестировщик плохой и вообще никаких требований не стал уточнять. НО, он же искатель багов и критически изначально настроен, он понимает, что в авторизации точно есть огромное количество багов. И начинает рассуждать: тааак, надо почитать, что такое авторизация и какие там типичные ошибки бывают. Тааак, самое банальное - вход вообще без пароля. Еще что? ну например слабый пароль могут подобрать перебором, а какие ограничения у нас вообще на это? а что если трафик перехватят, мы вообще пароли в зашифрованном виде передаем или просто текстом?
Да, задача была размыто поставлена. Да, много времени на нее потратит человек, но ооочень сильно глубже протестирует задачу. В итоге закончит только тогда, когда вы его остановите (так как тестирование безопасности обширная задача), либо когда уж совсем иссякнут идеи для кейсов
В общем, у искателя багов при отсутствии требований мы можем получить самое плохое - это затягивание сроков. У того, кто только проверял соответствие, получим очень плохое качество и большое количество пропущенных багов
сбор требований, проверка полноты требований, тестирование самих требований - все это выходит за рамки вашей задачи по проверке соответствия требованиям.
Проверка соответствия требованиям - это когда вам приносят готовые требования и задача только проверить соответствие. Все остальное, выходящее за рамки, является поиском багов (либо можете новое определение придумать)
Лично у меня проверка соответствия требованиям это уже заключительный этап, а первый - самый сложный и самый ответственный, это тестирование требований (что к проверке соответствия требованиям не имеет отношения)
четкая поставленная задача - проверить соответствие требованиям, вполне подходит на уровень джуна и мидл-. Там нужно всего лишь взять готовые требования и, даже не сильно еще погрузившись в продукт, можно по самим требованиям накидать кейсов и чисто по ним пройтись. Там не требуется что то от себя придумывать, пытаться аналитика подловить на сложных кейсах, тут достаточно не пропустить кейсы и полностью покрыть требования
Цель найти все баги, уже подходит больше для мидл+ и синьора, так как подразумевает не только четкую задачу "взять и проверить соответствие", а более обширную задачу с тестированием самих требований и выход за рамки требований (как в юзабилити например)
а теперь перечитайте мой самый первый комментарий, в котором написано, что "искатель багов" и цель "проверка соответствий требованиям" - это по сути в практике одно и то же, отличается лишь настроем, с которым подходим к этому тестированию
А если уж вы так любите к людям придираться на собеседованиях и очень хочется разделить эти два понятия, то:
Цель тестирования "проверка соответствия требованиям" - четко сформулированная конкретная фраза, которая говорит нам о том, что нужно просто взять готовые требования и по ним проверять соответствие реализации
Эта конкретная цель не подразумевает, что "вообще то надо сначала требования сами тестировать", "вообще то надо за рамки требований выходить и не все туда в требования писать", "вообще то надо юзабилити и подобное без требований как то по наитию тестировать и баги писать. Это все ваши уже придумки и вы такими придумками четкую поставленную задачу "проверить соответствие требованиям" превращаете в "поиск всех багов" (и в реализации и в самих требованиях)
"Цель - проверка соответствия требованиям узкая и имеет место быть, только когда вы реально открываете требования, четко по ним идете и сверяете все кейсы.
Как только вы вышли ЗА рамки требований (проверяете полноту требований, тестируете то, что не описано в требованиях, тестируете сами требования) - вы уже не "проверяете соответствие требований", а искатель багов "
Так вот, как вы проверяете полноту требований?? Вы действуете как искатель багов, ищите узкие места системы, потенциально опасные/сложные кейсы, функционал вообще не описанный в требованиях и тд и на основе этого добиваетесь полноты требований
И дальше, когда все требования полны, нормально описаны и сами не содержат ошибок - тут, что "проверяльщик соответствия требованиям", что "искатель багов" будут проверять одни и те же кейсы, которые в требованиях описаны. Отличий никаких
Цель - проверка соответствия требованиям узкая и имеет место быть, только когда вы реально открываете требования, четко по ним идете и сверяете все кейсы.
Как только вы вышли ЗА рамки требований (проверяете полноту требований, тестируете то, что не описано в требованиях) - вы уже не "проверяете соответствие требований", а искатель багов
"К примеру, вы можете не требовать аналитика вписать эти требования, но отметить что использованный компонент не соответствует дизайн гайдам платформы либо бренд буку клиента и зарегать баг на эту тему
Конструктивно в вас может быть свой check list, который условно дополнительно применяется под конкретную технологию и обеспечивает полноту по "общим" требованиям "
ЕЩЕ РАЗ, дак ЧЕМ же тогда по вашему отличается цель "проверка соответствия требованиям" и цель "найти все баги"?
Причем, по вашим же словам, в проверке соответствия требований - требования не настолько уж обязательны, не все требования аналитика просить добавить, а юзабилити вообще трудно описуемо в требованиях и юзабилити баги как то по наитию надо искать?
При этом, цель "найти все баги" для вас настолько плохая, что вы готовы даже с сеньором попрощаться, если он ее озвучит. ХОТЯ, "найти все баги" точно так же подразумевает, что нам известны все требования. Иначе цель не достижима, так как не зная требований вы все баги и не найдете
Или, все таки, как я вас пытаюсь убедить, цели тестирования эти абсолютно одинаковые и влияют только на общий настрой? Может лучше вместо пустого вопроса про цель тестирования спросить, какие кейсы, в каком порядке и почему именно так собеседуемый будет тестировать?
Вы пишите лучше на конкретных примерах, в чем подход с поиском всех багов хуже, чем подход с проверкой соответствий требованиям. Иначе, в одном сообщении пишите, что плюс проверки соответствий требованиям - быстро проверил и отправил в прод, а искатель багов будет 100500 кейсов придумывать помимо требований и долго тестировать все кейсы
То пишите, что при проверке соответствий требованиям тестировщик обеспечит полноту требований и проверит ВСЕ кейсы, а искатель значит кучу кейсов вообще пропустит и много чего не станет проверять
Вот мой конкретный пример, только не уходите в демагогию, а постарайтесь его разобрать:
Есть сайт по покупке неких вещей, вам нужно протестировать кнопку "Оформить заказ". Аналитик вообще бешеный, на 50 страницах вордовского файла описал вам самые полные требования к этой кнопке: ее название, РАЗМЕР, ее поведение, все комбинации железа и ПО, где эта кнопка корректно должна отрабатывать. В общем, самые исчерпывающие требования.
И есть два тестировщика, которые по этим требованиям протестировали вообще ВСЕ кейсы, какие только возможно придумать.
По требованиям все отлично, все кейсы проходят, требования полны и полностью соблюдены.
Первый тестировщик, цель которого проверка соответствия требованиям, закрывает задачу и отпускает в прод
Второй тестировщик "искатель багов", понимает, что по требованиям все отлично и работает, НО при разрешениях экранов более 2К кнопка такая маленькая, что скорей всего каждый второй пользователь будет промахиваться, психовать и, условно, каждый сотый будет просто закрывать сайт и не оформлять из за этого заказ. Так как он искатель багов, он даже такой мелкий вроде бы баг заводит (хотя полностью соответствующий требованиям, так как размер кнопки прописан) и идет к вышестоящим разбираться, не наделали ли мы ерунды и точно ли такое надо в прод релизить??
Вот какой подход вам лично ближе, проверка соответствия требованиям или искатель багов? и какого из этих тестировщиков вы хотели бы к себе в команду?
Сразу напишу, что у первого тестировщика тоже есть плюс в том, что он проверил полноту требований и проверил кейсы и при этом не стал тратить время на визит к вышестоящему по поводу субъективого восприятия удобства кнопки. Место тоже такому тестировщику есть. Если потом что то не так пойдет в проде, будет отток клиентов, то получит за это аналитик, который размер кнопок написал
и еще раз повторюсь, вы сами действуете как искатель багов, а не как человек, который проверяет соответствие требованиям
Я вам дал четкую строку требований на уникальность имен и вы не кинулись на проверку соответствия требованиям, а критически отнеслись к ним и сразу же выдали два кейса с возможными багами (загрузка с мобилок, загрузка файла другого формата) и сразу же как искатель багов начали предъявлять претензии к этим требованиям
Скорей всего, как опытный тестировщик, вы бы пошли к аналитику с перечнем узких мест, которые вы видите в функционале и которые не описаны в требованиях: различные устройства и браузеры, кодировка, многопоточная загрузка, загрузка файлов другого формата и тд.
То есть, типичный искатель багов это тот, кто еще на момент прочтения требований уже видит возможные проблемы
"требования полны" - точно так же недостижимая цель, как и "найти все баги"
Чтобы требования были полны, в них должны быть описаны ожидаемые результаты вообще всех кейсов, которые вы только придумаете. Включая, поведение на ресайз окна, описание всех сочетаний конфигураций, где обязательно должен работать функционал и тд и тп
Если у вас требования полны и покрывают ВСЕ возможные кейсы, то количество кейсов для проверки соответствия требований будет точно такое же, как у тестировщика цель которого найти все баги, а значит и качество тестирования и количество найденных багов и время тестирования, все будет абсолютно одинаковое при обоих подходах. То есть вывод такой , как я и писал, это абсолютно одинаковые по смыслу цели тестирования, отличается только общий настрой подхода к задаче
Как я в самом своем первом сообщении писал "Во втором утверждении, когда цель тестирования это поиск багов. Сразу подразумевается критическое мышление и к реализации и К ТРЕБОВАНИЯМ! Тут уже больше опираешься на знание продукта, знание его конечного пользователя и опираешься именно на это и тестирование начинается именно с поиска багов в самих требованиях. В данной парадигме требования это не конституция и не библия, на которую надо опираться и принимать за чистую монету. В данной парадигме требования это тоже часть нашего продукта, которая тоже скорей всего содержит какие то баги, несостыковки, функционал, неудобный для конечного пользователя "
"По вашему подходу я могу все проверить, но потом кто-то откроет сайт з загрузкой файла на мобильном и все ... все получат люлей. Или загрузит вместо картинки что-то дай бог не зловредное "
И ваш последний абзац вас и выдал, вы сами идете по цели "поиска багов", а не просто "проверка соответствия требованиям"
Вот вы сейчас сами всё с ног на голову перевернули =D
До этого вы писали, что при "проверке на соответствие требованиям" тестировщик должен четко проверить соответствие требованиям и четко по ним проверить все кейсы, а при цели "найти баги" тестировщик будет тратить время команды на то, что вообще в требованиях не описано и цель "найти баги" не достижима, так как она не конечна
Сейчас же, когда я попросил на конкретном примере показать отличие этих подходов, вы написали: "с целью проверки соответствия требованиям тестировщик должен будет покрыть ВСЁ, а не только то требование которое у него есть. А искатель багов будет топтаться с известным ему требованием и 100500 кейсов на это требование придумывать" =D
Давайте уж определимся на конкретном примере, кто у нас по требованиям идет, а кто не по требованиям, у кого конечная цель, а у кого нет
Требования - это то, что вам дал заказчик/руководитель/аналитик
Когда у вас есть требования и реализация не сходится с ними, то вы автоматически создаёте баг и обсуждаете его, либо, если реализация устраивает, то аналитик свои требования поправит, если реализация не устраивает, то разраб правит согласно требованиям. НО, факт в том, что баг точно есть и либо требования, либо реализацию надо править
Если вы что то стороннее находите и пусть даже это будет требования от эпл по юзабилити, пусть все другие компании именно на них строят свои продукты, для вас это требованиями НЕ является. Эпл под вас точно свои правила править не будет, а разраб послать может с таким багом. С чего он должен исправлять свою работу по каким то правилам из интернета?
Вот вы сначала вышестоящему принесите эти "общие" правила, пусть посмотрят, если их устроят эти правила и разрешат использовать в качестве требований, только тогда они становятся непосредственно требованиями.
И я ещё раз напишу: все это опять же выходит за рамки "проверки соответствий по требованиям". А следовательно, вы не должны целью тестирования ставить такое узкое определение
Вы мне 10 раз уже написали о том, что круто только "тестирование в соответствии с требованиями", так как это подразумевает, что тестировщик изначально добьется полных требований, полностью их покроет, а значит можно сказать, что все кейсы протестированы и качество продукта обеспечено
Но тут же пишете, что вообще то полнота требований не обязательна (а значит уже качество тестирования по такой методике не измеримо и доверия не заслуживает) и можно вообще самому нагуглить какие нибудь требования, самому решить, что мы теперь их как постулат используем. Потом к заказчику придем, скажем, я вот нагуглил какие то требования, по ним проверил и мне теперь деньги давайте?
И ещё раз спрашиваю, по вашему, искатель багов то как тестирует в такой ситуации? Не точно ли так же, как вы описали, гуглит тебе самые вещи, что и вы? Как ожидаемый результат то получается?
Тоооо есть, у вас нет требований, нет аналитика, кто все распишет. Вы сами что то там почитали в интернете, сами себе придумали требования, сами по ним же потестили... И считаете, что вы уже не искатель багов, а тестирование у вас было четко по требованиям? =D
А как тогда по вашему искатели багов будут работать, они просто открывают сайт и клацают enter, пока что нибудь не сломалось? ?
Вы сами в очередной раз описали работу искателя багов, который при невозможности получить требования, сам изучает бест практис и пытается по ним найти баг, но продолжаете утверждать, что это у вас четкое тестирование по требованиям ?
Вы сами поставили ситуацию, в которой тестировщик, который "проверяет соответствие требований" не имеет никаких требований и не имеет аналитика, который смог бы ответить на вопросы и значит и значит такой тестировщик бесполезен
Сами же пишете, что поступили бы как искатель багов, стали бы читать в инете, искать какие то бест практис и тд.
Но....почему то продолжаете утверждать, что хороший тестировщик тот, у кого цель тестировать соответствие требованиям (что подразумевает только полноту требований, а иначе мы отказываемся вообще тестить)
А искателя багов на собесе завалили бы..
Ну прям классный тестировщик, который пока не дождется полных требований (хотя сам написал, что их никто не даст) даже не притронется к задаче и даст продукту выйти с примитивными багами, которые и без требований можно было найти =D
А по стратегии такой вопрос: у меня нет даже варианта, что я откажусь тестировать, как вы предлагаете.
Если такие условия, что я мало разбираюсь в теме, но требований нет и точно мне никто не даст их. Я захожу на хабр, ищу все статьи на данную тему, изучаю и тестирую так, как позволяет ситуация
Я не могу просто бросить тестирование только потому что никто не может полные требования дать
Смешно же =D вы изначально патовую ситуацию даёте, когда очень сложная узкоспециализированная задача даётся абсолютно без требований, даётся тестировщикам, которые в безопасности ноль вообще и ещё нет аналитиков, которые могли бы расписать требования. Вывод тут один, вы плохой руководитель, а тестировщики в другую компанию уйдут =D
Возьмём средний вариант, более жизненный, когда у вас два одинаковых хороших сеньор тестировщика, которые базово разбираются в безопасности, но естественно у них нет каких то глубоких знаний об этом
Вы к ним приходите и говорите, что нужно протестировать безопасность, требований нет и никто вам их не подскажет.
Что ответят сеньоры?
Тот, у которого цель "проверка соответствиям требований" скажет, я вам что, кнопкотык какой то что ли? Я вам искатель багов что ли? Вот вам список вопросов, подготовьте 40 страниц с четкими полными требованиями на безопасность, потом приступлю к работе. Пока не будет требований, работа моя не возможна. То, что у вас нет аналитиков, которые это распишут, это не моя проблема. Жду 40страниц с ответами
А что ответит сеньор, который "искатель багов"? Скажет, вот вам тот же самый список вопросов. Понимаю, что нет аналитиков и не будет, кто подробно распишет требования, но вы насколько сможете, распишите ответы. Все, на что не сможете ответить, не так страшно. Я и без полных требований почитаю в интернете best practices, и не идеально конечно, но хоть в каком нибудь виде протестирую и хотя бы часть багов смогу откопать
И какой подход вам больше нравится?
Отличный пример!
только вот вы не можете прийти к человеку со словами "проверь безопасность авторизации на нашем сайте в соответствии с требованиями" и не дать ему хоть какие то требования, это иначе бессмысленная задача. Он спросит, в соответствии с требованиями то какими?
Хоть какие то ему требования дадите, например, требования очень плохие и всего одна строчка "пароль должен быть не менее 12 символов". Через полчаса тестировщик закрывает задачу, на проде у вас все ломается, куча дыр безопасности. Вы прибегаете к нему и спрашиваете, ты че натворил? почему куча багов и дыр безопасности?
Что он вам ответит? Я полностью выполнил поставленную задачу, протестировал вход на наш сайт по требованиям, которые вы мне дали! я провел исчерпывающее тестирование граничных значений и проверил все кейсы, которые только можно было придумать.
Вы сами начинаете проверять и правда, реализация полностью соответствует требованиям, только пароль 12+ символов является валидным. Ну и кого тут нужно увольнять??
Аналогичная ситуация, вы приходите к тестировщику "искателю багов" и говорите аналогично: "проверь безопасность авторизации на нашем сайте, найди все баги" и уходите. Допустим, даже этот тестировщик плохой и вообще никаких требований не стал уточнять. НО, он же искатель багов и критически изначально настроен, он понимает, что в авторизации точно есть огромное количество багов. И начинает рассуждать: тааак, надо почитать, что такое авторизация и какие там типичные ошибки бывают. Тааак, самое банальное - вход вообще без пароля. Еще что? ну например слабый пароль могут подобрать перебором, а какие ограничения у нас вообще на это? а что если трафик перехватят, мы вообще пароли в зашифрованном виде передаем или просто текстом?
Да, задача была размыто поставлена. Да, много времени на нее потратит человек, но ооочень сильно глубже протестирует задачу. В итоге закончит только тогда, когда вы его остановите (так как тестирование безопасности обширная задача), либо когда уж совсем иссякнут идеи для кейсов
В общем, у искателя багов при отсутствии требований мы можем получить самое плохое - это затягивание сроков. У того, кто только проверял соответствие, получим очень плохое качество и большое количество пропущенных багов
сбор требований, проверка полноты требований, тестирование самих требований - все это выходит за рамки вашей задачи по проверке соответствия требованиям.
Проверка соответствия требованиям - это когда вам приносят готовые требования и задача только проверить соответствие. Все остальное, выходящее за рамки, является поиском багов (либо можете новое определение придумать)
Лично у меня проверка соответствия требованиям это уже заключительный этап, а первый - самый сложный и самый ответственный, это тестирование требований (что к проверке соответствия требованиям не имеет отношения)
четкая поставленная задача - проверить соответствие требованиям, вполне подходит на уровень джуна и мидл-. Там нужно всего лишь взять готовые требования и, даже не сильно еще погрузившись в продукт, можно по самим требованиям накидать кейсов и чисто по ним пройтись. Там не требуется что то от себя придумывать, пытаться аналитика подловить на сложных кейсах, тут достаточно не пропустить кейсы и полностью покрыть требования
Цель найти все баги, уже подходит больше для мидл+ и синьора, так как подразумевает не только четкую задачу "взять и проверить соответствие", а более обширную задачу с тестированием самих требований и выход за рамки требований (как в юзабилити например)
а теперь перечитайте мой самый первый комментарий, в котором написано, что "искатель багов" и цель "проверка соответствий требованиям" - это по сути в практике одно и то же, отличается лишь настроем, с которым подходим к этому тестированию
А если уж вы так любите к людям придираться на собеседованиях и очень хочется разделить эти два понятия, то:
Цель тестирования "проверка соответствия требованиям" - четко сформулированная конкретная фраза, которая говорит нам о том, что нужно просто взять готовые требования и по ним проверять соответствие реализации
Эта конкретная цель не подразумевает, что "вообще то надо сначала требования сами тестировать", "вообще то надо за рамки требований выходить и не все туда в требования писать", "вообще то надо юзабилити и подобное без требований как то по наитию тестировать и баги писать. Это все ваши уже придумки и вы такими придумками четкую поставленную задачу "проверить соответствие требованиям" превращаете в "поиск всех багов" (и в реализации и в самих требованиях)
Еще раз напишу то, о чем писал 10 минут назад.
"Цель - проверка соответствия требованиям узкая и имеет место быть, только когда вы реально открываете требования, четко по ним идете и сверяете все кейсы.
Как только вы вышли ЗА рамки требований (проверяете полноту требований, тестируете то, что не описано в требованиях, тестируете сами требования) - вы уже не "проверяете соответствие требований", а искатель багов "
Так вот, как вы проверяете полноту требований?? Вы действуете как искатель багов, ищите узкие места системы, потенциально опасные/сложные кейсы, функционал вообще не описанный в требованиях и тд и на основе этого добиваетесь полноты требований
И дальше, когда все требования полны, нормально описаны и сами не содержат ошибок - тут, что "проверяльщик соответствия требованиям", что "искатель багов" будут проверять одни и те же кейсы, которые в требованиях описаны. Отличий никаких
Цель - проверка соответствия требованиям узкая и имеет место быть, только когда вы реально открываете требования, четко по ним идете и сверяете все кейсы.
Как только вы вышли ЗА рамки требований (проверяете полноту требований, тестируете то, что не описано в требованиях) - вы уже не "проверяете соответствие требований", а искатель багов
=D
"К примеру, вы можете не требовать аналитика вписать эти требования, но отметить что использованный компонент не соответствует дизайн гайдам платформы либо бренд буку клиента и зарегать баг на эту тему
Конструктивно в вас может быть свой check list, который условно дополнительно применяется под конкретную технологию и обеспечивает полноту по "общим" требованиям "
ЕЩЕ РАЗ, дак ЧЕМ же тогда по вашему отличается цель "проверка соответствия требованиям" и цель "найти все баги"?
Причем, по вашим же словам, в проверке соответствия требований - требования не настолько уж обязательны, не все требования аналитика просить добавить, а юзабилити вообще трудно описуемо в требованиях и юзабилити баги как то по наитию надо искать?
При этом, цель "найти все баги" для вас настолько плохая, что вы готовы даже с сеньором попрощаться, если он ее озвучит. ХОТЯ, "найти все баги" точно так же подразумевает, что нам известны все требования. Иначе цель не достижима, так как не зная требований вы все баги и не найдете
Или, все таки, как я вас пытаюсь убедить, цели тестирования эти абсолютно одинаковые и влияют только на общий настрой? Может лучше вместо пустого вопроса про цель тестирования спросить, какие кейсы, в каком порядке и почему именно так собеседуемый будет тестировать?
Вы пишите лучше на конкретных примерах, в чем подход с поиском всех багов хуже, чем подход с проверкой соответствий требованиям. Иначе, в одном сообщении пишите, что плюс проверки соответствий требованиям - быстро проверил и отправил в прод, а искатель багов будет 100500 кейсов придумывать помимо требований и долго тестировать все кейсы
То пишите, что при проверке соответствий требованиям тестировщик обеспечит полноту требований и проверит ВСЕ кейсы, а искатель значит кучу кейсов вообще пропустит и много чего не станет проверять
Вот мой конкретный пример, только не уходите в демагогию, а постарайтесь его разобрать:
Есть сайт по покупке неких вещей, вам нужно протестировать кнопку "Оформить заказ". Аналитик вообще бешеный, на 50 страницах вордовского файла описал вам самые полные требования к этой кнопке: ее название, РАЗМЕР, ее поведение, все комбинации железа и ПО, где эта кнопка корректно должна отрабатывать. В общем, самые исчерпывающие требования.
И есть два тестировщика, которые по этим требованиям протестировали вообще ВСЕ кейсы, какие только возможно придумать.
По требованиям все отлично, все кейсы проходят, требования полны и полностью соблюдены.
Первый тестировщик, цель которого проверка соответствия требованиям, закрывает задачу и отпускает в прод
Второй тестировщик "искатель багов", понимает, что по требованиям все отлично и работает, НО при разрешениях экранов более 2К кнопка такая маленькая, что скорей всего каждый второй пользователь будет промахиваться, психовать и, условно, каждый сотый будет просто закрывать сайт и не оформлять из за этого заказ. Так как он искатель багов, он даже такой мелкий вроде бы баг заводит (хотя полностью соответствующий требованиям, так как размер кнопки прописан) и идет к вышестоящим разбираться, не наделали ли мы ерунды и точно ли такое надо в прод релизить??
Вот какой подход вам лично ближе, проверка соответствия требованиям или искатель багов? и какого из этих тестировщиков вы хотели бы к себе в команду?
Сразу напишу, что у первого тестировщика тоже есть плюс в том, что он проверил полноту требований и проверил кейсы и при этом не стал тратить время на визит к вышестоящему по поводу субъективого восприятия удобства кнопки. Место тоже такому тестировщику есть. Если потом что то не так пойдет в проде, будет отток клиентов, то получит за это аналитик, который размер кнопок написал
и еще раз повторюсь, вы сами действуете как искатель багов, а не как человек, который проверяет соответствие требованиям
Я вам дал четкую строку требований на уникальность имен и вы не кинулись на проверку соответствия требованиям, а критически отнеслись к ним и сразу же выдали два кейса с возможными багами (загрузка с мобилок, загрузка файла другого формата) и сразу же как искатель багов начали предъявлять претензии к этим требованиям
Скорей всего, как опытный тестировщик, вы бы пошли к аналитику с перечнем узких мест, которые вы видите в функционале и которые не описаны в требованиях: различные устройства и браузеры, кодировка, многопоточная загрузка, загрузка файлов другого формата и тд.
То есть, типичный искатель багов это тот, кто еще на момент прочтения требований уже видит возможные проблемы
"Это просто жизненные ситуации, когда "искатели багов" пропускают очевиднейшие ошибки, так как просто не тестировали это вообще "
дак кто в итоге больше багов пропустит, тот у кого цель "НАЙТИ ВСЕ БАГИ" или тот, у кого цель просто проверить соответствие требованиям? =DD
вы помоему начинаете уже защищать тех, кто ищет все баги, а не кто только соответствие требованиям проверяет
"требования полны" - точно так же недостижимая цель, как и "найти все баги"
Чтобы требования были полны, в них должны быть описаны ожидаемые результаты вообще всех кейсов, которые вы только придумаете. Включая, поведение на ресайз окна, описание всех сочетаний конфигураций, где обязательно должен работать функционал и тд и тп
Если у вас требования полны и покрывают ВСЕ возможные кейсы, то количество кейсов для проверки соответствия требований будет точно такое же, как у тестировщика цель которого найти все баги, а значит и качество тестирования и количество найденных багов и время тестирования, все будет абсолютно одинаковое при обоих подходах. То есть вывод такой , как я и писал, это абсолютно одинаковые по смыслу цели тестирования, отличается только общий настрой подхода к задаче
Как я в самом своем первом сообщении писал "Во втором утверждении, когда цель тестирования это поиск багов. Сразу подразумевается критическое мышление и к реализации и К ТРЕБОВАНИЯМ! Тут уже больше опираешься на знание продукта, знание его конечного пользователя и опираешься именно на это и тестирование начинается именно с поиска багов в самих требованиях. В данной парадигме требования это не конституция и не библия, на которую надо опираться и принимать за чистую монету. В данной парадигме требования это тоже часть нашего продукта, которая тоже скорей всего содержит какие то баги, несостыковки, функционал, неудобный для конечного пользователя "
"По вашему подходу я могу все проверить, но потом кто-то откроет сайт з загрузкой файла на мобильном и все ... все получат люлей. Или загрузит вместо картинки что-то дай бог не зловредное "
И ваш последний абзац вас и выдал, вы сами идете по цели "поиска багов", а не просто "проверка соответствия требованиям"
Вот вы сейчас сами всё с ног на голову перевернули =D
До этого вы писали, что при "проверке на соответствие требованиям" тестировщик должен четко проверить соответствие требованиям и четко по ним проверить все кейсы, а при цели "найти баги" тестировщик будет тратить время команды на то, что вообще в требованиях не описано и цель "найти баги" не достижима, так как она не конечна
Сейчас же, когда я попросил на конкретном примере показать отличие этих подходов, вы написали: "с целью проверки соответствия требованиям тестировщик должен будет покрыть ВСЁ, а не только то требование которое у него есть. А искатель багов будет топтаться с известным ему требованием и 100500 кейсов на это требование придумывать" =D
Давайте уж определимся на конкретном примере, кто у нас по требованиям идет, а кто не по требованиям, у кого конечная цель, а у кого нет