Очень часто слышу от коллег разного уровня следующее: "Зачем так подробно расписывать документацию? В частности, баг-репорты. Мы же не разработчики и не должна делать их работу".

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

Наша задача помочь разработчику найти первопричину, а еще лучше указать, что именно нужно исправить.

Поэтому важно писать понятные заголовки, логические и последовательные шаги, результаты и самое главное: добавлять вложения.

И это не просто скрины и видео. Это еще и логи, и HAR-архивы из DevTools, сохраненные сессии из Charles Proxy, примеры скриптов к БД, тестовые данные, которые привели к дефекту.

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

Тот же вопрос к кейсам и чек-листам. Иногда проверяешь работы студентов и вообще ничего не понимаешь. А ведь так быть не должно.

С документацией работают тестировщики разного уровня, ребята из других команд, разработчики, которые могут писать код по тестам, чтобы не упустить негативные сценарии, а иногда и сами клиенты.

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

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

Можно спросить у разработчиков: все ли понятно по багам, что изменить, как оптимизировать.

У компаний уже давно не просто запрос на оператора по запуску кейсов, а на проактивного QA-инженера.

Но если вам нравится хаос, то кто я такой, чтобы его запрещать 😁

#работа#процесс| сайт|материалы по тестированию | видео

В этом посте были ссылки, но мы их удалили по правилам Сетки