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

Почему это важно?

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

Знакомо? Именно поэтому в тестировании существует особый документ — баг-репорт (от английского bug report, то есть «отчёт об ошибке»). Это не просто жалоба на то, что что-то пошло не так. Это точная, структурированная запись, которая позволяет другому человеку воспроизвести ошибку — то есть повторить те же шаги и увидеть ту же проблему.

Без правильно написанного баг-репорта разработчик не может исправить ошибку. Хорошо написанный баг-репорт — это половина решения проблемы.

Теория

Что такое баг?

Баг (от английского bug — «жучок») — это ошибка в программе, из-за которой она работает не так, как должна. Программа «ожидает» одно поведение, а на деле происходит другое.

Примеры багов:

Кнопка не реагирует на нажатие.
После ввода неправильного пароля приложение вылетает (закрывается само по себе) вместо того, чтобы показать сообщение об ошибке.
Цена товара в корзине отображается как «0 рублей».
На экране появляется текст «Error 500» вместо страницы с товарами.

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

Что такое баг-репорт?

Баг-репорт — это документ (карточка, запись), в котором тестировщик подробно описывает найденную ошибку. Он должен быть написан так, чтобы любой другой человек — разработчик, менеджер, другой тестировщик — мог:

Понять, что именно не работает.
Самостоятельно воспроизвести (повторить) ошибку.
Оценить, насколько эта ошибка серьёзна.

Структура баг-репорта

Хороший баг-репорт состоит из нескольких обязательных частей. Давайте разберём каждую из них.

1. Заголовок (Title / Summary)

Это краткое, но ёмкое описание ошибки — одна фраза, из которой сразу понятно, в чём проблема.

Плохой заголовок:

«Кнопка не работает»

Хороший заголовок:

«Кнопка "Оформить заказ" не реагирует на нажатие на странице корзины в мобильном браузере Chrome»

Правило хорошего заголовка: что сломалось + где сломалось + при каких условиях (если это важно).

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

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

Сюда входит:

Устройство — телефон, компьютер, планшет. Модель, если важно (например, iPhone 13).
Операционная система — Windows 11, macOS, Android 12, iOS 16 и т. д.
Браузер и его версия — Chrome 124, Firefox 115, Safari и т. д. (если тестируется веб-сайт).
Версия приложения — например, «версия 2.4.1».

Аналогия. Если вы звоните в сервисный центр и говорите «мой телевизор не включается», первое, что они спросят: «Какая модель? Сколько лет? Что делали перед этим?» Это и есть «окружение».

3. Шаги воспроизведения (Steps to Reproduce)

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

Правила хороших шагов:

Каждый шаг — отдельное действие.
Шаги нумеруются.
Описание конкретное: не «войти в приложение», а «открыть приложение, ввести логин [email protected] и пароль Test1234, нажать кнопку "Войти"».
Шаги должны быть воспроизводимы — любой человек, следуя им, должен увидеть ту же ошибку.

4. Ожидаемый результат (Expected Result)

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

Пример: «После нажатия кнопки "Оформить заказ" пользователь должен перейти на страницу подтверждения заказа».

5. Фактический результат (Actual Result)

Фактический результат — это то, что реально произошло. Именно это и есть баг.

Пример: «После нажатия кнопки "Оформить заказ" ничего не происходит — страница не обновляется, никаких сообщений не появляется».

6. Серьёзность (Severity) — уровень критичности

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

Аналогия. Представьте ресторан. Если на кухне пожар — это катастрофа, ресторан не может работать. Если у официанта пятно на рубашке — это неприятно, но ресторан продолжает работать. Серьёзность — это как раз оценка масштаба проблемы.

Обычно используют следующие уровни:

Уровень	Название	Что означает	Пример
S1	Blocker (Блокирующий)	Приложение полностью не работает, тестирование невозможно	Приложение вылетает при запуске
S2	Critical (Критический)	Основная функция сломана, обходного пути нет	Нельзя оплатить заказ
S3	Major (Серьёзный)	Важная функция работает неправильно, но есть обходной путь	Фильтр товаров не работает, но можно искать вручную
S4	Minor (Незначительный)	Небольшая проблема, не мешает основной работе	Опечатка в тексте кнопки
S5	Trivial (Тривиальный)	Косметический дефект, почти незаметен	Отступ между элементами на 2 пикселя больше, чем в макете

