Что такое баг-репорт: структура, виды дефектов и правила оформления

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

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

Документ хранится в баг-трекинговой системе — Jira, Яндекс Трекере или YouTrack. Каждый баг-репорт проходит жизненный цикл: от статуса Open до Closed.

Почему нельзя ограничиться мессенджером? Сообщение в чате теряется, не отслеживается, не попадает в статистику качества. Баг-репорт решает три задачи: формализует информацию, делает её отслеживаемой и даёт метрики для оценки качества продукта. Без него команда работает вслепую.

Баг, дефект и сбой: терминология по ISTQB

Международный стандарт квалификации тестировщиков ISTQB разграничивает три понятия. Ошибка — неверное действие разработчика при написании кода. Дефект — изъян в самом коде, возникший из-за этой ошибки. Сбой — последствие выполнения кода с дефектом: то, что видит пользователь.

В повседневной речи все три понятия объединяют словом «баг». В официальной документации и тикетах точнее использовать термин «дефект».

Прежде чем создавать баг-репорт, специалист выполняет локализацию: подтверждает, что наблюдаемое поведение — именно дефект, а не особенность конфигурации или ожидаемая функция.

Виды дефектов программного обеспечения

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

Функциональные и нефункциональные дефекты: полная классификация

Семь типов дефектов охватывают большинство ситуаций, с которыми сталкивается QA-инженер в работе.

Отдельный подвид логического дефекта — «баг требований»: код написан верно, но техническое задание изначально не отражало реальные нужды бизнеса.

Серьёзность и приоритет дефекта: в чём принципиальная разница

Серьёзность (severity) и приоритет (priority) — разные измерения, и смешивать их нельзя. Серьёзность показывает, насколько дефект влияет на работу системы; её определяет тестировщик. Приоритет — срочность исправления с точки зрения бизнеса; его назначает продукт-оунер или менеджер.

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

Пять уровней серьёзности (S0–S4)

Уровень серьёзности зависит не только от критичности самого дефекта, но и от охвата: блокирующий баг у 80% пользователей и тот же дефект в редком сценарии — разные истории с точки зрения серьёзности.

Три уровня приоритета (P1–P3) и кто их определяет

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

Структура баг-репорта: обязательные и дополнительные поля

Стандартный баг-репорт содержит двенадцать полей. Пять из них обязательны — без них разработчик не сможет воспроизвести и устранить дефект. Остальные добавляются согласно стандартам команды.

Тип вложения зависит от вида дефекта: визуальный баг — скриншот, функциональный — лог, дефект UX — скринкаст с записью взаимодействия. Чем точнее вложение, тем быстрее разработчик локализует проблему.

Образцы баг-репортов: шаблон и готовые примеры

Разобраться со структурой проще через конкретные примеры. Ниже — два уровня детализации: базовый для начинающих и корпоративный образец для команды, работающей с 1С. Оба корректны — глубина описания растёт вместе с опытом специалиста.

Пример начинающего и опытного QA: два уровня детализации

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

Баг-репорт для 1С: корпоративный образец

Для 1С-команд важны специфические поля: конфигурация (например, «Бухгалтерия предприятия 3.0»), версия платформы и режим работы — тонкий или толстый клиент.

Для 1С-команд удобен Яндекс Трекер: русскоязычный интерфейс и интеграция с отечественными корпоративными системами.

Жизненный цикл дефекта: от Open до Closed

Дефект проходит через семь статусов. Каждый отражает, на чьей стороне сейчас задача.

Open — тестировщик зафиксировал и открыл тикет. In Progress — разработчик взял дефект в работу. Fixed — исправление внесено, ожидается ретест. Closed — тестировщик подтвердил: дефект устранён.

Три ветки отклонения. Rejected — тикет некорректен: дефект не воспроизводится или поведение является ожидаемым. Deferred — дефект отложен из-за низкого приоритета или ресурсных ограничений. Reopened — дефект возвращён в работу после отсрочки или после того, как ретест показал: исправление не сработало.

Если после закрытия тот же дефект обнаруживается снова — открывают новый тикет. Тот же жизненный цикл начинается заново.

Инструменты для ведения баг-репортов онлайн

Большинство команд ведут баг-репорты в специализированных онлайн-системах. Выбор зависит от масштаба команды и требований к интеграциям.

Jira — де-факто стандарт крупных IT-команд. Гибкая настройка статусов, рабочих процессов и интеграций. Яндекс Трекер — российская альтернатива с похожим функционалом, популярна в отечественных командах. YouTrack (JetBrains) — хорошо подходит для средних команд, особенно работающих в экосистеме JetBrains. Trac и Mantis — более лёгкие решения для небольших проектов.

