Баг-репорт без боли: как описать ошибку, чтобы разработчик сразу понял проблему

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

Баг-репорт (bug report) — это описание обнаруженной ошибки в программе, сайте, мобильном приложении или другой системе.

Его главная задача простая: разработчик должен понять проблему и желательно воспроизвести её у себя.

Потому что баг, который существует только на ноутбуке тестировщика, выглядит примерно так:

👨‍💻 Разработчик: «У меня работает».

🧑‍🔬 Тестировщик: «А у меня нет».

👨‍💻 Разработчик: «Ну значит работает».

И вот уже где-то начинается созвон на 40 минут.

Хороший баг-репорт сильно сокращает такие ситуации.

🔥 Главное правило хорошего баг-репорта

После прочтения отчёта разработчик должен получить ответы минимум на четыре вопроса:

1. Что произошло?

2. Где это произошло?

3. Как это повторить?

4. Что должно было произойти вместо этого?

Если хотя бы половины информации нет, начинается детектив.

Разработчик одновременно превращается в Шерлока Холмса:

Где нажали?
Под каким пользователем?
Какая версия приложения?
Что было введено?
Это Safari?
Это Android?
Это вообще наш сайт?

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

📝 1. Заголовок: не «сломалось», а конкретно что сломалось

Заголовок должен позволять понять проблему даже без открытия задачи.

❌ Плохо

Ошибка оплаты

или легендарное:

Не работает

Спасибо, теперь всё понятно.

✅ Лучше

Кнопка «Оплатить» не реагирует после выбора оплаты банковской картой

Ещё лучше добавить место:

Checkout: кнопка «Оплатить» не реагирует после выбора банковской карты

Хорошая формула:

Где → что происходит → при каком условии

Например:

Профиль пользователя → аватар не обновляется после загрузки нового изображения

или:

Авторизация → пользователь получает ошибку 500 при входе через Google

Уже по заголовку разработчик примерно понимает, куда смотреть.

🪜 2. Шаги воспроизведения — самая важная часть

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

Пишите действия последовательно.

Steps to reproduce

1. Открыть страницу оформления заказа.

2. Добавить товар в корзину.

3. Перейти к оплате.

4. Выбрать «Банковская карта».

5. Ввести данные карты.

6. Нажать «Оплатить».

Именно действия пользователя, а не:

«Ну я там сначала что-то выбрал, потом перешёл куда-то в корзину, и оно сломалось».

Особенно важно указать необычные условия.

Например:

Ошибка появляется только при пустом поле «Отчество».

или:

Баг воспроизводится только после обновления страницы.

или:

Сначала необходимо добавить два товара, удалить первый и только потом нажать «Оплатить».

Да, иногда баги действительно требуют ритуала уровня: открыть модальное окно → закрыть → обновить → нажать кнопку → пожертвовать клавиатуру богам JavaScript.

Именно поэтому подробные шаги важны.

🎯 3. Actual Result — что произошло

Здесь описываем фактическое поведение системы.

Фактический результат

После нажатия кнопки «Оплатить» ничего не происходит. Кнопка остаётся активной, переход на страницу оплаты отсутствует.

Главное — писать наблюдаемый результат, а не собственную теорию.

❌ Плохо

Наверное, backend неправильно обрабатывает запрос.

Возможно. А возможно frontend вообще запрос не отправляет.

Пусть разработчики сами выясняют причину. Ваша задача — зафиксировать симптом.

✅ 4. Expected Result — а что должно было произойти?

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

Ожидаемый результат

После нажатия кнопки «Оплатить» пользователь должен быть перенаправлен на страницу платёжного сервиса.

Теперь разница между текущим и ожидаемым поведением понятна.

Actual: ничего не происходит.

Expected: должен открыться платёжный сервис.

Есть конкретный конфликт — есть конкретная задача.

🖥 5. Окружение: потому что «у меня работает» иногда действительно правда

Один и тот же продукт может вести себя совершенно по-разному в разных условиях.

Поэтому указывайте окружение.

• Windows 11;

• Chrome;

• разрешение 1920×1080;

• production;

• пользователь с ролью Manager.

Для мобильного приложения:

• модель устройства;

• версия iOS или Android;

• версия приложения;

• тип сети, если это имеет значение.

Это особенно важно для ошибок, связанных с интерфейсом.

Например, кнопка может прекрасно выглядеть на iPhone, но улетать за пределы экрана на конкретном Android-устройстве.

А потом начинается:

— У меня всё нормально.

— А вот скрин.

— …

— Я завёл баг.

📸 6. Скриншоты и видео — иногда лучше тысячи слов

Описание:

«Кнопка немного съезжает вправо».

Что значит «немного»?

2 пикселя? 20? Она вообще уже покинула страницу и отправилась строить новую жизнь?

Скриншот решает вопрос мгновенно.

