Как ответить на вопрос «Из чего состоит баг-репорт» на собеседовании QA

Зачем это спрашивают

Баг-репорт — основной продукт работы тестировщика, который видят другие люди. Разработчик по нему чинит, тимлид по нему планирует, продакт по нему решает, выпускать ли релиз. Если репорт плохой, команда тратит время на уточнения, а иногда закрывает дефект как «не воспроизводится» и выпускает его в продакшен.

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

Как построить сильный ответ

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

Несколько деталей, которые отличают сильный ответ:

• Ожидаемый результат с источником. «Должно работать» — не ожидание. «По требованию в истории заказов новые заказы идут первыми» — ожидание, которое можно проверить.
• Severity ставит тестировщик, priority обычно решает тимлид или продакт. Подробнее — в статье про severity и priority.
• Один репорт — одна ошибка. Если нашли две, заведите два бага и свяжите их.
• Частота для плавающих ошибок. Не «иногда», а «4 из 10 попыток» — об этом в статье про невоспроизводимые баги.

Формула заголовка

Рабочая формула: где + что происходит + при каком условии. Заголовок описывает симптом, а не причину, и не содержит эмоций.

• Плохо: «Корзина не работает», «Срочно! Баг с заказом», «Ошибка в JS».
• Хорошо: «История заказов: после выхода из аккаунта и повторного входа у заказов не отображается статус».

Такой заголовок найдётся поиском по словам «история заказов», «статус», «вход», и разработчик ещё до открытия задачи понимает, какой модуль смотреть.

Пример ответа

Цель баг-репорта — чтобы разработчик повторил ошибку без вопросов ко мне. Поэтому в нём есть заголовок по схеме «где, что, при каком условии», окружение — стенд, сборка, браузер с версией, — предусловия: под какой ролью и с какими данными я работал. Дальше шаги, по одному действию на шаг и с конкретными значениями, ожидаемый результат со ссылкой на требование и фактический результат без оценок. Я ставлю severity по последствиям для пользователя, а priority предлагаю, но решает его обычно тимлид. Обязательно прикладываю доказательства: скриншот или видео, а если ошибка связана с запросами — HAR или текст ответа из DevTools. Если ошибка плавающая, указываю частоту числом. Перед отправкой проверяю, нет ли дубликата, и сам прохожу свои шаги ещё раз.

Частые ошибки

• Перечислить поля и не объяснить, зачем каждое нужно.
• Забыть окружение и предусловия — самая частая причина ответа «у меня работает».
• Писать в заголовке причину («Не работает валидация на бэке») вместо симптома.
• Объединять в шаге несколько действий: «Заполнить форму и оформить заказ».
• Писать фактический результат оценочно: «всё сломалось», «ужасно выглядит».
• Путать severity и priority или считать, что тестировщик единолично ставит оба.
• Не прикладывать ничего, кроме скриншота, когда ошибка явно в ответе сервера.

Пример на MarketCove

Представим, что вы проверяете оформление заказа гостем в учебном магазине MarketCove и после отправки формы видите сообщение об ошибке. Как мог бы выглядеть репорт:

• Заголовок: Оформление заказа гостем: адрес с дробью в номере дома («д. 5/2») отклоняется, заказ не создаётся
• Окружение: учебный стенд, Chrome 129, macOS 15
• Предусловия: пользователь не авторизован, в корзине 2 любых товара
• Шаги:
  1. Открыть корзину, нажать «Оформить заказ».
  2. Заполнить поля «Имя», «Email», «Карта (16 цифр)» корректными тестовыми данными, в поле «Адрес» ввести «ул. Лесная, д. 5/2».
  3. Отправить форму.
• Ожидаемый результат: заказ создан, показан номер заказа (дробь в номере дома — обычный формат почтового адреса).
• Фактический результат: заказ не создан, на экране сообщение «Что-то пошло не так», сервер ответил 400.
• Вложения: видео, запрос и ответ из вкладки Network (тело запроса здесь упрощено):

POST /api/shop/orders HTTP/1.1
Content-Type: application/json

{"name": "Анна", "address": "ул. Лесная, д. 5/2", "…": "остальные поля опущены"}

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

Задание для практики

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

1. Сможет ли коллега, который не видел вашего экрана, пройти шаги без вопросов?
2. Есть ли у ожидаемого результата источник?
3. Найдётся ли ваш заголовок поиском по двум-трём ключевым словам?

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