Баг-репорт: из чего состоит, пример и как написать

Что такое баг-репорт и из чего он состоит

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

Набор полей зависит от компании и баг-трекера, но основа везде одна. Ниже атрибуты из урока, которые встречаются почти в любом отчёте.

• Заголовок (summary)

  Коротко описывает проблему и отвечает на три вопроса: где, что и когда. Сначала идёт место (модуль или страница), потом то, что произошло, и условия, при которых это случилось.

• Шаги воспроизведения (steps to reproduce, STR)

  Действия по порядку, пройдя которые, любой человек увидит тот же результат. Стоит уложиться в 7–10 шагов, а лучше в меньшее число, но не склеивать шаги, которые логически не объединяются.

• Фактический и ожидаемый результат

  Фактический (actual result) описывает, что получилось после шагов. Ожидаемый (expected result) описывает, что должно быть по требованиям, и рядом обязательно ставят ссылку на требование или макет, из которого это следует.

• Окружение (environment)

  Операционная система с версией и разрядностью, браузер с версией и стенд, на котором найден дефект: dev у разработчиков, stage со стабильной версией для тестирования или prod, где работают пользователи. Например, кнопка "Оплатить" в приложении доставки не нажимается только в Safari на iPhone, а в Chrome всё работает. Без окружения в отчёте разработчик проверит в Chrome и закроет баг с резолюцией Works for me.

• Серьёзность и приоритет

  Severity показывает, насколько дефект влияет на систему, а priority задаёт очередь исправления. Подробнее о них в следующем разделе.

• Вложения (attachments)

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

• Служебные поля

  Проект, компонент, версия сборки, автор (reporter), исполнитель (assignee), метки, связанные задачи и версия исправления (fix version). Её заполняет разработчик, когда баг исправлен.

• Статус

  Положение бага в жизненном цикле. Новый баг получает статус New, после назначения разработчику становится Open (Assigned), после исправления Resolved, после проверки тестировщиком Verified и в конце Closed. Если дефект воспроизводится снова, его переоткрывают (Reopened). У статуса Resolved бывают разные резолюции: Fixed, Duplicate, Won't fix, Works for me, As designed.

Severity и priority: в чём разница

Серьёзность (severity) – это степень влияния дефекта на работу системы, и её обычно выставляет тестировщик. Приоритет (priority) задаёт очередь исправления, то есть какой баг чинить первым. Его ставит менеджер проекта, а если менеджера нет, то ведущий тестировщик, сам тестировщик или аналитик, который знает, какие функции заказчику нужны в первую очередь.

Самая распространённая шкала приоритета – High, Medium и Low. Баг с High исправляют как можно быстрее, Medium тоже обязательно исправляют, хотя он не критичен, а исправление Low можно отложить, пока есть более срочные. В некоторых системах приоритет и серьёзность обозначают цифрами от 1 до 4, и единицу исправляют первой. В стандартной форме Jira поля severity нет, его добавляют на проекте, а приоритет там идёт от Highest до Lowest.

Серьёзность и приоритет не обязаны совпадать, и пример такого расхождения часто просят на собеседовании. Высокая серьёзность при низком приоритете бывает, когда сломана функция, которой почти никто не пользуется: тестировщик ставит critical, а менеджер откладывает исправление, потому что без этой функции пока можно обойтись. Обратный пример – опечатка на главной странице Google, где в названии одна буква o вместо двух. На работу сайта она не влияет, но бьёт по репутации бренда, поэтому приоритет у неё высокий.

Шкала серьёзности на разных проектах своя, где-то нет blocker, где-то trivial. Чаще всего встречается такая.

• Blocker (блокирующий)

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

• Critical (критический)

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

• Major (значительный)

  Серьёзное отклонение от бизнес-логики или нарушение работы без критических последствий. Часто есть обходной путь (workaround), которым функцию всё же можно выполнить.

• Minor (незначительный)

  Функциональность не нарушена, но результат расходится с ожидаемым, например в дизайне.

• Trivial (тривиальный)

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

Пример баг-репорта

В уроке баг заводится в Jira на учебном проекте: на странице входа после щелчка по пустому месту страницы съезжает кнопка Sign in. Бесплатную учебную версию Jira можно завести на сайте Atlassian и повторить всё самому.

Шаги нумеруют списком, а заголовки блоков STR, Actual result и Expected result выделяют жирным, чтобы разработчик сразу видел структуру. Actual result я пишу теми же словами, что и заголовок.

