Что такое Defect Life Cycle?
Жизненный цикл дефекта (defect life cycle или bug life cycle) описывает путь дефекта от обнаружения через разрешение до закрытия. Понимание этого цикла обеспечивает эффективное отслеживание багов, четкую коммуникацию и своевременное разрешение.
Стадии жизненного цикла дефекта
1. New (Новый)
Описание: Дефект зарегистрирован тестировщиком, еще не проверен. Действия: Тестировщик логирует дефект с деталями (шаги, скриншоты, серьезность).
2. Assigned (Назначен)
Описание: Дефект проанализирован и назначен разработчику. Действия: Менеджер/Лид проверяет, назначает соответствующему разработчику.
3. Open (Открыт)
Описание: Разработчик начинает исследование/исправление. Действия: Разработчик подтверждает дефект, начинает работу.
4. Fixed (Исправлен)
Описание: Разработчик завершил исправление, готово к верификации. Действия: Изменения кода реализованы, отправлены в тестовую среду.
5. Retest (Повторное тестирование)
Описание: Тестировщик проверяет исправление. Действия: Тестировщик выполняет тестовые случаи для подтверждения разрешения.
6. Verified/Closed (Проверено/Закрыто)
Описание: Исправление подтверждено, дефект закрыт. Действия: Тестировщик подтверждает разрешение, обновляет статус на закрыт.
Альтернативные пути
Rejected (Отклонен)
Описание: Дефект признан невалидным (не баг, работает как задумано).
Deferred (Отложен)
Описание: Валидный дефект отложен на будущий релиз.
Reopened (Переоткрыт)
Описание: Исправление не решило проблему или вызвало регрессию.
Workflow жизненного цикла дефекта
[New] → [Assigned] → [Open] → [Fixed] → [Retest] → [Verified] → [Closed]
↓ ↓ ↓ ↑ ↓
[Rejected] [Deferred] [Reopened]──┘ [Reopened]
Атрибуты дефекта
| Поле | Описание | Пример |
|---|---|---|
| ID | Уникальный идентификатор | BUG-1234 |
| Title | Краткое резюме | “Вход не работает с валидными учетными данными” |
| Description | Детальное объяснение | Шаги воспроизведения, ожидаемое vs фактическое |
| Severity | Воздействие на систему | Critical, High, Medium, Low |
| Priority | Срочность исправления | P1, P2, P3, P4 |
| Status | Текущее состояние | New, Open, Fixed, Closed |
| Assigned To | Ответственный разработчик | john.doe@company.com |
| Reporter | Кто нашел | qa.tester@company.com |
Severity vs Priority
| Severity | Priority | Пример |
|---|---|---|
| Critical | P1 | Обработка платежей сломана - исправить немедленно |
| High | P1 | Данные пользователя раскрыты - риск безопасности |
| Medium | P2 | Поиск возвращает некорректные результаты |
| Low | P3 | Косметическая проблема UI |
| Critical | P2 | Сбой в редком граничном случае (затрагивает < 1% пользователей) |
| Low | P1 | Презентация CEO завтра, нужна косметическая правка |
Severity = Технический impact Priority = Бизнес-срочность
Лучшие практики
1. Писать четкие отчеты о дефектах
Плохой отчет:
Заголовок: Вход не работает
Описание: Я попытался войти и не получилось.
Хороший отчет:
Заголовок: Вход не работает с ошибкой "Invalid credentials" для валидных пользователей
Описание:
При попытке входа с валидными учетными данными, система возвращает
ошибку "Invalid credentials" и не аутентифицирует пользователя.
Шаги для воспроизведения:
1. Перейти на https://app.example.com/login
2. Ввести username: test@example.com
3. Ввести password: ValidPass123!
4. Нажать кнопку "Login"
Ожидаемый результат:
Пользователь аутентифицирован и перенаправлен на dashboard.
Фактический результат:
Отображается сообщение об ошибке "Invalid credentials".
Вход не работает, несмотря на корректные учетные данные.
Окружение:
- Браузер: Chrome 118.0
- ОС: Windows 11
- Сервер: Staging (v2.3.1)
Доп. информация:
- Проблема началась после развертывания 2025-10-01
- Затрагивает все тестовые аккаунты
- Console показывает ошибку 401 от /api/auth/login
- Скриншот приложен: login-error.png
2. Использовать согласованные определения Severity/Priority
Уровни Severity:
- Critical (S1): Сбой системы, потеря данных, утечка безопасности
- High (S2): Основная функция сломана, значительное воздействие на функциональность
- Medium (S3): Функция частично работает, доступен workaround
- Low (S4): Незначительная проблема, косметическая, нет функционального воздействия
Уровни Priority:
- P1: Исправить немедленно (блокер)
- P2: Исправить в текущем спринте
- P3: Исправить в следующем спринте
- P4: Исправить при наличии времени (бэклог)
3. Процесс Defect Triage
Ежедневная встреча Triage (15-30 мин):
- Просмотреть новые дефекты
- Валидировать воспроизводимость
- Назначить severity и priority
- Назначить разработчику
- Установить целевую дату разрешения
4. Отслеживать метрики дефектов
| Метрика | Описание |
|---|---|
| Open Defects | Всего неразрешенных багов |
| Defect Age | Дней с момента регистрации |
| Mean Time to Resolve | Среднее время исправления |
| Reopened Rate | % переоткрытых дефектов |
| Defect Density | Багов на функцию/модуль |
Распространенные ошибки
❌ Расплывчатые описания: “Не работает” - предоставьте конкретные шаги
❌ Отсутствие воспроизводимости: Не воспроизводится = не исправляется
❌ Неправильная severity: “Опечатка в footer” помечена как Critical
❌ Дублирующие дефекты: Проверяйте существующие баги перед регистрацией
❌ Нет регрессионного тестирования: Исправление проверено, но связанные функции не протестированы
Заключение
Хорошо определенный жизненный цикл дефекта обеспечивает систематическое отслеживание багов от обнаружения до закрытия. Четкие процессы, последовательная коммуникация и дисциплинированное следование приводят к более быстрому разрешению, лучшему качеству и улучшенному сотрудничеству команды.
Ключевые выводы:
- Стандартизируйте workflow: Определите четкие стадии и переходы
- Пишите детальные отчеты: Шаги, скриншоты, детали окружения
- Различайте severity vs priority: Технический impact vs бизнес-срочность
- Регулярный triage: Ежедневный обзор новых дефектов
- Отслеживайте метрики: Мониторьте время разрешения, плотность дефектов
- Проводите RCA: Учитесь на критических дефектах для предотвращения повторения