Как составить понятный и структурированный баг-репорт с помощью TMS DoQA
В разработке программного обеспечения любая ошибка может обернуться потерей времени и ресурсов, и поэтому тестировщикам жизненно необходим навык грамотного составления баг-репортов. Недостаточно четкие и полные отчеты о багах затягивают сроки исправления и приводят, в конечном итоге, к снижению качества продукта.
Признаки хорошего баг-репорта
Хороший баг-репорт должен отражать, что именно и почему произошло в системе, и соответствовать пяти основным критериям.
1. Лаконичность.
Баг-репорт должен быть достаточно детализированным, но при этом максимально кратким и содержать только необходимые в конкретном случае данные.
2. Полнота.
Необходимый минимум информации для баг-репорта: название, отражающее проблему, шаги для воспроизведения ошибки, ожидаемый и фактический результаты и доказательства бага. В TMS эти поля, как правило, обязательны для заполнения. При этом система управления тестированием не ограничивает тестировщика в добавлении дополнительных данных, в том числе вложений.
3. Воспроизводимость.
Важно, чтобы дефект можно было вызвать повторно. На первый взгляд, данных в баг-репорте может быть достаточно, но баг не получится воспроизвести. В процессе может оказаться, что для этого нужен, например, специфический девайс или окружение. В таком случае нужно сузить круг и локализовать все, что происходит в тестируемой системе.
4. Понятность.
Баг должен быть описан недвусмысленно, так, чтобы его можно было воспроизвести. Одна из самых распространенных ошибок — написание баг-репорта не техническим, а художественным, разговорным языком. Это делает документ менее информативным и вносит сумбур в баг-трекинг. Хорошей практикой является дополнение баг-репорта скриншотами или видео — иногда лучше один раз увидеть.
5. Атомарность.
В баг-репорте должен быть описан только один дефект.
Структура баг-репорта
Обычно при составлении баг-репорта применяется стандартный шаблон, в который могут включаться дополнительные атрибуты, например, поля для сбора метрик или фильтрации документов. Перед началом работы убедитесь, что найденный вами дефект еще не был зарегистрирован в системе.
В форме баг-репорта в TMS DoQA есть все необходимое для сбора данных об ошибках, а часть полей предзаполнена автоматически, чтобы сэкономить время.
Заголовок. Он должен кратко описывать суть проблемы, чтобы разработчики могли по одному названию баг-репорта понять, что произошло.
Фактический результат — что произошло после воспроизведения шагов.
- Ожидаемый результат — что должно было произойти после воспроизведения шагов.
Описание (например, версия и окружение) и подробные шаги воспроизведения бага.
Окно загрузки файлов, подтверждающих возникновение ошибки, например, видео, скриншотов или логов.
Иногда некоторых атрибутов в баг-репорте может не быть — существуют плавающие баги, а также баги, которые сложно отловить, локализовать и найти шаги для воспроизведения.
Помимо стандартных полей форма баг-репорта в TMS DoQA содержит приоритет, статус и возможность установить связь с баг-трекером.
Приоритет — для помощи разработчикам в определении приоритетности устранения ошибки.
В решении, какой приоритет поставить багу, может помочь классификация багов по уровню влияния на систему.
Блокер (Blocker) — баг, из-за которого система не работает вообще: сайт выдает «ошибку 404», а приложение не запускается.
Крит (Critical) — баг, который серьезно влияет на главную функцию системы. Например, если в приложении для хайкинга невозможно проложить маршрут.
Мажор (Major) — баг, из-за которого неудобно использовать систему, но основные функции при этом работают.
Минор (Minor) — баг, который не нарушает логику системы, но ухудшает пользовательский опыт. Например, неинтуитивный интерфейс.
Тривиальный (Trivial) — баг, не требующий срочного исправления, так как не влияет на работу системы. Его можно пофиксить при исправлении других ошибок. Например, тривиальным багом может быть малозаметная опечатка в меню приложения.
Также приоритетность бага зависит от приоритетов команды и бизнеса. Бизнесу важны действия пользователя, которые приносят доход и сокращают расходы. Если на этом пути возникает даже самый незначительный баг, например, неправильный шрифт или опечатка, то он будет считаться критичным, потому что находится на критически важном пути.
В то же время крэш, который стабильно воспроизводится в редко используемой побочной функциональности приложения и затрагивает минимальное количество пользователей, не будет критическим, потому что на бизнес в данный момент это не оказывает влияния.
Статус — для понимания, на каком этапе жизненного цикла находится баг.
После создания баг-репорт уходит в работу, разработчик вносит исправления, фикс проходит код-ревью и попадает на тестирование, после которого поступает в продакшн. На любой стадии процесс может откатиться назад, если баг не будет устранен — форма баг-репорта в DoQA это предусматривает и дает возможность менять статус.
Возможность установить связь с трекером — Jira, YouTrack или Yandex Tracker (в разработке интеграции с Битрикс24 и Redmine) — чтобы баг-репорт автоматически отображался в связанной системе.
В сохраненном баг-репорте отображается автор и дата создания. По ссылкам на прогон и тест-кейс или чек-лист удобно прослеживать, к какой документации относится баг-репорт.
Грамотное составление баг-репортов — не просто технический навык, а важнейший элемент успешной работы команды. Хорошо написанный отчет о баге может сэкономить часы, а то и дни работы, позволяя разработчикам сосредоточиться на решении более приоритетных проблем.
Присоединяйтесь к TMS DoQA, чтобы оптимизировать составление баг-репортов — мы предоставляем 30 дней бесплатного пользования без ограничений по функциональности.
Больше экспертных материалов о тестировании — в Telegram-канале.