Баг-репорт, который не вернут разработчики
Баг-репорт — единственный артефакт, по которому вас каждый день оценивает вся команда. Поэтому его просят «написать прямо здесь» почти на каждом собеседовании.
Дефект (баг) — расхождение фактического поведения системы с ожидаемым. Ожидаемое берётся из требований, а если требований нет — из здравого смысла, аналогов и предыдущего поведения продукта.
Вопрос 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: «Разработчик закрыл баг со статусом „не воспроизводится“. Ваши действия?»
Что на самом деле проверяет интервьюер
Как вы ведёте себя в конфликте: пойдёте в эскалацию, сдадитесь или сначала проверите себя.
Развёрнутый ответ
Порядок действий, который стоит проговорить:
- Воспроизвести самому на актуальной сборке — возможно, дефект уже поправлен смежным изменением или это была нестабильность стенда.
- Сравнить окружения: версия сборки, браузер, роль пользователя, данные аккаунта, фича-флаги, регион, время. Чаще всего разница именно здесь.
- Усилить доказательства: видеозапись, har-файл, логи с request-id, точное время события — по нему разработчик найдёт запись в логах.
- Прийти лично или в тред и воспроизвести вместе. Пять минут разговора экономят три круга переоткрытий.
- Если дефект действительно не воспроизводится — не оставлять «висяк»: описать в комментарии, что проверили, и закрыть с обоснованием, оставив след для будущего.
Формулировка важна не меньше содержания: «у меня воспроизводится на сборке 4.18.0-rc3, вот видео и request-id, давай посмотрим вместе» работает, а «ты не разобрался» — нет. На собеседовании оценивают именно этот тон.
Типичные ошибки кандидатов
- Пишут заголовок «Не работает кнопка» — в бэклоге из двухсот задач такой баг не найти и не оценить.
- Складывают в один репорт несколько дефектов. Один баг — одна карточка, иначе половину исправят, а карточку закроют.
- Не указывают версию сборки и окружение, из-за чего разработчик проверяет на другом стенде и честно не воспроизводит.
- Пропускают ожидаемый результат, считая, что «и так очевидно». Часто оказывается, что дефекта нет, а есть непонятое требование.
- Приносят скриншот вместо текста ошибки: по картинке нельзя искать в логах.
- Эмоции и капслок в описании — сразу минус в глазах интервьюера.
Как ответить кратко
Хороший баг-репорт состоит из заголовка формата «что, где, при каких условиях», окружения со сборкой и версией браузера, предусловий, пронумерованных шагов с конкретными данными, фактического и ожидаемого результата со ссылкой на требование, severity и priority, а также вложений — скриншота или видео, лога, запроса-ответа и request-id. Один репорт — один дефект. Если разработчик пишет «не воспроизводится», я сначала проверяю сам на актуальной сборке, потом сверяю окружения и данные, добавляю видео и request-id и предлагаю посмотреть вместе — обычно расхождение оказывается в версии, роли или тестовых данных.