Баг-репорт, который не вернут разработчики

Баг-репорт — единственный артефакт, по которому вас каждый день оценивает вся команда. Поэтому его просят «написать прямо здесь» почти на каждом собеседовании.

Дефект (баг) — расхождение фактического поведения системы с ожидаемым. Ожидаемое берётся из требований, а если требований нет — из здравого смысла, аналогов и предыдущего поведения продукта.

Вопрос 1: «Из чего состоит хороший баг-репорт?»

Что на самом деле проверяет интервьюер

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

Развёрнутый ответ

Обязательные поля и смысл каждого:

  • Заголовок — «что, где, при каких условиях». По нему баг должен опознаваться в списке из ста штук без открытия.
  • Окружение — стенд, версия сборки, браузер и его версия, ОС, устройство, учётная запись.
  • Предусловия — состояние системы до шагов: какой пользователь, что в корзине, какие включены фича-флаги.
  • Шаги воспроизведения — пронумерованные, атомарные, с конкретными данными.
  • Фактический результат — что произошло, дословно с текстом ошибки.
  • Ожидаемый результат — что должно было произойти, со ссылкой на требование.
  • Severity и priority, вложения: скриншот или видео, лог консоли, запрос-ответ из вкладки Network, идентификатор запроса.

Сравним заголовки:

Плохо:  Не работает оплата
Плохо:  Ошибка!!! Срочно!
Хорошо: Оплата сохранённой картой падает с 500 при сумме заказа больше 100 000 руб. (web, Chrome 141)

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

Окружение: stage-2, сборка 4.18.0-rc3, Chrome 141, Windows 11
Предусловия: пользователь qa_user@example.com авторизован, карта **** 4242 привязана

Шаги:
1. Добавить в корзину товар стоимостью 120 000 руб.
2. Открыть корзину, нажать «Перейти к оплате».
3. Выбрать сохранённую карту **** 4242.
4. Нажать «Оплатить».

Фактически: через 3 секунды появляется «Что-то пошло не так»,
           POST /api/v1/payments отвечает 500, в теле {"error":"amount overflow"}.
Ожидаемо:  заказ оплачен, статус «Оплачен» (требование PAY-31, лимит операции 300 000 руб.).

Воспроизводится: 5 из 5 попыток. При сумме 99 999 руб. — оплата проходит.
Приложено: har-файл, скриншот, request-id 7f3c9a11

Обратите внимание на строку «при 99 999 проходит» — вы фактически провели границу и подарили разработчику половину диагностики. Это то, что отличает сильный отчёт от формально полного.

Вопрос 2: «Разработчик закрыл баг со статусом „не воспроизводится“. Ваши действия?»

Что на самом деле проверяет интервьюер

Как вы ведёте себя в конфликте: пойдёте в эскалацию, сдадитесь или сначала проверите себя.

Развёрнутый ответ

Порядок действий, который стоит проговорить:

  1. Воспроизвести самому на актуальной сборке — возможно, дефект уже поправлен смежным изменением или это была нестабильность стенда.
  2. Сравнить окружения: версия сборки, браузер, роль пользователя, данные аккаунта, фича-флаги, регион, время. Чаще всего разница именно здесь.
  3. Усилить доказательства: видеозапись, har-файл, логи с request-id, точное время события — по нему разработчик найдёт запись в логах.
  4. Прийти лично или в тред и воспроизвести вместе. Пять минут разговора экономят три круга переоткрытий.
  5. Если дефект действительно не воспроизводится — не оставлять «висяк»: описать в комментарии, что проверили, и закрыть с обоснованием, оставив след для будущего.

Формулировка важна не меньше содержания: «у меня воспроизводится на сборке 4.18.0-rc3, вот видео и request-id, давай посмотрим вместе» работает, а «ты не разобрался» — нет. На собеседовании оценивают именно этот тон.

Типичные ошибки кандидатов

  • Пишут заголовок «Не работает кнопка» — в бэклоге из двухсот задач такой баг не найти и не оценить.
  • Складывают в один репорт несколько дефектов. Один баг — одна карточка, иначе половину исправят, а карточку закроют.
  • Не указывают версию сборки и окружение, из-за чего разработчик проверяет на другом стенде и честно не воспроизводит.
  • Пропускают ожидаемый результат, считая, что «и так очевидно». Часто оказывается, что дефекта нет, а есть непонятое требование.
  • Приносят скриншот вместо текста ошибки: по картинке нельзя искать в логах.
  • Эмоции и капслок в описании — сразу минус в глазах интервьюера.

Как ответить кратко

Хороший баг-репорт состоит из заголовка формата «что, где, при каких условиях», окружения со сборкой и версией браузера, предусловий, пронумерованных шагов с конкретными данными, фактического и ожидаемого результата со ссылкой на требование, severity и priority, а также вложений — скриншота или видео, лога, запроса-ответа и request-id. Один репорт — один дефект. Если разработчик пишет «не воспроизводится», я сначала проверяю сам на актуальной сборке, потом сверяю окружения и данные, добавляю видео и request-id и предлагаю посмотреть вместе — обычно расхождение оказывается в версии, роли или тестовых данных.

Проверьте себя
1. Какой заголовок баг-репорта лучший?
AОплата не работает!!!
BОшибка на странице корзины
CОплата сохранённой картой падает с 500 при сумме заказа больше 100 000 руб. (web, Chrome 141)
DПроблема с бэкендом, нужно срочно чинить
2. Вы нашли три независимых дефекта на одной странице. Как их оформить?
AТремя отдельными баг-репортами
BОдним репортом со списком из трёх пунктов — так быстрее
CОдним репортом с максимальным severity из трёх
DНе оформлять, а рассказать разработчику устно
3. Разработчик закрыл баг как «не воспроизводится». Какое первое действие наиболее профессионально?
AСразу эскалировать руководителю разработки
BПереоткрыть баг с комментарием «проверь внимательнее»
CВоспроизвести самому на актуальной сборке и сверить окружение, версию, роль и данные
DСогласиться и закрыть баг