Manual Testing

БЛОК 6. Работа с багами — 20. Bug report

📚 25 вопросовПройти тест →
Лекция

БЛОК 6. Работа с багами — 20. Bug report

Manual Testing

БЛОК 6. Работа с багами — 20. Bug report

🧭 Введение: зачем QA нужен сильный bug report

Баг-репорт — это рабочий документ, по которому команда понимает: что сломано, как повторить и что ожидалось. Если репорт слабый, даже важный дефект может "зависнуть" в переписке.
Для junior QA это ключевой навык: не просто найти проблему, а передать ее так, чтобы разработчик начал фикс без лишних уточнений.
💡 Совет:
Представь, что тебя нет онлайн: bug report должен работать и без созвона с QA.
✅ Вывод:
Хороший bug report ускоряет исправление и снижает шум в команде.

⚠️ Проблема -> решение

Проблема: баг найден, но описан расплывчато ("иногда падает", "не работает"). В результате тикет возвращается в QA со статусом need more info.
Решение: использовать стандартную структуру bug report и прикладывать минимальный доказательный пакет.
🟢 Если совсем просто:
Сильный баг-репорт = четкий контекст + шаги + expected/actual + доказательства.
🎯 Как понять, что этап прошел успешно:
Разработчик может воспроизвести дефект только по тексту тикета.

🛠️ Чем помогает и как работает

Bug report нужен, чтобы превратить дефект в понятную задачу для исправления. Он связывает QA, разработку, аналитику и релизный процесс.
Как это работает:
  • Шаг 1: фиксируем контекст (environment, build, роль, данные).
  • Шаг 2: описываем шаги воспроизведения.
  • Шаг 3: разделяем expected и actual.
  • Шаг 4: добавляем severity и вложения.
  • Шаг 5: передаем тикет и отвечаем на уточнения команды.
✅ Вывод:
Bug report — это не "формальность", а основной канал передачи дефекта в работу.

📚 Ключевые термины (простыми словами)

  • Bug report — структурированное описание дефекта.
  • Title — короткое и точное название проблемы.
  • Environment — где найден баг (окружение, версия, устройство, браузер).
  • Steps to reproduce — действия, которые приводят к дефекту.
  • Expected result — что должно было произойти.
  • Actual result — что произошло фактически.
  • Attachments — скриншоты, видео, логи, network-ответы.
  • Severity — тяжесть дефекта.
  • Priority — срочность исправления.

🔎 Откуда QA берёт Expected result

Ожидаемое поведение не придумывается тестировщиком. Оно всегда должно опираться на источник.
🟢 Если совсем просто:
Expected — это не мнение QA, а согласованное поведение системы.
Основные источники expected:
  • требования (requirements);
  • acceptance criteria;
  • UX/UI макеты;
  • API-контракты;
  • бизнес-правила;
  • договоренности команды.
Пример:
Requirement:Поле phone обязательно. Expected:Форма не отправляется, пока phone пустой. Actual:Форма отправляется.
✅ Вывод:
Expected всегда должен ссылаться на источник поведения системы.

1. Структура bug report: базовый шаблон junior QA

Без структуры баг-репорты становятся "чатиком с проблемой". Структура нужна, чтобы все тикеты читались одинаково.
🟢 Если совсем просто:
Один шаблон для всех багов дает стабильное качество.
🎯 Как понять, что этап прошел успешно:
Любой тикет в команде имеет одинаковый каркас, и его быстро читать.
Назначение:
Сделать баг-репорты понятными и предсказуемыми.
Простыми словами:
Чем стандартнее форма, тем меньше потерь информации.
Для новичка:
Не начинай с длинного текста. Сначала заполни обязательные блоки.
Пример шаблона:
TitleEnvironmentPreconditionsSteps to reproduceExpected resultActual resultSeverityAttachments
✅ Вывод:
Шаблон защищает от пропуска критичных полей.

2. Что происходит после создания bug report

Bug report — это начало процесса, а не конец. После создания тикет проходит через рабочий цикл команды.
🟢 Если совсем просто:
Bug report запускает цепочку: найден -> описан -> исправлен -> проверен.
Lifecycle:
  1. QA создает баг.
  2. Triage определяет priority и владельца.
  3. Разработчик анализирует дефект.
  4. Баг исправляется.
  5. QA выполняет retest.
  6. Тикет закрывается.
✅ Вывод:
Сильный баг-репорт ускоряет каждый этап жизненного цикла дефекта.

3. Как писать сильный Title

Title — первое, что видит команда. Плохой заголовок делает дефект неясным уже на входе.
🟢 Если совсем просто:
Title должен отвечать на вопрос "что именно сломано и где".
🎯 Как понять, что этап прошел успешно:
По title без открытия тикета понятна суть дефекта.
Назначение:
Сделать triage и поиск багов быстрыми.
Простыми словами:
Title — это "суть дефекта в одной строке".
Для новичка:
Избегай названий типа "Critical bug", "Не работает", "Ошибка в системе".
Формула сильного Title:
[Где] + Что сломалось + При каком условии
Примеры:
  • [Login] 500 after 6th failed attempt
  • [Checkout] Duplicate charge after timeout + retry
  • [Profile] Save succeeds with empty required phone
