Про Тестинг: обеспечение качества, тестирование, автоматизация

Раздел: Тестирование > Тестовые Артефакты > Баг Репорт > Жизненный цикл бага

Жизненный цикл бага

Перед началом описания элементарного жизненного цикла бага предлагаем рассмотреть следующую блок-схему, показывающую основные статусы и возможные переходы от статуса к статусу в процессе его существования:

Жизненный цикл бага

Теперь переходим к описанию данной схемы.

Допустим вы нашли баг и зарегистрировали его в баг трекинг системе. Согласно нашей блок-схеме он получит статус “Новый”. Тестировщик, ответственный за валидацию новых баг репортов, или координатор проекта (в зависимости от распределения ролей в вашей команде) может перевести его в один из следующих статусов:

  • “Отклонен”, если данный баг невалидный или повторный, или же его просто не смогли воспроизвести
  • “Отсрочен”, если данный баг не нужно исправлять в данной итерации
  • “Открыт”, если исправление бага необходимо

Рассмотрим теперь по порядку каждый из вариантов.

  1. Отклонен. В этом случае вы можете либо поспорить о судьбе вашего багрепорта, изменив статус на “Переоткрыт” либо закрыть его - статус “Закрыт”
  2. Отсрочен. Баг репорт в статусе “Отсрочен” можно перевести в статус “Открыт”, когда потребуется исправление либо в статус “Закрыт”, если уже не потребуется.
  3. Открыт. Именно в таком состоянии разработчик получает баг репорт для исправления. Он может отклонить (дальнейшие действия смотрите в пункте 1) или исправить баг. Баг репорт в статусе “Исправлен” переводится на тестировщика для проверки. В случае если проблема все еще воспроизводится, выставляется статус “Переоткрыт” и баг репорт направляется назад на доработку к разработчику. Если же исправление было успешным, то баг репорт переводится в статус “Закрыт”.

* * *

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


Примечание 1: в некоторых системах баг трекинга созданный баг репорт сразу получает статус “Открыт” без дополнительной валидации

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

Примечание 3: Рассмотренный выше жизненный цикл основан на том, что в команде есть кто-то, ответственный за назначение баг репортов. В случае, если такой роли на проекте нет, то баги назначаются разработчиками самостоятельно, и тогда во избежании путанницы, есть смысл ввести еще один промежуточный статус “В разработке” (In progress), показывающий, что данный баг репорт уже назначен и находится на стадии исправления. Пример реализации подобного жизненного цикла на базе JIRA можно увидеть на следующем рисунке:

JIRA - Жизненный цикл бага


Наверх