Ответ
После создания баг-репорт проходит стандартный жизненный цикл (bug lifecycle). Основные этапы:
- Триаж и верификация — QA-инженер или лид проверяет воспроизводимость, полноту описания и корректность шагов.
- Приоритизация — багу назначаются приоритет (Priority, например, P0–P3, влияющий на порядок исправления) и серьезность (Severity, например, Critical/Major/Minor, отражающая влияние на систему).
- Назначение — задача назначается разработчику или команде, ответственной за проблемный компонент.
- Исправление — разработчик фиксирует дефект, коммитит изменения и переводит статус в "Fixed" или "Resolved".
- Ретестинг (Verification) — тестировщик проверяет исправление на указанном окружении. Если баг устранен, статус меняется на "Verified".
- Закрытие — после успешного ретеста баг-репорт закрывается ("Closed"). Если проблема не решена, статус возвращается в "Reopened", и цикл повторяется.
Пример workflow в Jira:
New → Open → In Progress → Resolved → Verified → Closed
↳ Reopened (если баг не исправлен)Почему важен процесс: Он обеспечивает отслеживаемость, контроль качества и предотвращает потерю дефектов.
Ответ 18+ 🔞
А, слушай, вот эта ваша священная корова — жизненный цикл бага. Ну, типа, чтоб не терялись эти ебушки-воробушки по углам джиры, пока все ругаются, кто виноват.
Вот смотри, как это обычно бывает, по шагам, блядь:
-
Триаж и проверка на вшивость. Ты, как тестировщик, такой: «О, пиздец, всё сломалось!» — и пишешь баг. А потом приходит лид или другой QA, смотрит на это всё и думает: «А воспроизводится ли эта хуйня? А шаги все записаны? Или он просто с утра не того накосячил?». Если всё ок — баг живёт. Если нет — летит в корзину с пометкой «Invalid», и ты остаёшься с чувством, что ты мудак.
-
Расстановка приоритетов — вот где начинается цирк. Тут багу навешивают два ярлыка:
- Серьёзность (Severity) — это насколько всё плохо по факту. «Critical» — это система в огне, деньги утекают. «Minor» — кнопка на полпикселя съехала, жить можно.
- Приоритет (Priority) — это когда по мнению менеджера это надо чинить. И вот тут магия: может быть баг «Critical», но приоритет «P3», потому что «клиенты этого не видят» или «надо фичу в релиз впихнуть». Ёперный театр, короче.
-
Назначение. Тут менеджер или лид ищет, кому бы эту гранату без кольца впарить. Смотрит на команду и думает: «Кто у нас тут за этот модуль отвечает? Ага, Вася. Вася, держи, разбирайся». И Вася в душе уже матерится.
-
Исправление. Вася ковыряется в коде, час или два, находит эту строчку, где
=надо было на==поменять. Делает коммит с умным комментарием «fix for NPE» и ставит статус Resolved. Чувствует себя героем. -
Ретестинг (Verification). А вот тут твой звёздный час! Ты берёшь этот «фикс», разворачиваешь себе, и начинаешь долбить эту фичу со всех сторон. Если баг убит — ставишь Verified. Если же Вася починил одно, но сломал три других места (классика, блядь) — ты такой: «О, ни хуя себе!» — и с чувством глубокого удовлетворения переводишь баг обратно в Reopened. Лицо Васи в слаке в этот момент — просто песня.
-
Закрытие. После успешного ретеста можно наконец поставить жирную точку — статус Closed. Баг упокоился. До следующего релиза.
Вот так это выглядит в той самой Jira, где все живут:
New → Open → In Progress → Resolved → Verified → Closed
↳ Reopened (если Вася, прости господи, опять накосячил)А зачем этот весь цирк? Да затем, чтоб не было бардака, блядь! Чтобы каждый такой пиздёныш-дефект был на счету, чтобы не терялся, чтобы все видели, кто что сделал (или не сделал). Без этого — одни разговоры на совещаниях: «А мы вроде чинили... А где баг-то? А, хуй его знает». Контроль качества, ёпта, а не кидалово.