🟢 Если совсем просто:
Title отвечает на 3 вопроса:
  • где проблема;
  • что сломано;
  • при каком действии.
✅ Вывод:
Точный title экономит время всей команды на этапе triage.

4. Steps to reproduce: правило рабочих шагов

Шаги — центральная часть bug report. Если шаги слабые, тикет почти всегда возвращают.
🟢 Если совсем просто:
Один шаг = одно действие, без двусмысленных слов.
🎯 Как понять, что этап прошел успешно:
Разработчик повторяет дефект по шагам с первого раза.
Назначение:
Передать воспроизводимый путь к дефекту.
Простыми словами:
Пиши так, как будто проверяющий впервые видит эту фичу.
Для новичка:
Перед отправкой шагов удали фразы "иногда", "примерно", "как обычно".
Mini-правило хороших шагов:
  • точные;
  • короткие;
  • последовательные;
  • без предположений.
🟢 Простое правило:
Если шаг нельзя выполнить буквально, значит он написан плохо.
✅ Вывод:
Хорошие шаги — главный показатель качества bug report.

5. Expected vs Actual: не смешивать в одну строку

Это самая частая ошибка junior QA. Когда expected и actual смешаны, трудно понять, что именно нарушено.
🟢 Если совсем просто:
Expected и actual всегда пишем отдельными блоками.
🎯 Как понять, что этап прошел успешно:
Из тикета сразу видно "что должно быть" и "что произошло на самом деле".
Назначение:
Сделать дефект проверяемым до и после фикса.
Простыми словами:
Эта пара — основа любой проверки исправления.
Для новичка:
Если не можешь сформулировать expected, вернись к AC/контракту.
✅ Вывод:
Разделенные expected/actual убирают двусмысленность и ускоряют ретест.

6. Severity и Priority в bug report

Эти поля часто путают. В репорте они нужны, чтобы команда правильно расставила акценты.
🟢 Если совсем просто:
Severity = насколько тяжёл дефект, Priority = насколько срочно чинить.
🎯 Как понять, что этап прошел успешно:
Оценка в тикете аргументирована влиянием на пользователя и бизнес.
Назначение:
Помочь triage принимать решения быстрее.
Простыми словами:
Не все критичные баги чинят первыми, и не все срочные — самые тяжелые.
Для новичка:
Если сомневаешься в приоритете, предложи вариант и добавь короткое обоснование.
✅ Вывод:
Правильные severity/priority повышают качество релизных решений.

7. Вложения: когда и что прикладывать

Скриншоты и видео не "для красоты". Они сокращают путь от "не понял" до "вижу проблему".
🟢 Если совсем просто:
Чем сложнее баг, тем важнее артефакты.
🎯 Как понять, что этап прошел успешно:
По вложениям можно подтвердить баг и начать диагностику.
Назначение:
Дать разработке и DevOps доказательства дефекта.
Простыми словами:
Текст + артефакты всегда сильнее, чем только текст.
Для новичка:
Для интеграционных багов добавляй минимум: response, время инцидента, correlation id.
✅ Вывод:
Качественные вложения ускоряют путь от бага до фикса.

8. Правило автономного bug report

Хороший bug report должен работать без участия QA. Это ключевой критерий качества документа.
🟢 Простое правило:
Если разработчик не может воспроизвести баг без созвона с QA, описание бага нужно доработать.
🎯 Признак сильного bug report:
  • понятен контекст;
  • понятны шаги;
  • есть expected/actual;
  • есть окружение;
  • есть доказательства.
Разработчик открывает тикет -> повторяет баг -> начинает фикс.
✅ Вывод:
Автономность репорта — основной стандарт качества в команде.

9. Где может находиться причина бага

Баг не всегда означает ошибку разработчика в коде. Причина дефекта может быть в разных слоях системы.
🟢 Если совсем просто:
QA проверяет не только код, а весь контекст продукта.
Источник дефекта может быть:
  • код;
  • требования;
  • бизнес-логика;
  • конфигурация;
  • интеграция;
  • данные;
  • инфраструктура;
  • UX-решение.
Пример:
Requirement:Пользователь может оплатить заказ несколько раз. Код работает корректно,но бизнес-логика ошибочна.
✅ Вывод:
Даже при "правильном коде" дефект может быть реальным и критичным.

10. Хороший и слабый bug report: быстрый контраст

Контраст помогает junior быстрее уловить разницу в качестве.
🟢 Если совсем просто:
Слабый репорт создает вопросы, сильный — запускает фикс.
🎯 Как понять, что этап прошел успешно:
Тикет после создания не требует длинной переписки.
Сравнение:
Слабый репортСильный репорт
"Платеж не работает""[Checkout] Duplicate charge after timeout + retry"
Нет preconditionsЕсть environment + build + role + status
Нет repro rateУказано 3/10 и условия
Нет вложенийЕсть видео + response + время
✅ Вывод:
Качество bug report прямо влияет на скорость исправления дефекта.