• Summary

  Login page: The Sign in button is displaced after clicking on the page. Login page отвечает на вопрос "где", смещение кнопки на вопрос "что", щелчок по странице на вопрос "когда".

• Steps to reproduce

  1. Open the Login page. 2. Navigate to the Sign in button. 3. Click on the page.

• Actual result

  The Sign in button is displaced after clicking on the page.

• Expected result

  The Sign in button is located on the page according to mockups. Рядом ставят ссылку на макет, например в Figma.

• Environment

  Windows 10 с разрядностью системы и Google Chrome с номером версии из справки браузера.

• Priority и severity

  Дефект интерфейсный и на работу не влияет, поэтому приоритет Low или даже Lowest, а серьёзность trivial.

• Attachment

  Скриншот, на котором кнопка обведена красной рамкой. Бесплатный скриншотер ShareX и платный Snagit позволяют сразу добавить рамку, стрелку и подпись.

• Связи и спринт

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

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

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

Заголовок я начинаю с названия модуля и двоеточия, например User info: The Undo button is disabled after clicking the Save button. По модулю баг потом проще найти в трекере.

• Порядок слов

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

• Пассивный залог

  В заголовке, описании и результатах действие происходит с элементом: кнопкой, страницей, запросом. Поэтому пишут The Undo button is disabled. В активном залоге The Undo button disables непонятно, кнопка что-то отключает или отключается сама. Предусловие о пользователе, созданном заранее, пишут в прошедшем времени: was created.

• Артикль the

  В отчёте почти всегда говорят о конкретном предмете, о кнопке, запросе или пользователе, поэтому по умолчанию ставят определённый артикль the. A и an нужны, когда предмет появляется в тексте впервые.

• Глагол в начале шага

  Шаги начинаются с глагола в начальной форме: Open, Click, Select. По-русски шаги так же пишут инфинитивом ("открыть", "нажать") без "открой" и "нажми", чтобы действие не было привязано к конкретному человеку.

• Предлоги

  Click on the Save button и Click the Save button одинаково допустимы. Другие предлоги вроде in или at с кнопкой не ставят.

Локализация дефекта

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

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

Пример из интернет-магазина: при оформлении заказа приходит ошибка 500. В Network видно, что запрос POST /api/orders уходит с полем promo_code. Тестировщик повторяет заказ без промокода, с действующим и с просроченным, и ошибка возникает только с просроченным. Заголовок бага тогда звучит как "Checkout: 500 error when applying an expired promo code", и разработчик сразу знает, где искать.

Найденное добавляют в комментарий к баг-репорту или пишут разработчику. Иногда сам баг заводят уже по настоящей причине, например "пропал доступ к базе данных" вместо "ошибка 500". Если времени в обрез, глубокая локализация подождёт, но для критичных дефектов она окупается.

• Запрос и ответ в DevTools

  На вкладках Network и Console видно, правильный ли эндпоинт, какие данные ушли в теле запроса и что вернулось. Смотрят не только статус-код, но и тело ответа с сообщением об ошибке.

• База данных

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

• Логи

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

• Простые проверки

  Подключён ли интернет и не мешает ли кэш. Так тестировщик проверяет, что баг действительно воспроизводится.

• Мобильные приложения

  Здесь заглядывают в логи самого приложения и в отчёты о падениях (crash logs).

• СтатьяDevTools для тестировщика

Видеоуроки, шпаргалки и тренажёры

Я разбираю баг-репорт в десятом уроке курса "Тестировщик с нуля" на YouTube: атрибуты, severity и priority, заведение бага в Jira и жизненный цикл дефекта. Отдельные ролики посвящены баг-репортам на английском и локализации дефекта. В бесплатном базовом курсе по тестированию тема идёт уроком "Отчеты о дефектах. Jira", и после теории в нём есть задания.

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

• Урок курсаЭтот урок с заданиями – бесплатно
• Мой видеоурокотчёт о дефекте в Jira, severity и priority
• Мой видеоуроккак писать баг-репорт на английском
• Мой видеоурокчто такое локализация дефекта
• Шпаргалкабаг-репорт
• Шпаргалкажизненный цикл бага
• Тренажёрошибки в баг-репортах
• Тренажёрна каком слое архитектуры дефект
• СтатьяЧек-лист и тест-кейс: шаги в них пишут так же

Курсы по теме

• бесплатный

  Тестирование ПО с нуля. Теория + Практика. Базовый уровень

  Первое рабочее место тестировщика

  89 уроков113 441

Вопросы и ответы