Где тестировщику брать ответы в случае сомнений?

Думаю, что это может случится с каждым. Представьте, что вы приходите в новый проект/компанию и практически ничего о них не знаете. Первые недели достаточно стрессовые, поскольку нужно разобраться, как работает продукт.

Довольно распространённый случай, когда тестировщику нужно определить, что именно протестировать в той или иной задаче. Куда бежать и кому задавать вопросы, если сама задача неясна и требует дополнительной информации? Что делать, если вы не уверены, баг это или нет?

Давайте разобьём этот вопрос на несколько сценариев и для каждого разработаем план действий.

Сценарий #1: задача относится к проверке функции (или части функции), где есть строгое описание, но мало деталей.

Данный сценарий описывает ЧТО данная функция выполняет.

Данный сценарий очень распространён для новичков или в случаях, когда нужно подменить кого-то в команде, при этом не зная тонкостей конкретной задачи. Если у нас есть какой-то вопрос, который не был раскрыт ранее, и он касается бизнес-части, мы должны задать его менеджеру проекта или кому-то, кто разбирается в бизнес-логике продукта.

Здесь вы можете узнать больше о важности качественных требований и роли, которую QA играет в этом.

Конечно, по этому вопросу вы можете обратиться к разработчику, но позвольте спросить вас кое о чём. Как вы узнаете, что разработчик правильно понял требование и передал вам актуальную информацию? QA-инженер – это тот, проверяет ожидаемый результат. Если тестировщик изначально получит не ту информацию, всё тестирование будет поставлено под угрозу. Поэтому, мой совет – хорошо перепроверяйте требования и тщательно выбирайте источник правды. Особенно, когда речь идёт о бизнес-логике продукта.

Сценарий #2: задача связана с технической стороной продукта (например, фронтенд/бэкенд)

Данный сценарий описывает, КАК реализовать эту функцию.

Если какие-то аспекты данной задачи непонятны для QA, ему/ей придётся сотрудничать с разработчиком, который и составлял эту техническую задачу. В результате их разговора должна появится ясность, а суть того, что нужно протестировать - донесена до тестировщика.

Часто QA-инженер не единственный, кто получает пользу из подобных обсуждений. Разработчик также получает представление о том, что следует учитывать при разработке функции, наряду с более глубоким пониманием того, как тестировщик будет выполняет тестирование.

Сценарий #3: есть сомнения, баг это или нет. Кого спросить перед созданием тикета?

Данный сценарий описывает ПОЧЕМУ вы считаете, что это баг.

• базируется ли обнаруженный баг на здравом смысле?
• обнаружены ли доказательства в документации или вы поговорили с менеджером проекта?
• возможно, разработчик не закрывал баг потому, что этого не было указано в требованиях?
• либо разработчик выполнил ту или иную задачу на основе своего собственного видения и опыта?
• отличается ли текущая динамика от других платформ (Web, Android, iOS) и почему?

Перед созданием тикета, в случае сомнений, спрашивайте тестировщика, который больше разбирается в продукте, если вопрос касается бизнес-части – задавайте вопрос менеджеру проекта, а по поводу технической части - разработчику.

В любом случае, мы должны отбросить наши собственные предположения или домыслы разработчика, и вместо этого, спросить у дизайнеров и руководства, как на самом деле должна вести себя эта функция.

Сценарий #4: баг возвращён разработчиком с комментарием «это не баг, а фича»

Вносились ли изменения в дизайн или требования, без фактического обновления, а тестировщик располагает устаревшей информацией? Если так, то это коллективная ошибка.

В других случаях, как по мне, подобный сценарий не очень хорош для репутации QA (особенно если вы достаточно долго работаете над проектом, чтобы знать о продукте всё).  Получается, тестировщик никогда не проходит через сценарий №3. В результате, разработчик начинает работать над так называемым багом и после собственного анализа понимает, что это и не баг вовсе. Думаю, единственное, что в этот момент испытывают разработчики – разочарование, раздражение и даже гнев. Время потрачено впустую. Решение заключается в том, чтобы изначально выяснить с QA, менеджером проекта и дизайнером, баг ли это.  Как только вы это сделаете, станет ясно, закрыть баг или исправить его.

Данные сценарии, на мой взгляд, наиболее распространены. Однако, стоит понимать, что это не полный список. Дайте мне знать, если вы знаете другие сценарии, которые будут полезны для QA-инженера и дадут возможность чувствовать себя более подготовленными и уверенными в работе.   

Помните, дополнительная информация, полученная извне, может развеять сомнения и пролить свет на то, как всё должно работать.

Оригинал статьи: https://medium.com/@yuliia-kuprii/where-a-tester-gets-answers-in-case-of-uncertainty-c9f1622bf6f