Некоторые малые команды начинают с Telegram-ботов: они отправляют уведомления о новых дефектах прямо в чат. Удобно на старте, но мессенджер не обеспечивает полноценного отслеживания и аналитики — со временем баг-трекинговая система становится необходимостью.

Как правильно составить баг-репорт: советы и частые ошибки

Качественный баг-репорт сокращает число уточнений и ускоряет исправление. Семь правил, которые работают на любом уровне опыта.

1. Сначала локализуй. Убедись, что это дефект, а не особенность конфигурации или ожидаемая функция.
2. Точный заголовок. Что происходит, где и при каких условиях. «Кнопка не работает» — плохо. «При нажатии «Оплатить» не открывается форма карты» — хорошо.
3. Минимально необходимые шаги. Убери лишнее. Если баг воспроизводится за три шага — не пиши восемь.
4. Прикладывай вложения. Скриншот, лог или скринкаст снимают половину вопросов ещё до созвона.
5. Смотри с точки зрения бизнеса. Дефект на странице оплаты важнее косметического бага в подвале сайта.
6. Проверяй на нескольких устройствах и версиях. Если воспроизводится только на одном — укажи явно.
7. Используй командный шаблон. Единый формат ускоряет работу всей команды: меньше разнобоя, больше предсказуемости.

Типичные антипаттерны:

• расплывчатый заголовок без указания места и условий;
• нет шагов воспроизведения — разработчик не может подтвердить дефект;
• пропущены предусловия — баг не воспроизводится из-за разного начального состояния системы;
• нет окружения — непонятно, на каком устройстве или браузере проявляется проблема.

Чёткий баг-репорт — меньше уточнений, быстрее исправление.

Хотите разобраться в тестировании ПО на практике и войти в IT-профессию? В ProfiFuture можно пройти программу тестировщика программного обеспечения за 1,5 месяца с господдержкой — 75% стоимости компенсируется образовательной квотой. Онлайн, без отрыва от работы, документ государственного образца по окончании.

Часто задаваемые вопросы

Что такое баг-репорт простыми словами?

Баг-репорт — структурированный технический документ, который QA-специалист заполняет при обнаружении ошибки в программе. Содержит описание проблемы, шаги воспроизведения, фактический и ожидаемый результат. Хранится в баг-трекинговой системе. Благодаря репорту разработчик получает всё необходимое для устранения дефекта, не тратя время на дополнительные уточнения.

Чем баг отличается от дефекта и сбоя по ISTQB?

По стандарту ISTQB: ошибка — неверное действие разработчика; дефект — изъян в коде, возникший из-за этой ошибки; сбой — последствие выполнения кода с дефектом. В разговорной речи все три понятия объединяют словом «баг». В официальной документации и тикетах корректнее использовать термин «дефект».

Какие поля обязательны в баг-репорте?

Пять обязательных полей: заголовок (суть проблемы одним предложением), шаги воспроизведения, фактический результат, ожидаемый результат, окружение (ОС, браузер, версия приложения). Поля ID, серьёзность, приоритет, вложения и назначение исполнителя добавляются согласно стандартам конкретной команды.

В чём разница между серьёзностью и приоритетом дефекта?

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

Какие статусы проходит дефект в жизненном цикле?

Семь ключевых статусов: Open (зафиксирован), In Progress (в работе), Fixed (исправлен, ожидает ретеста), Closed (ретест подтвердил исправление), Rejected (репорт некорректен или дефект не воспроизводится), Deferred (отсрочен из-за низкого приоритета), Reopened (взят в работу после отсрочки). Конкретный набор зависит от настроек баг-трекинговой системы.

В каких программах ведут баг-репорты онлайн?

Наиболее распространённая система — Jira, де-факто стандарт в крупных IT-командах. Среди российских альтернатив активно используется Яндекс Трекер. Также применяют YouTrack (JetBrains), Trac, Mantis. В малых командах иногда начинают с мессенджеров, но это снижает отслеживаемость и осложняет аналитику дефектов.

Что делать, если баг не воспроизводится?

Проверьте предусловия (точные данные, окружение, версию ПО), попробуйте несколько устройств и браузеров, соберите логи в момент сбоя. Если воспроизведение нестабильно — зафиксируйте все попытки и их результаты в репорте явно. Разработчик получит статус «Cannot Reproduce» и проведёт самостоятельное расследование.

Как правильно написать заголовок баг-репорта?

Эффективный заголовок отвечает на три вопроса: что происходит, где и при каких условиях. Плохо: «Кнопка не работает». Хорошо: «При нажатии «Оплатить» на шаге подтверждения заказа не открывается форма ввода данных карты». Цель — разработчик должен понять суть дефекта без чтения всего репорта.

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

Кто выполняет эту работу и какие навыки нужны — в обзоре про то, кто такой тестировщик.