Структуру репорта вы уже знаете: заголовок, шаги, ожидаемое и фактическое. Но правильно заполненные поля ещё не делают репорт хорошим. Есть мнение, что хорошо написанный баг-репорт — половина решения проблемы для разработчика: одну и ту же проблему можно описать так, что останется исправить пару строк кода, — а можно так, что сам автор назавтра не поймёт, что имел в виду. Эта статья — про то, что отличает репорт, который чинят, от репорта, который возвращают.

Сначала понять, потом писать

Всё начинается не с полей формы, а с понимания происходящего. Пока у вас нет чёткого понимания, «что сломалось», писать репорт рано: получится описание внешнего проявления, а не сути.

Рабочая формула — сформулировать проблему в виде трёх ответов: что сделали, что получили, что ожидали получить. «Что сделали» превращается в шаги воспроизведения, «что получили» — в фактический результат, «что ожидали» — в ожидаемый. Формула хороша ещё и тем, что заранее показывает, дефект ли это вообще: если на «что ожидали» вы не можете сослаться ни на требование, ни на здравый смысл, — возможно, приложение ведёт себя правильно.

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

Детализация: у репорта другие правила, чем у кейса

В статье о качестве кейсов мы искали баланс конкретики и общности. В баг-репорте баланс смещён: предпочтение — конкретике. Причина проста: нехватка одной мелкой детали может сделать дефект невоспроизводимым. Если есть хоть малейшее сомнение, важна ли деталь, — считайте, что важна. «Файл допустимого формата, где русский текст в разных кодировках» разработчик не воспроизведёт; «HTML от 100 КБ до 1 МБ, текст в UTF-8 (10 строк) и WIN-1251 (20 строк)» — воспроизведёт с первого раза.

При этом конкретика не значит многословность:

  • Не расписывайте то, что заменяется одной фразой. Четыре шага «указать первый параметр… второй… третий… запустить» сворачиваются в «запустить приложение со всеми тремя корректными параметрами».
  • Не начинайте «с сотворения мира». Вместо шагов «запустить приложение, подождать 30 минут» напишите предусловие: «приложение запущено и проработало более 30 минут» — и оставьте один шаг, который вызывает баг.
  • Убирайте детали, не влияющие на дефект. Если поиск не находит mp3-файлы, неважно, что файл называется song1.mp3 и лежит на диске J:. Как понять, что влияет, а что нет? Исследованием: поймите закономерность поведения — и нужная степень детализации станет очевидной.

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

Один дефект — один отчёт

Два незыблемых правила:

  • В каждом репорте описывается ровно один дефект. Если один дефект проявляется в нескольких местах — проявления перечисляются в подробном описании одного репорта. Если в репорте два дефекта и один починили, а второй нет, — в какой статус переводить отчёт? Неизвестно.
  • Новый дефект — новый репорт. Нельзя описывать новую проблему, переоткрывая старый закрытый репорт: теряется история, ломаются метрики, наступает хаос. Именно поэтому во многих командах переоткрывать отчёты может ограниченный круг людей.

Дубликаты: искать до, а не оправдываться после

Когда тестировщиков много (или память коротка), один дефект описывают дважды. Защита:

  • Ищите перед заведением. Поиск в трекере по ключевым словам — обязательный шаг перед созданием репорта.
  • Пишите информативные заголовки — поиск идёт в первую очередь по ним. Десяток репортов «Кнопка не работает» превращают каждый следующий поиск в перебор вручную.
  • Указывайте в описании текст сообщений приложения — по точному тексту ошибки дубликат находится даже тогда, когда всё остальное описано слишком общо.
  • Нашли дополнительную информацию по уже заведённому багу — дополните существующий репорт, а не создавайте новый.

Типичные ошибки

Ошибки оформления:

  • Заголовки-загадки: «Неожиданное прерывание», «Найдено 19 элементов», «В приложении красный шрифт». Что за проблема? Где? При каких условиях? Непонятно.
  • Игнорирование кавычек: «запись исчезает при наведении мыши» пугает, пока не узнаешь, что исчезает поле с названием «Запись». Кавычки показывают, что это имя элемента.
  • Скриншот всего экрана без отметок. Обведите проблемное место — скорость понимания вырастает в разы. И прикладывайте сам файл, если баг связан с файлом: репорт «неверно обрабатывается файл» без файла бесполезен.
  • Откладывание «на потом». Нашли пять багов, решили описать вечером — к вечеру детали (а иногда и сами баги) забыты. Описывайте сразу.

Логические ошибки — опаснее:

  • Выдуманные дефекты. В требованиях нигде не сказано, что приложение должно это делать, — а репорт заведён, потому что оно этого не делает. Ожидаемый результат берётся из требований или здравого смысла, не из фантазии.
  • Жаргон и критика вместо описания. «Фигово подцепились чартники» или «ну и кто такое писал?!» — репорт описывает проблему с приложением, а не качества коллег.
  • Концентрация на мелочах в ущерб главному. Хрестоматийный случай: тестировщик нашёл краш с потерей данных, но завёл его как косметический дефект — в предсмертном сообщении об ошибке была опечатка. Всегда спрашивайте себя: как это влияет на пользователя?
  • Заниженная важность. Тщательно исследуйте наиболее опасные последствия дефекта и аргументированно отстаивайте оценку — чрезмерно заниженный репорт может месяцами ждать своей очереди.
  • Смирение с воспроизводимостью «иногда». «Иногда» означает, что настоящая причина не найдена: с таким дефектом всем — и вам, и разработчику — придётся работать на веру. Продолжайте искать закономерность: дополнительные тесты, похожая функциональность, консультации с коллегами. Процент «невоспроизводимых» дефектов можно приблизить к нулю.

Где это применяется

Судьба вашего бага решается качеством репорта. Хороший репорт чинят за минуты и без вопросов; плохой возвращается с резолюциями «не воспроизводится» и «не является дефектом» — и время теряют все. А ещё по репортам о вас судят: их читает вся команда, каждый день.

Где спотыкаются начинающие:

  • Пишут репорт, не поняв сути. Описано внешнее проявление («иногда обрабатываются случайные файлы»), а не закономерность — воспроизвести невозможно.
  • Переносят привычку кейсов в репорты — оставляют «осмысленную свободу» в шагах. В репорте свобода вредна: сомневаетесь — конкретизируйте.
  • Заводят репорт на функциональность, которая ещё не объявлена готовой к тестированию, — констатируя, что не работает то, что и не должно было (пока!) работать.

Что учить дальше. Куда репорт отправляется после создания и какие статусы проходит — в статье про жизненный цикл бага; как оценить, насколько дефект серьёзен и срочен, — в статье про severity и priority.