Баг-менеджмент: что происходит после нахождения бага Найденный баг - это только начало истории. Каждый баг проходит целый жизненный цикл, прежде чем его окончательно закроют. Разберем типовые этапы жизненного цикла бага из моей практики: Тестируемый функционал: пользователь может генерировать и скачать отчет о продажах за выбранный период в формате 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