Ответ
Жизненный цикл дефекта описывается набором статусов. Типичный workflow включает следующие ключевые состояния:
- New / Open: Дефект заведен тестировщиком и ожидает первоначальной проверки.
- Assigned / In Progress: Баг подтвержден и назначен разработчику на исправление.
- Fixed / Resolved: Разработчик сообщил об исправлении. Дефект переходит на повторную проверку (verification).
- Verified / Closed: Тестировщик подтвердил, что исправление работает корректно, и закрывает баг.
- Reopened: При повторной проверке выяснилось, что проблема не устранена полностью. Баг возвращается в статус
AssignedилиOpen. - Rejected: Дефект отклонен (например, если это не баг, а ожидаемое поведение, дубликат или недостаточно информации для воспроизведения).
- Deferred / Postponed: Исправление решено отложить на будущие версии (например, из-за низкого приоритета).
Типичная диаграмма перехода статусов:
flowchart LR
A[New] --> B{Проверка}
B -->|Подтвержден| C[Assigned]
B -->|Отклонен| D[Rejected]
C --> E[Fixed]
E --> F{Верификация QA}
F -->|Пройдена| G[Closed]
F -->|Не пройдена| H[Reopened]
H --> C
C -->|Отложен| I[Deferred]Конкретный набор статусов может варьироваться в зависимости от используемой системы (Jira, YouTrack, Redmine) и процессов команды.
Ответ 18+ 🔞
А, слушай, про жизненный цикл бага? Ну это ж классика, пиздец! Представь, ты нашёл какую-то дичь в софте — вот с этого всё и начинается, ёпта.
Сначала ты, как тестировщик, такой: «Опа, нашел!» И создаёшь запись — статус New или Open. То есть, просто кинул эту бомбу в общую кучу, типа, «разбирайтесь, мудаки».
Дальше идёт Assigned или In Progress. Это когда кто-то из разработчиков посмотрел, охнул, и говорит: «Да, хуйня, это я накосячил». Баг вешают ему на шею, и он начинает его пилить.
Когда он думает, что всё починил, он ставит статус Fixed. Ага, типа «готово, забирайте, красавчики». Но это, блядь, только начало второго акта этой драмы!
Потом ты, как тестировщик, лезешь проверять. Если всё ок — ставишь Verified или Closed. Баг отправляется в утиль истории. Но! Если ты видишь, что фикс — это просто новый способ вызова того же самого пиздеца, ты жмешь кнопку Reopened. И всё, блядь, по новой: разработчик снова получает этот подарочек в статус Assigned. «Привет, дружок-пирожок, недоделал!»
А бывает, разработчик смотрит на багрепорт и такой: «Чё за хуйню мне тут прислали?». И тогда он может отклонить его — статус Rejected. Причины: «это не баг, а фича», «информации — ноль, нихуя не воспроизводится», или «этот дефект уже есть, ты дубликат создал, балбес».
Ну и любимый статус менеджеров — Deferred. Это когда все понимают, что баг есть, но его решать — овердохуища работы, а пользы — как с козла молока. И говорят: «Отложим на потом, нахуй». «Потом», блядь, обычно означает «никогда».
Вот, смотри, как это всё вертится по кругу, прям картинка:
flowchart LR
A[New] --> B{Проверка}
B -->|Подтвержден| C[Assigned]
B -->|Отклонен| D[Rejected]
C --> E[Fixed]
E --> F{Верификация QA}
F -->|Пройдена| G[Closed]
F -->|Не пройдена| H[Reopened]
H --> C
C -->|Отложен| I[Deferred]Красота, да? В жизни, конечно, всё ещё веселее. В одной конторе статусов — как грязи, в другой — три штуки, и все через «обсудили в чатике». Но суть-то одна: пока баг не Closed, всем пизда, спокойной жизни не видать.