7. Приоритет (Priority)

Приоритет (Priority) — это оценка того, насколько быстро нужно исправить ошибку. Это бизнес-характеристика, которую обычно устанавливает менеджер или тимлид.

Важно для начинающих: Серьёзность и приоритет — разные вещи! Путаница здесь очень распространена.

Пример разницы:

На сайте интернет-магазина опечатка в имени генерального директора в разделе «О компании». Серьёзность — Trivial (технически почти не влияет). Приоритет — High (директор требует исправить немедленно).
Кнопка «Экспорт в PDF» не работает. Серьёзность — Major. Приоритет — Low (этой функцией пользуется 2% пользователей, можно починить в следующем релизе).

Уровни приоритета:

High (Высокий) — исправить как можно скорее.
Medium (Средний) — исправить в ближайшем обновлении.
Low (Низкий) — исправить когда будет время.

8. Вложения (Attachments)

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

Скриншот — снимок экрана с ошибкой.
Видеозапись — особенно полезна для ошибок, которые сложно описать словами.
Логи — технические записи о работе программы (актуально для более продвинутого уровня).

Скриншот стоит тысячи слов. Если есть возможность — прикладывайте всегда.

Сводная таблица: из чего состоит баг-репорт

Поле	Обязательно?	Назначение
Заголовок	✅ Да	Быстро понять суть проблемы
Окружение	✅ Да	Воспроизвести в нужных условиях
Шаги воспроизведения	✅ Да	Повторить ошибку
Ожидаемый результат	✅ Да	Понять, как должно быть
Фактический результат	✅ Да	Понять, что сломалось
Серьёзность	✅ Да	Оценить масштаб проблемы
Приоритет	✅ Да	Решить, когда чинить
Вложения	Желательно	Наглядно показать ошибку

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

Давайте посмотрим на реальный пример. Представим, что мы тестируем простой интернет-магазин.

БАГ-РЕПОРТ #042

Заголовок:
  При добавлении 10 и более единиц товара в корзину
  итоговая сумма отображается как «0 ₽»

Окружение:
  - Устройство: Ноутбук ASUS VivoBook
  - ОС: Windows 11 Home
  - Браузер: Google Chrome 124.0.6367.82
  - Версия приложения: 3.1.0 (тестовая среда)

Шаги воспроизведения:
  1. Открыть сайт: https://shop-test.example.com
  2. Перейти в каталог → раздел «Электроника».
  3. Открыть карточку товара «Наушники беспроводные», цена 2 990 ₽.
  4. В поле «Количество» ввести значение «10».
  5. Нажать кнопку «Добавить в корзину».
  6. Перейти в раздел «Корзина» (значок в верхнем правом углу).
  7. Посмотреть на строку «Итого».

Ожидаемый результат:
  В строке «Итого» отображается сумма 29 900 ₽
  (2 990 ₽ × 10 = 29 900 ₽).

Фактический результат:
  В строке «Итого» отображается «0 ₽».
  При этом количество товара (10 шт.) показано корректно.

Серьёзность: S2 — Critical
  (Основная функция — расчёт суммы заказа — работает некорректно.
  Пользователь не может узнать реальную стоимость своего заказа.)

Приоритет: High
  (Ошибка напрямую влияет на оформление покупок — ключевой
  бизнес-процесс сайта.)

Вложения:
  - screenshot_cart_zero_sum.png (скриншот корзины с суммой «0 ₽»)

Разбор примера

Обратите внимание на несколько вещей:

Заголовок сразу говорит нам, что именно сломалось («итоговая сумма = 0 ₽»), при каком условии («10 и более единиц»).
Шаги написаны так конкретно, что их может повторить человек, который никогда не видел этот сайт. Указан точный URL, конкретный товар и точное значение в поле.
Ожидаемый и фактический результат чётко разведены. Мы не просто пишем «не работает» — мы показываем разрыв между ожиданием (29 900 ₽) и реальностью (0 ₽).
Серьёзность обоснована: объяснено, почему это Critical, а не просто поставлена галочка.

Частые ошибки начинающих

Вот что чаще всего делают не так при написании первых баг-репортов:

❌ Нечёткие шаги: «Зайти на сайт, попробовать купить что-нибудь» — разработчик не сможет воспроизвести.

❌ Смешивание ожидаемого и фактического результата: «Должно показывать сумму, но показывает 0» — это лучше разделить на два чётких пункта.

❌ Отсутствие окружения: Ошибка может воспроизводиться только в Safari на iPhone — без этой информации разработчик будет искать проблему часами.

❌ Эмоциональные оценки: «Ужасная ошибка! Всё сломалось!!!» — в баг-репорте нет места эмоциям. Только факты.

❌ Один баг-репорт на несколько ошибок: Если вы нашли три разные проблемы — пишите три отдельных репорта.

Практика

Упражнение 1. Найдите ошибки в баг-репорте

Прочитайте следующий баг-репорт и найдите в нём как минимум 3 проблемы. Запишите их.

Заголовок: Не работает

Шаги: Открыть приложение и попробовать войти.

Ожидаемый результат: Должно работать нормально.

Фактический результат: Приложение ругается и показывает
ошибку при входе с неправильным паролем.
Также кнопка "Забыл пароль" не работает.
Ещё иконки на главном экране мелкие.

Серьёзность: очень страшная ошибка

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

Упражнение 2. Напишите свой баг-репорт

Откройте любой сайт или приложение, которым вы пользуетесь каждый день (интернет-магазин, новостной сайт, мобильное приложение банка). Найдите любую мелкую проблему — опечатку, неудобное расположение кнопки, что-то, что работает не так, как вы ожидаете.

Напишите баг-репорт по полной структуре:

Заголовок
Окружение
Шаги воспроизведения
Ожидаемый результат
Фактический результат
Серьёзность (с обоснованием)
Приоритет

Даже если вы не найдёте настоящий баг — попробуйте придумать реалистичный сценарий и описать его.

Упражнение 3. Определите уровень серьёзности

Для каждой из описанных ситуаций определите уровень серьёзности (S1–S5) и объясните свой выбор одним предложением.

При попытке запустить мобильное приложение банка оно мгновенно закрывается. Войти невозможно.
На странице «Контакты» написано «8-800-XXXXXX» вместо реального номера телефона.
Кнопка «Перевести деньги» работает, но надпись на ней отображается жирным шрифтом вместо обычного.
При оплате картой после ввода CVC-кода страница зависает и транзакция не завершается, хотя деньги со счёта списываются.
В разделе «Помощь» одна из статей открывается на 3 секунды дольше, чем остальные.

Упражнение 4. Серьёзность vs. Приоритет

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

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

Ситуация Б. На главной странице сайта компании, которая завтра проводит крупную презентацию для инвесторов, в заголовке написано название конкурента вместо собственного названия компании.

Главные выводы урока

Баг-репорт — это структурированный документ, который позволяет разработчику воспроизвести и исправить ошибку.
Обязательные части баг-репорта: заголовок, окружение, шаги воспроизведения, ожидаемый результат, фактический результат, серьёзность, приоритет.
Шаги воспроизведения — самая важная часть: они должны быть конкретными, пронумерованными и воспроизводимыми.
Серьёзность (Severity) — техническая оценка того, насколько сильно баг влияет на программу (S1 Blocker → S5 Trivial).
Приоритет (Priority) — бизнес-оценка того, как быстро нужно исправить баг (High / Medium / Low).
Серьёзность и приоритет — разные вещи и могут не совпадать.
Один баг-репорт = одна ошибка. Никаких эмоций — только факты.
Скриншот или видео значительно упрощают работу разработчика — прикладывайте их всегда, когда можете.