Для визуальных ошибок полезно приложить:

• скриншот;

• запись экрана;

• стрелку или выделение проблемного места.

Особенно удобно видео для сложных сценариев.

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

🧾 7. Логи и ошибки из консоли — разработчик скажет спасибо

Если у вас есть доступ к технической информации — прикладывайте её.

POST /api/payment
Status: 500
TypeError: Cannot read properties of undefined

Для разработчика это уже огромная подсказка.

Особенно полезны:

• ошибки браузерной консоли;

• HTTP-коды;

• request/response;

• backend-логи;

• stack trace;

• crash logs мобильного приложения.

Но есть важный момент: не нужно превращать баг-репорт в свалку логов на 50 000 строк.

Если возможно, оставьте только информацию вокруг ошибки или приложите полный лог отдельным файлом.

🔁 8. Укажите, насколько стабильно воспроизводится ошибка

Очень полезная информация:

Воспроизводится 5 из 5 раз.

или:

Проявляется примерно в 20% случаев.

или:

Удалось воспроизвести один раз, повторно пока не получилось.

Последний вариант тоже абсолютно нормальный.

Баг не становится ненастоящим только потому, что воспроизводится редко.

Такие ошибки особенно прекрасны.

Сегодня работают. Завтра нет. После открытия DevTools снова работают. Закрыл DevTools — опять сломались.

Разработчик смотрит на код.

Код смотрит на разработчика.

🚨 Severity и Priority — это не одно и то же

Два термина часто путают.

Severity — насколько серьёзна сама ошибка

Critical: приложение падает при запуске.

Major: невозможно оформить заказ.

Minor: текст выходит за границы блока.

Priority — насколько быстро нужно исправить проблему

И здесь начинается интересное.

Опечатка в баннере рекламной кампании может технически иметь низкий Severity. Но если акция стартует через 15 минут, Priority внезапно становится очень высоким.

Поэтому Severity отвечает на вопрос:

«Насколько сильно сломана система?»

А Priority:

«Насколько срочно это нужно чинить?»

🤡 Как НЕ надо писать баг-репорт?

«Не работает»

Что? Где? Когда?

Никто не знает.

«Исправьте срочно!!!»

Почему срочно? Что сломалось? Кто пострадал?

Зато три восклицательных знака уже на месте.

«После обновления всё стало плохо»

Это не баг-репорт. Это начало эмоционального разговора.

«Не работает кнопка, см. видео»

А видео длится 7 минут. Первые четыре минуты человек ищет нужную вкладку. На шестой минуте приходит сообщение в Telegram. На 6:53 происходит баг.

Разработчик уже успел духовно состариться.

🧩 Идеальный шаблон баг-репорта

Заголовок

Checkout: кнопка «Оплатить» не реагирует после выбора банковской карты

Окружение

• Production

• Windows 11

• Chrome

Предусловия

Пользователь авторизован. В корзине находится хотя бы один товар.

Шаги воспроизведения

1. Перейти в корзину.

2. Нажать «Оформить заказ».

3. Выбрать оплату банковской картой.

4. Заполнить данные.

5. Нажать «Оплатить».

Фактический результат

После нажатия кнопки ничего не происходит.

Ожидаемый результат

Открывается страница платёжного сервиса.

Частота воспроизведения

5/5.

Дополнительная информация

TypeError: Cannot read properties of undefined

Приложен скриншот.

Вот это уже баг-репорт, после которого разработчик не спрашивает:

«А как это вообще повторить?»

🧠 Хороший тестировщик не просто ищет баги

Поиск ошибок — только часть работы QA.

Нужно ещё уметь:

• анализировать поведение системы;

• локализовать проблему;

• проверять граничные значения;

• придумывать тестовые сценарии;

• отличать баг от ожидаемого поведения;

• понятно описывать найденные ошибки;

• проверять исправления;

• не создавать пять одинаковых задач. 😅

Поэтому хороший bug report — это реальный профессиональный навык тестировщика.

И, кстати, полезен он не только QA. Разработчик, аналитик, дизайнер, продакт и даже обычный пользователь могут оформить проблему так, чтобы команда решила её намного быстрее.

🚀 Хочешь прокачивать программирование и практиковаться — попробуй Кодик

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

В приложении Кодик можно изучать программирование постепенно: проходить уроки, выполнять задания, писать код и закреплять знания практикой.

Вместо бесконечного «посмотрел 14 часов курса и вроде всё понял» можно сразу проверять себя задачами.

А если хочется регулярно повторять программирование небольшими порциями — заглядывай в наше Telegram-сообщество Кодика. Там выходят полезные посты, разборы, мини-задачи, тесты и материалы для разработчиков.

Удобный формат, чтобы открыть Telegram на несколько минут и неожиданно узнать что-нибудь полезное вместо очередного мемаса.

Хотя мемасы у нас тоже бывают. 😎