Ошибки и дефекты: жизненный цикл бага

Ошибки и дефекты: жизненный цикл бага

Введение

Баг — это не просто «что-то сломалось». В профессиональном тестировании у каждого дефекта есть чёткий жизненный цикл, атрибуты и характеристики. Умение правильно описать и классифицировать баг — один из ключевых навыков QA-инженера.

Error → Bug → Failure: цепочка

Сначала важно понять терминологию:

Error (Ошибка) — это действие человека (разработчика, аналитика, тестировщика), которое приводит к дефекту. Например, разработчик неправильно понял требование.

Bug / Defect (Дефект) — результат ошибки, «поломка» в артефакте: в коде, документации, конфигурации. Это то, что тестировщик находит и документирует.

Failure (Отказ) — видимое проявление дефекта во время выполнения системы. То, что замечает пользователь.

Цепочка:

Разработчик допустил Error → в коде появился Defect → при запуске возник Failure

Не каждый дефект приводит к отказу сразу — некоторые «спят» до определённых условий.

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

Каждый баг проходит через несколько статусов:

New (Новый)
    ↓
Open (Открыт) — взят в работу, подтверждён
    ↓
In Progress (В работе) — разработчик исправляет
    ↓
Fixed (Исправлен) — разработчик говорит «починил»
    ↓
Retest (На перетестировании) — тестировщик проверяет
    ↓
Closed (Закрыт) — баг исправлен и подтверждён

Дополнительные ветки:
Open → Rejected (Отклонён) — не является дефектом, задумано так
Open → Deferred (Отложен) — не будем исправлять сейчас
Retest → Reopened (Переоткрыт) — баг не исправлен, возвращается в Open

Severity vs Priority

Это два разных параметра, которые часто путают.

Severity (Серьёзность) — насколько сильно дефект влияет на работу системы. Техническая характеристика.

Priority (Приоритет) — насколько срочно нужно исправить дефект. Бизнес-характеристика.

Важный пример: Опечатка в имени CEO на главной странице — Severity: Trivial, но Priority: High (потому что это увидят все и это репутационный риск).

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

Атрибуты хорошего баг-репорта

Хороший баг-репорт должен содержать:

1. ID — уникальный идентификатор (обычно автоматически)
2. Title / Summary — краткое описание сути (что сломалось)
3. Steps to Reproduce — пошаговые шаги для воспроизведения
4. Expected Result — что должно произойти по требованиям
5. Actual Result — что произошло на самом деле
6. Environment — браузер, ОС, версия приложения
7. Severity — серьёзность дефекта
8. Priority — приоритет исправления
9. Attachments — скриншоты, видео, логи

Пример хорошего баг-репорта:

Title: Кнопка «Сохранить» не сохраняет изменения профиля

Steps to Reproduce:
1. Войти в аккаунт
2. Перейти в Настройки → Профиль
3. Изменить имя пользователя
4. Нажать кнопку «Сохранить»
5. Обновить страницу

Expected: Новое имя отображается после обновления
Actual: Имя возвращается к старому значению

Environment: Chrome 120, Windows 11, App v2.3.1
Severity: Major | Priority: High

Распространённые ошибки

• Путать Severity и Priority. Это разные характеристики, которые могут не совпадать.
• Неполные шаги воспроизведения. Баг без возможности воспроизвести — разработчик его не исправит.
• Неясный ожидаемый результат. «Должно работать» — не ожидаемый результат. Пиши конкретно.
• Описывать несколько дефектов в одном баг-репорте. Один баг — один репорт.

Что запомнить

• Error → Bug/Defect → Failure — цепочка от ошибки человека до видимого сбоя
• Жизненный цикл бага: New → Open → In Progress → Fixed → Retest → Closed
• Severity — техническая серьёзность; Priority — бизнес-приоритет исправления
• Хороший баг-репорт содержит: заголовок, шаги воспроизведения, ожидаемый/фактический результат, окружение