База для QA
К списку уроков
Блок 4 · Тестовая документация — практика

Урок 14. Баг-репорт

Как правильно сообщать о багах

Темы урока

Баг и баг-репорт, жизненный цикл бага, структура баг-репорта, Severity vs Priority, частые ошибки

Видео урока

Пройти тест по уроку

Конспект урока

Конспект — Урок 14: Баг-репорт

Что такое баг и баг-репорт

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

Нет ожидаемого результата → нет бага: чтобы зафиксировать отклонение, нужно знать, как должно быть.

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

Без репорта баг существует только в голове тестировщика — он не может быть зафиксирован, приоритизирован или отслежен.

Структура баг-репорта

Заголовок

Отвечает на вопрос «что сломалось, где и при каких условиях» — одной строкой.

Формула: [Что] + [Где] + [При каких условиях]

Плохо Хорошо
«Кнопка не работает» «Кнопка "Оплатить" не реагирует на клик на iOS 17 в Safari»
«Не работает оплата» «Оплата картой зависает на шаге подтверждения на Android 14 / Chrome 124»
«Ошибка при регистрации» «При вводе email с точкой перед @ форма регистрации возвращает ошибку 500»

Окружение и предусловия

Окружение — ОС, браузер, версия приложения, устройство. Баги часто специфичны для конкретного стека.

Предусловия — что должно быть сделано до начала воспроизведения: «Авторизован пользователь с непустой корзиной».

Без окружения разработчик тестирует на своей машине и в своём браузере — и честно «не воспроизводит».

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

Каждый шаг — одно конкретное действие: не «нажми куда-то», а «нажмите кнопку "Добавить в корзину" на карточке товара "Маргарита"».

  • Нумерованный список — не перескакивай, не объединяй несколько действий в один шаг
  • Самопроверка перед отправкой: пройди по шагам заново — если воспроизвёл сам, значит и разработчик сможет

Ожидаемый и фактический результат

Ожидаемый результат — что должно произойти согласно требованиям, дизайну или здравому смыслу.

Фактический результат — что произошло в реальности: точно, без эмоций, с деталями ошибки.

Разрыв между ними — это и есть баг. Без одного из двух репорт неполный.

Severity — серьёзность по техническому ущербу

Severity оценивает тестировщик — насколько серьёзно сломалась функциональность.

Severity Описание
Blocker Приложение падает или критичная функция полностью недоступна — работа невозможна
Critical / Major Серьёзное нарушение функциональности, но обходной путь есть
Minor Неудобство без потери функции
Trivial / Cosmetic Опечатки, пиксельные расхождения — не мешают работе

Priority — срочность по бизнесу

Priority оценивает PM или тимлид — насколько срочно нужно починить исходя из контекста.

  • Cosmetic-баг на главной странице за день до запуска → Priority High (клиент увидит первым)
  • Blocker на незапущенной фиче → Priority Low (ждёт своего спринта)

Severity vs Priority — не путаем

Severity Priority
Кто оценивает Тестировщик PM / тимлид
Критерий Технический ущерб Бизнес-срочность
Пример несовпадения Blocker на IE 6 → Severity высокий, Priority низкий Опечатка на баннере → Severity trivial, Priority high

Жизненный цикл бага

New → Assigned → In Progress → Fixed → Verified → Closed
                                             ↓
                                         Reopened
Статус Описание
New Тестировщик создал репорт
Assigned Назначен разработчику
In Progress Разработчик взял в работу
Fixed Разработчик говорит «починил»
Verified QA проверил фикс и подтвердил
Closed Баг официально закрыт
Reopened QA проверил фикс — баг не исправлен или воспроизводится снова

При повторном открытии обязательно указывай: версию, в которой проверял, и что именно не так с фиксом. Цикл Fixed → Reopened может повторяться несколько раз — это нормальный рабочий процесс.

Частые ошибки начинающих

  1. Заголовок-загадка — «Не работает», «Ошибка», «Проблема». Невозможно понять без открытия и переспроса.
  2. Нет окружения или шагов — разработчик не может воспроизвести → статус «не воспроизводится» и тишина.
  3. Эмоции в описании — «Ужасный баг!!!», «Всё сломано!» снижает профессиональное доверие к репорту.

Три принципа хорошего баг-репорта

  • Нейтральность — только факты, шаги и конкретика. Никаких «опять сломали».
  • Достаточность — ровно столько, сколько нужно для воспроизведения, без романа.
  • Воспроизводимость — пройди по шагам сам до отправки. Если сам не воспроизвёл — уточни перед публикацией.

Баг-репорт в Jira и YouTrack

Структура та же: Summary, Steps to Reproduce, Expected / Actual Result, Environment, Severity, Priority.

  • Вложения критичны: скриншот или видео воспроизведения бага экономит разработчику 20 минут переспросов.
  • Лейблы и компоненты помогают фильтровать: «мобайл», «оплата», «авторизация» — быстрый поиск нужных багов.

Ключевые выводы урока

  1. Баг-репорт — инструмент: хорошее описание = баг в работе, плохое = «не воспроизводится» и тишина.
  2. Формула заголовка — [Что] + [Где] + [При каких условиях] — одной строкой.
  3. Severity и Priority — разные оси: серьёзность определяет QA, срочность — бизнес.
  4. Жизненный цикл: New → Assigned → Fixed → Verified → Closed; Reopened — норма, не катастрофа.
  5. Три принципа: нейтральность, достаточность, воспроизводимость.

Домашнее задание

Зайди на Пиццаед, найди 1 баг на сайте и напиши баг-репорт.

Обязательные поля: заголовок, окружение, шаги воспроизведения, ожидаемый и фактический результат, Severity, Priority, скриншот или видео.

Критерий выполнения: пройди по своим шагам сам перед отправкой — репорт должен воспроизводиться.

Сдавать в чат марафона.