БЛОК 6. Работа с багами — 21. Severity, Priority и жизненный цикл бага

🧭 Введение: зачем QA понимать Severity, Priority и lifecycle

После того как баг найден и заведен, команде нужно понять три вещи: насколько дефект тяжелый, насколько срочно его исправлять, и где он сейчас находится в процессе. Для этого нужны Severity, Priority и lifecycle.

Если эти три части не разделять, triage быстро превращается в хаос: команда спорит о приоритетах, а не принимает решения по фактам.

💡 Совет:

Всегда разделяй в голове три вопроса: насколько больно, насколько срочно и где сейчас баг в процессе.

✅ Вывод:

Severity, Priority и lifecycle — это основа осознанных релизных решений.

⚠️ Проблема -> решение

Проблема: новички часто путают severity и priority, а статусы бага воспринимают как формальность. В результате дефекты получают неверный приоритет, зависают в очереди или закрываются слишком рано.

Решение: работать по понятной модели: сначала оценить влияние (severity), потом срочность в контексте релиза (priority), затем вести баг по прозрачному жизненному циклу.

🟢 Если совсем просто:

Severity = насколько тяжело, Priority = насколько срочно, Lifecycle = на каком шаге обработки бага мы сейчас.

🎯 Как понять, что этап прошел успешно:

Команда одинаково трактует оценки и статусы, а дефекты двигаются по процессу без хаоса.

🛠️ Чем помогает и как работает

Эта модель нужна, чтобы не чинить "все подряд". Она помогает команде фокусироваться на том, что реально важно для пользователей и релиза.

Как это работает:

Шаг 1: QA фиксирует дефект и ставит предварительную severity.
Шаг 2: на triage команда подтверждает priority и владельца.
Шаг 3: баг проходит по статусам жизненного цикла.
Шаг 4: после фикса QA делает retest и закрывает/переоткрывает.

✅ Вывод:

Оценки и статусы превращают поток багов в управляемый процесс.

📚 Ключевые термины (простыми словами)

Severity — тяжесть дефекта и его влияние.
Priority — срочность исправления в текущем плане.
Triage — встреча/процесс, где багу назначают приоритет и владельца.
Lifecycle — путь бага от создания до закрытия.
Retest — повторная проверка после фикса.
Reopen — переоткрытие бага, если проблема осталась.

1. Severity vs Priority: в чем разница

Это главный фундамент темы. Почти все начинающие QA сначала смешивают эти два параметра.

🟢 Если совсем просто:

Severity отвечает на вопрос "насколько больно", Priority отвечает на вопрос "насколько срочно чиним".

🎯 Как понять, что этап прошел успешно:

QA может объяснить, почему баг с высокой severity иногда получает не самый высокий priority, и наоборот.

Назначение:

Развести тяжесть дефекта и срочность его исправления.

Простыми словами:

Severity — про влияние дефекта, Priority — про план работ команды.

Главное правило:

Severity показывает тяжесть самого дефекта. Priority показывает срочность исправления именно сейчас, в текущем релизном контексте.

Для новичка:

Не ставь priority только по эмоциям от бага. Всегда смотри на контекст релиза.

Сравнение:

Параметр	Что показывает	Кто обычно влияет
Severity	Техническая/пользовательская тяжесть	QA + dev
Priority	Срочность исправления в релизе	QA + PM/lead

✅ Вывод:

Severity и Priority связаны, но это разные решения.

2. Как оценивать Severity (базовая модель)

Severity должна отражать реальное влияние дефекта. Для junior лучше использовать простую и повторяемую шкалу.

🟢 Если совсем просто:

Чем сильнее баг ломает критичный поток, данные или безопасность, тем выше severity.

🎯 Как понять, что этап прошел успешно:

Severity в тикете аргументирована фактическим влиянием.

Назначение:

Сделать оценку тяжести единообразной в команде.

Простыми словами:

Оцени не "насколько раздражает", а "насколько ломает".

Для новичка:

Перед оценкой задай базовые вопросы по влиянию.

Мини-чеклист Severity:

ломается ли критичный пользовательский поток;
теряются ли деньги или данные;
есть ли риск безопасности;
есть ли обходной путь;
затронуты все пользователи или узкая группа.

Пример шкалы:

Critical — сервис/критичный поток недоступен, серьезный финансовый или security риск.
High — сильная деградация важной функции, но есть обходной путь.
Medium — заметная ошибка, влияющая на UX/функцию без критического ущерба.
Low — косметика или незначительная проблема.

✅ Вывод:

Severity должна опираться на влияние, а не на субъективную важность "лично для нас".

3. Как оценивать Priority (в контексте релиза)

Priority зависит не только от дефекта, но и от текущего плана. Один и тот же баг в разных релизах может получить разный приоритет.

🟢 Если совсем просто:

Priority = срочность фикса с учетом дедлайна и релизного риска.

🎯 Как понять, что этап прошел успешно:

Команда может объяснить, почему баг чинится сейчас/позже.

Назначение:

Управлять очередью исправлений под реальные сроки.

Простыми словами:

Priority показывает место бага в очереди работ.

Для новичка:

Не назначай всем дефектам P0. Высокий приоритет должен быть обоснован.

Мини-чеклист Priority:

баг блокирует текущий релиз;
затронут ли основной бизнес-поток;
есть ли дедлайн или выкладка прямо сейчас;
существует ли временный workaround;
сколько пользователей пострадает до следующего релиза.

Пример шкалы:

P0 — чиним немедленно, блок релиза.
P1 — чиним в текущем цикле.
P2 — можно перенести в следующий спринт.
P3 — низкий приоритет, backlog.

✅ Вывод:

Priority — это решение по времени исправления, а не дубль severity.

4. Жизненный цикл бага: от открытия до закрытия

Статусы нужны не "для Jira", а для прозрачности процесса. По lifecycle видно, где именно застрял дефект.

🟢 Если совсем просто:

Lifecycle показывает путь бага: найден -> проверен -> исправлен -> подтвержден -> закрыт.

🎯 Как понять, что этап прошел успешно:

По статусу всегда ясно, кто сейчас владелец следующего действия.

Назначение:

Сделать движение бага по процессу понятным для всей команды.

Простыми словами:

У каждого статуса есть конкретный смысл и ответственный.

Для новичка:

Перед сменой статуса спроси: какое действие завершено и какое действие ожидается дальше.

Важное правило:

Статус бага должен показывать реальное состояние работы, а не просто "куда его перетащили в Jira".

Типовой lifecycle:

Open — баг заведен.
In Progress — разработчик взял в работу.
Fixed — исправление заявлено.
Retest / Verified — QA проверил фикс.
Closed — дефект подтвержденно устранен.

Дополнительный статус:

Reopened — баг вернули в работу, если проблема осталась.

Важно:

Названия статусов могут отличаться в разных командах:

Open / New
In Progress / Assigned
Fixed / Ready for Retest
Verified / QA Passed
Closed / Done

Но смысл обычно один: баг найден -> взят в работу -> исправлен -> проверен -> закрыт.

✅ Вывод:

Lifecycle позволяет команде управлять дефектами, а не просто "копить тикеты".

5. Когда и почему баг переоткрывают (Reopen)

Переоткрытие — нормальная часть процесса, а не "ошибка QA". Главное — делать это с фактами и обновленным контекстом.

🟢 Если совсем просто:

Если после Fixed дефект воспроизводится, баг нужно reopen.

🎯 Как понять, что этап прошел успешно:

Reopen сопровождается новыми шагами, средой и артефактами.

Назначение:

Вернуть дефект в работу корректно и без эмоциональных споров.

Простыми словами:

Reopen = "фикса недостаточно", а не "кто-то виноват".

Для новичка:

При reopen всегда указывай: что проверяли, что ожидали, что получили, на каком build.

✅ Вывод:

Качественный reopen ускоряет второй цикл исправления.

6. Кто принимает решения по Severity и Priority

Это командная работа, а не личное решение одного человека. Важно понимать зоны ответственности.

🟢 Если совсем просто:

QA предлагает оценку, команда подтверждает ее на triage.

🎯 Как понять, что этап прошел успешно:

По каждому дефекту есть согласованный severity, priority и владелец.

Назначение:

Снизить конфликты и сделать решения предсказуемыми.

Простыми словами:

Severity и priority — это договоренность команды на основе фактов.

Практическое правило:

QA обычно предлагает severity. Priority чаще подтверждается на triage командой. Финальное решение зависит от релиза, дедлайна и бизнес-риска.

Для новичка:

Если есть спор, не спорь "на словах": покажи влияние, частоту, артефакты и релизный контекст.

✅ Вывод:

Факты и единые критерии важнее личных оценок.

7. Конфликтные случаи: как думать правильно

Иногда у бага высокая severity, но невысокий priority. Или наоборот: невысокая severity, но urgent priority.

🟢 Если совсем просто:

Оцени влияние отдельно, срочность отдельно, затем своди в релизное решение.

🎯 Как понять, что этап прошел успешно:

Каждый спорный кейс имеет объяснение "почему так приоритизировали".

Назначение:

Научиться принимать непротиворечивые решения в реальных условиях.

Простыми словами:

Не все "тяжелые" баги чиним первыми, и не все "легкие" можно откладывать.

Для новичка:

Не пытайся "угадать правильный priority". Твоя задача — обосновать предложение фактами: влиянием, охватом, релизным риском и workaround.

Пример:

Баг A:Severity = High, Priority = P2Причина: редкий admin-only поток, релиз не блокирует. Баг B:Severity = Medium, Priority = P0Причина: в день релиза ломает основной checkout у части пользователей.

✅ Вывод:

Сильный QA умеет объяснить приоритет с учетом контекста, а не только уровня тяжести.

📌 Must-know факты

Severity показывает влияние дефекта, Priority — срочность исправления.
Severity и Priority могут отличаться и это нормально.
Жизненный цикл бага должен быть прозрачным для всей команды.
Reopen — рабочий инструмент, если дефект не устранен полностью.
Решения по priority принимаются с учетом релизного контекста.

❗ Частые мифы

❌ Миф: Severity и Priority — одно и то же.

✅ Как правильно: Severity про тяжесть, Priority про очередь исправления.

📎 Почему это важно: Иначе triage становится хаотичным.

❌ Миф: Если баг получил Fixed, его нельзя переоткрывать.

✅ Как правильно: При воспроизведении после фикса баг нужно reopen с фактами.

📎 Почему это важно: Это защищает качество релиза.

❌ Миф: Priority определяет только QA.

✅ Как правильно: Priority — командное решение на triage.

📎 Почему это важно: Так учитываются и технические, и продуктовые риски.

❌ Миф: Все критичные баги всегда блокируют релиз.

✅ Как правильно: Решение зависит от контекста, обходных путей и фактического охвата проблемы.

📎 Почему это важно: Это снижает риск необоснованных релизных стопов.

✅ Best Practices

Всегда разделяй оценку влияния (severity) и срочности (priority).
Используй единые критерии severity для всей команды.
Подтверждай priority на triage, а не в одиночку.
Перед закрытием бага обязательно делай retest.
При повторе дефекта корректно используй Reopened.
Держи статусы тикетов актуальными.
В спорных кейсах опирайся на факты и релизный контекст.

🏁 Заключение

Severity, Priority и жизненный цикл бага — это практический инструмент управления качеством. Когда QA умеет правильно оценивать дефекты и вести их по lifecycle, команда быстрее принимает решения и стабильнее выпускает релизы.

Для junior это один из ключевых шагов от "нашел баг" к "управляет дефектами как часть команды".

БЛОК 6. Работа с багами — 21. Severity, Priority и жизненный цикл бага

БЛОК 6. Работа с багами — 21. Severity, Priority и жизненный цикл бага

🧭 Введение: зачем QA понимать Severity, Priority и lifecycle

⚠️ Проблема -> решение

🛠️ Чем помогает и как работает

📚 Ключевые термины (простыми словами)

1. Severity vs Priority: в чем разница

2. Как оценивать Severity (базовая модель)

3. Как оценивать Priority (в контексте релиза)

4. Жизненный цикл бага: от открытия до закрытия

5. Когда и почему баг переоткрывают (Reopen)

6. Кто принимает решения по Severity и Priority

7. Конфликтные случаи: как думать правильно

📌 Must-know факты

❗ Частые мифы

💬 Часто спрашивают на собеседованиях

🚨 Типичные ошибки

Ошибка 1: Priority ставят по эмоциям

Ошибка 2: Severity оценивают по "кто громче говорит"

Ошибка 3: Баг закрывают без ретеста

Ошибка 4: Не используют Reopen

Ошибка 5: Статусы бага не обновляют

✅ Best Practices

🏁 Заключение

Проверьте знания