📥 Баг-менеджмент: что происходит после нахождения бага

Разберем типовые этапы жизненного цикла бага из моей практики.

Тестируемый функционал: пользователь может сгенерировать и скачать отчет о продажах за выбранный период в формате PDF.

💡 Обнаружение (New)
Тестировщик находит проблему и создает баг-репорт:

«При попытке экспорта отчета за последний квартал (1 апреля - 30 июня) система выдает ошибку "Internal Server Error 500". Отчет за более короткие периоды (например, за один день) генерируется нормально. Шаги воспроизведения: ...»

💡 Назначение (Assigned)
Багу назначают исполнителя - конкретного разработчика, который становится ответственным за его исправление.

Проблема явно связана с обработкой больших объемов данных или работой сервиса генерации PDF. Баг назначается backend-разработчику, ответственному за модуль отчетов:

«Саша, разберись с экспортом PDF для длительных периодов».

💡 В работе (In Progress)
Разработчик исследует логи и код:

«Вижу проблему. Сервис генерации PDF (сторонняя библиотека) имеет лимит на размер входных данных. Когда мы передаем данные, мы этот лимит превышаем, и библиотека вызывает необработанное исключение, которое приводит к 500-й ошибке. Нужно или разбивать данные на части, или менять подход к формированию PDF».

💡 Исправлено (Fixed)
Разработчик принимает решение реализовать пагинацию данных внутри PDF-документа. Он вносит изменения, чтобы отчет для больших периодов разбивался на страницы и данные в библиотеку передавались порциями.

«Готово. Реализовал потоковую передачу данных в PDF-генератор. Лимит больше не превышается. Код отправлен на тестовый сервер».

💡 Повторная проверка (Retest)
Тестировщик проверяет исправление.

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

«Отчет создался, но данные в нем неполные. На второй странице обрываются строки таблицы, а итоговая сумма не совпадает с данными в интерфейсе».

💡 Переоткрытие (Reopened)
Тестировщик возвращает баг разработчику:

«Основная ошибка исправлена (500-я пропала), но фикс привел к дефекту контента. Отчет содержит не все данные и итоги подсчитаны неверно. Требуется доработка логики пагинации».

Статус меняется на Reopened.

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

Цикл повторяется:
🌟 In Progress (снова)
🌟 Fixed (снова)
🌟 Retest (снова)

💡 Закрыт (Closed)
После полной и успешной проверки баг торжественно закрывают. На ретро можно снова вернуться к этой проблеме для разбора полётов.

Так же есть другие этапы, которые я не включила:
🌟 Rejected / Not a Bug - ошибка не считается багом.
🌟 Deferred / Postponed - решение отложено.
🌟 Won’t Fix - баг реальный, но решено не исправлять.
🌟 Duplicate - дубликат другого бага.

А какой этап жизненного цикла бага чаще всего становится самым проблемным в ваших проектах? И почему?