📌 Must-know факты

  • Bug report — основной артефакт передачи дефекта в работу.
  • Без структуры тикет почти всегда будет шумным.
  • Title, steps, expected/actual — три критичных блока.
  • Вложения особенно важны для flaky и интеграционных багов.
  • Качественный репорт должен быть воспроизводим без участия QA в звонке.

❗ Частые мифы

❌ Миф: Главное — написать побольше текста.
✅ Как правильно: Важно писать структурно и по фактам, а не длинно.
📎 Почему это важно: Перегруженный текст мешает, а не помогает фиксу.
❌ Миф: Скриншот всегда достаточен.
✅ Как правильно: Для многих багов нужны шаги, контекст и технические артефакты.
📎 Почему это важно: Без данных баг может остаться "не воспроизводится".
❌ Миф: Severity и priority — одно и то же.
✅ Как правильно: Severity про тяжесть, priority про срочность.
📎 Почему это важно: Неправильная оценка ломает triage и релизные планы.
❌ Миф: Если баг очевиден QA, подробности не нужны.
✅ Как правильно: Репорт должен быть понятен любому члену команды без устных пояснений.
📎 Почему это важно: Это сокращает время от обнаружения до фикса.

💬 Часто спрашивают на собеседованиях

❓ Вопрос: Что обязательно должно быть в bug report? ✅ Ответ: Минимум: title, environment, preconditions, steps, expected/actual, severity и вложения.
❓ Вопрос: Как понять, что bug report качественный? ✅ Ответ: Если разработчик может воспроизвести дефект и начать фикс без созвона с QA.
❓ Вопрос: Почему title так важен? ✅ Ответ: По нему команда triage быстро понимает суть дефекта и его область.
❓ Вопрос: Когда нужны дополнительные артефакты кроме скрина? ✅ Ответ: При flaky, интеграционных, сетевых и backend-ошибках, где нужен технический контекст.
❓ Вопрос: В чем разница между expected и actual? ✅ Ответ: Expected — правильное поведение по требованиям, actual — фактический результат, который наблюдал QA.

🚨 Типичные ошибки

Ошибка 1: Общий title

Было:
"Ошибка в оплате".
Стало:
"[Checkout] Duplicate charge after timeout + retry".
Объяснение:
Конкретный title ускоряет triage и поиск дублей.

Ошибка 2: Шаги без preconditions

Было:
Есть действия, но не указан контекст.
Стало:
Перед шагами добавлены окружение, build, роль и состояние данных.
Объяснение:
Preconditions влияют на повторяемость не меньше самих шагов.

Ошибка 3: Смешаны expected и actual

Было:
"Должно было не создать заказ, но создало и ошибка".
Стало:
Expected и actual вынесены в отдельные строки.
Объяснение:
Так проще валидировать фиксы на ретесте.

Ошибка 4: Нет repro rate у flaky-бага

Было:
"Иногда падает".
Стало:
"Repro rate: 2/10 при Fast 3G + retry < 3 sec".
Объяснение:
Частота и условия помогают приоритизировать и диагностировать.

Ошибка 5: Нет доказательств

Было:
Только текст описания.
Стало:
Добавлены видео, response и время инцидента.
Объяснение:
Артефакты значительно ускоряют разбор дефекта.

🔁 Почему bug report возвращают QA

Самые частые причины:
  • нет шагов воспроизведения;
  • нет environment;
  • нет preconditions;
  • нет expected result;
  • шаги слишком общие;
  • нет доказательств;
  • баг не воспроизводится.
🟢 Если совсем просто:
Если разработчик задает больше двух вопросов, bug report, скорее всего, слабый.

✅ Best Practices

  • Всегда используй единый шаблон bug report.
  • Пиши title по формуле: где + что сломалось + при каком условии.
  • Делай шаги короткими и детерминированными.
  • Разделяй expected и actual в разные блоки.
  • Для нестабильных багов обязательно добавляй repro rate.
  • Прикладывай технические артефакты для сложных дефектов.
  • Проверяй репорт правилом "можно воспроизвести без QA".

🎯 Найти баг мало — нужно доказать его

Для QA важна не только внимательность, но и доказательность.
Сильный QA делает три вещи:
  1. замечает проблему;
  2. подтверждает ее воспроизводимость;
  3. передает дефект в виде понятного bug report.
🟢 Если совсем просто:
Найти баг — половина работы. Доказать баг — вторая половина.

🏁 Заключение

Bug report — это точка, где качество работы QA становится видимым для всей команды. Сильный репорт не просто сообщает о проблеме, а дает путь к воспроизведению и исправлению.
Если ты оформляешь дефекты структурно и доказательно, команда чинит быстрее, а релизы становятся стабильнее.
🎯

Проверьте знания

Закрепите материал — пройдите тест по теме «БЛОК 6. Работа с багами — 20. Bug report»

Пройти тест →