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

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

Меня зовут Евгений Домнин, я QA и постараюсь поделиться видением, что делает баг репорт хорошим. Прошу простить за долгое вступление, давайте начнем.

Заголовок

Старайтесь ответить в названии тикета на три вопроса

1. Где происходит?

2. Что происходит?

3. При каких условиях?

Опытному разработчику достаточно будет только взглянуть на заголовок, чтобы понять в чем дело. Например,

Страница Входа: Не подсвечивается поле при вводе неверного пароля

Окружение

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

Войти на стейдже под аккаунтом админа

К слову о шагах

Шаги воспроизведения

Один из главных разделов, инструкция по воспроизведению бага. Я выделю два подраздела, на которые обратим внимание. Это оформление шагов (визуальное) и наполнение (данные внутри)

Визуальная часть

Сохраняйте структуру

Есть разные вариации баг репорта, но классически в нем должны быть следующие подразделы:

1. Шаги

2. Ожидаемый результат

3. Фактический результат

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

Используйте нумерованный список

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

По возможности, пишите без грамматических ошибок.

А теперь к наполнению этих шагов.

Здравый смысл при описании

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

Плохо:

1. Зайти на test.com/login

2. Кликнуть в поле login

3. Ввести логин

4. Кликнуть в поле password

5. Ввести пароль

Хорошо:

1. Перейти на test.com/login и войти под любой учетной записью

Мы не дробим пункты и шаги на то, что и так сделает разработчик, проходя по стандартному флоу. Когда я начинал, то немного зависал на этом пункте, мне казалось, что каждое движение должно быть под пунктом. Не стоит этого делать.

Избегайте неоднозначности

Всегда дополняйте шаги запросом, на который нужно посмотреть на конкретном шаге, пишите конкретную кнопку, на которую нужно нажать (если она с одинаковым названием)

Добавляйте тестовые данные

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

Пройдите по созданным шагам еще раз

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

Ожидаемый результат

Отдельным блоком идет ожидаемый результат, где мы описываем (неожиданно) результат, что ожидается при воспроизведении шагов. Особых рекомендаций тут нет кроме того, что этот блок должен быть – разработчику важно понимать к какому поведению следует привести функциональность. Формулировки по типу, "все должно быть норм" не подходят, пишите конкретное поведение

Фактический результат

Здесь мы пишем, а что произошло на самом деле, когда прошлись по шагам. Здесь тоже важна конкретика. Не стоит писать, что все поломалось (хотя наверное так оно и было). Стоит описать, что за индикаторы говорят, что все сломалось. Например,

Возвращается 500 ошибка по запросу GET /accounts и блокируется UI. Пользователь не может выйти со страницы или кликнуть на элементы. Обновление страницы приводит к повторному запросу и ошибке.

То есть описываем реальный эффект и его влияние на флоу юзера

Дополнительные файлы

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

Скриншоты ошибки

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

Запрос

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

URL ошибки

Собственно сам запрос, можете взять из раздела Network в браузере, котором проходит тестирование

Метод

GET, POST, TRACE, OPTION и так далее – методов немало, как и запросов с одинаковым URL, но разными методами. Не забудьте указать его в тикете

Код ошибки

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

Payload

Это полезная нагрузка запроса, то есть данные, что мы отправили в нашем запросе на сервере. Это есть не в каждом запросе (например, HEAD или GET ими не обладают), но там могут быть причины ошибки

Response

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

Логи из консоли

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

Это все хорошо, но...

Это все хорошо, но где у нас столько времени, чтобы все это красиво оформлять? Сроки горят, менеджер ругается, на проде блокер, а мне предлагается сидеть и еще расписывать все? Просто напишу разрабу в ЛС и все

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

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

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

Если у вас есть вопросы, предложения, несогласия, возмущения – пишите в комментарии, интересно услышать мнение!