Как написать классный баг-репорт

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

Многие могут сказать, что оформить баг-репорт очень просто и не требует специфических знаний, но так ли это просто на самом деле?

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

Давайте рассмотрим элементы баг-репорта по очереди и узнаем, как написать действительно классный репорт!

Заголовок (Title)

Заголовок часто недооценивают, считают ненужным и не заморачиваются при его оформлении. Но тайтл гораздо важнее, чем вы думаете. Почему? Потому что бизнес-аналитики или продакт-менеджеры — те, кто будет расставлять приоритеты в бэклоге, прежде чем углубиться в детали тикета, видят только заголовок. Подумайте например, о внешнем виде бэклога в Jira: что вы видите, когда просматриваете список задач в бэклоге? Что видите на jira-борде? Никакого описания, скриншотов, видео — единственный видимый элемент — это заголовок. Если вы не хотите, чтобы найденный вами баг остался незамеченным (а мы уверены, что вы этого не хотите), заголовок должен выделяться.

Как написать хороший тайтл? Он должен быть достаточно длинным, чтобы сообщить о характере ошибки с разумным уровнем детализации, но не должен содержать лишних и ненужных данных.

Рассмотрим следующий тайтл: «Проблема с кнопкой настроек».

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

Теперь сравните с этим: «Кнопка настроек становится неактивной после клика по ее праовму краю».

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

Описание (Description)

Как правило, чем больше в описании релевантной информации, тем лучше. Обратите внимание на слово «релевантная» — оно является ключевым. Вы должны предоставить всю информацию в том объеме, который облегчает поиск и устранение проблемы.

Наиболее важными элементами описания являются:

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

Почему мы обратили внимание на релевантность информации в описании? Потому что слишком много информации тоже может быть проблемой. Давайте рассмотрим следующий пример:

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

  • Откройте приложение и перейдите в «Личный кабинет»
  • Откройте страницу настроек пользователя и измените аватар
  • Сохраните аватар
  • Попытайтесь установить дату рождения в будущем
  • Увидев сообщение об ошибке, закройте страницу настроек пользователя
  • Закройте приложение
  • Снова откройте приложение
  • Перейдите в «Личную кабинет»
  • Кликните на правый край кнопки «Настройки»
  • Результат: Кнопка «Настройки» переходит в неактивное состояние, хотя должна оставаться активной.

На первый взгляд, описание выглядит правильным и точным, т.е. шаги ясны, подробны и недвусмысленны. Согласны? На самом деле описание содержит нерелевантную информацию. Действительно ли нужно закрыть и снова открыть приложение, чтобы воспроизвети баг? Какое отношение аватар и дата рождения имеют к этой кнопке? А если не пытаться пытаться их изменять? Нужно ли делать эти действия в той же последовательности…? Эти шаги попахивают чем-то подозрительным.

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

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

  • Откройте приложение и перейдите в «Личный кабинет»
  • Кликните на правый край кнопки «Настройки»
  • Результат: Кнопка «Настройки» переходит в неактивное состояние, хотя должна оставаться активной.

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

Устройство / Браузер

Хотя это звучит очевидно, тестировщики часто забывают о разных мелких деталях. Помните: устройства имеют не только названия, но и версии программного обеспечения, конкретные разрешения экрана, иногда (в зависимости от проекта) могут быть настроены определенные параметры и т.д. Тип сетевого подключения также может имеет значение.

То же самое касается браузеров — это не только название, но и версия, тип операционной системы, в которой работает браузер, разрешение экрана, установленные расширения — все может быть важно!

Окружение (Environment)

Это поле имеет отношение к среде, в которой проводилось тестирование, т.е. staging, development, UAT, production — и любой ее подтип/версия (в зависимости от проекта). Не забудьте добавить версию приложения! Хороший баг-репорт также будет содержать информацию о том, является ли баг проблемой регрессии (т.е. впервые возникла в последней версии приложения) или это проблема, которая существовала в предыдущих версиях, но не была обнаружена при тестировании прошлых версий. Это очень важно знать. Если ошибка возникла только что, то легче выяснить, что ее вызвало (т.е. одно из последних изменений), но если ошибка не новая (уже существовала в предыдущих версиях), то поиск и исправление могут быть не такими оперативными.

Прикрепленные файлы — скриншоты, видео, логи и т.п. (Attachments)

Частой проблемой, особенно в командах, где работают люди из разных стран с разными языками, является потеря информации при переводе. Формулировки могут различаться в разных командах. Как с этим справиться? Используйте общий язык: скриншоты и видеозаписи. При возникновении сомнений можно посмотреть видео или скриншоты бага.

При добавлении вложения действует то же правило, что и для описания: не прикрепляйте нерелевантную информацию! Представьте себе 5-минутное видео, в котором показан весь процесс регистрации пользователя, работы с приложением, воспроизведения множества сценариев, только для того, чтобы в последние 5 секунд показать, что кнопка «Настройки» становится неактивной! Прикрепите только тот 5-секундный фрагмент видео, который имеет отношение к делу.

Приоритет / Серьезность (Priority / Severity)

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

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

  • Критический (Critical) — работа с приложением либо его частью не может быть продолжена; основной функционал непригоден для использования;
  • Высокий (Major) — значительный баг или отклонение от ожидаемой функциональности;
  • Низкий (Minor) — небольшой баг, для которого существует простой обходной путь; косметические проблемы, такие как ошибки в написании слова, выравнивании текста и т.п.

Вот и все. Если все вышеперечисленные элементы написаны правильно — поздравляем, ваш баг-репорт действительно классный.

Какой была ваша первая зарплата в QA и как вы искали первую работу?

Мега обсуждение в нашем телеграм-канале о поиске первой работы. Обмен опытом и мнения.

Подписаться
Уведомить о
guest

0 комментариев
Межтекстовые Отзывы
Посмотреть все комментарии

Мы в Telegram

Наш официальный канал
Полезные материалы и тесты
Готовимся к собеседованию
Project- и Product-менеджмент

? Популярное

? Telegram-обсуждения

Наши подписчики обсуждают, как искали первую работу в QA. Некоторые ищут ее прямо сейчас.
Наши подписчики рассказывают о том, как не бояться задавать тупые вопросы и чувствовать себя уверенно в новой команде.
Обсуждаем, куда лучше податься - в менеджмент или по технической ветке?
Говорим о конфликтных ситуациях в команде и о том, как их избежать
$1100*
медианная зарплата в QA в июне 2023

*по результатам опроса QA-инженеров в нашем телеграм-канале

Собеседование

19%*
IT-специалистов переехало или приняло решение о переезде из России по состоянию на конец марта 2022

*по результатам опроса в нашем телеграм-канале

live

Обсуждают сейчас