Жизненный цикл бага — это процесс, который проходит каждый найденный дефект: от его обнаружения до закрытия. В ИТ жизненный цикл бага формализовался для ускорения обработки дефектов, минимизации рисков и прозрачности ведения работ.
История вопроса:
Ранние баг-трекинговые системы позволяли только фиксировать ошибки. По мере усложнения ПО появился запрос на структурированный трекинг статусов багов и описание всех этапов их обработки.
Проблема:
Без формальных стадий дефекты могут теряться, «зависать», оставаться незакрытыми, даже если они устранены. Также возможны недопонимания между QA и разработчиками из-за отсутствия прозрачности, кто и что должен делать.
Решение:
Стандартизация стадий (например: New, Open, Assign, In Progress, Fixed, Retest, Closed, Reopened) и описание действий на каждом этапе помогают упорядочить процесс обработки дефектов и сделать его прозрачным.
Ключевые особенности:
Можно ли закрыть баг, если он воспроизведён у тестировщика, но не у программиста?
Нет, баг должен быть согласован обеими сторонами и воспроизводиться по написанным шагам в баг-репорте.
Что делать, если по багу пришёл ответ 'Won't Fix'?
QA должен уточнить причину отказа. Если причина аргументирована (низкая критичность, совпадение с требованиями), баг можно закрыть с комментарием.
Обязан ли QA заново создавать баг, если после его закрытия проблема появилась повторно?
Нет, нужно перевести баг в статус «Reopened» и добавить новые детали по воспроизведению.
В компании использовался только базовый функционал журнала багов. После исправления дефекта разработчик отмечал его как решённый, тестировщик не проводил повторное тестирование, баги возвращались в релиз.
Плюсы:
Минусы:
Команда внедрила стандартный жизненный цикл бага с обязательным ретестом и описанием причин закрытия перед релизом.
Плюсы:
Минусы: