Найденный баг - это только начало истории. Каждый баг проходит целый жизненный цикл, прежде чем его окончательно закроют.
Разберем типовые этапы жизненного цикла бага из моей практики:
Тестируемый функционал: пользователь может генерировать и скачать отчет о продажах за выбранный период в формате 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)
После полной и успешной проверки баг торжественно закрывают. На ретро можно снова вернуться к этой проблеме для разбора полётов.
📱Разбор полётов по шагам на бусти
Этот пример довольно простой, он пропускает шаг ревью (In Review), но он уже наглядно показывает, что самый проблемный этап - часто не само исправление, а исчерпывающая проверка этого исправления (Retest), которая должна покрывать не только шаги из баг-репорта, но и смежные сценарии и, что особенно важно, проверку на целостность данных.
А какой этап жизненного цикла бага чаще всего становится самым проблемным в ваших проектах? И почему? #qa