.svg)
.svg)
Споры о багах редко начинаются из-за самого дефекта. Чаще спорят о том, насколько он критичен и когда его нужно исправлять. Один тестировщик ставит Critical, разработчик говорит Medium, продакт просит починить «не сейчас», а релиз уже близко.
В 2026 команды выпускают изменения быстрее, больше зависят от аналитики, feature flags и поэтапных выкладок. Поэтому путаница между Severity и Priority стала еще дороже: ошибка в классификации бага бьет по срокам, качеству релиза и доверию между ролями.
В этой статье: чем Severity отличается от Priority, кто их ставит, как договориться о важности бага, как проводить баг-триаж, какие уровни использовать и как убрать бесконечные споры из QA-процесса.
1. Почему команды постоянно путают Severity и Priority
Потому что оба термина звучат похоже и касаются «важности» дефекта. Но на практике они отвечают на разные вопросы:
Severity — насколько сильно баг ломает систему или сценарий пользователя;
Priority — насколько быстро команда должна заняться исправлением.
Когда эти вещи смешивают, получается хаос: баг может быть технически тяжелым, но не срочным для бизнеса, и наоборот.
2. Простое определение Severity и Priority
| Термин | Главный вопрос | Фокус |
|---|---|---|
| Severity | Насколько серьезно сломан продукт? | Техническое и пользовательское влияние |
| Priority | Когда это нужно исправить? | Порядок работы команды и релизные решения |
Severity описывает ущерб. Priority описывает очередь исправления.
3. Кто должен ставить Severity, а кто Priority
В зрелом процессе это не одна и та же роль.
| Решение | Кто обычно отвечает |
|---|---|
| Severity | QA или QA вместе с разработчиком |
| Priority | Продакт, тимлид, delivery-менеджер или triage-группа |
| Финальное решение при споре | Триаж с участием QA, разработки и бизнеса |
Если тестировщик в одиночку определяет и Severity, и Priority, он фактически принимает бизнес-решение, которое может быть вне его зоны ответственности.
4. Как выглядит нормальная шкала Severity
Базовый вариант на 4 уровня
| Уровень | Что означает |
|---|---|
| Critical | Продукт или ключевой сценарий неработоспособен, есть потеря данных, падение сервиса или блокировка массового потока |
| High | Ключевая функция работает некорректно, есть серьезное нарушение бизнес-логики, но не полный стоп |
| Medium | Сценарий нарушен частично, есть обходной путь, влияние ограничено |
| Low | Косметика, редко используемый кейс, текст, визуальное расхождение без заметного влияния на процесс |
Главное — договориться не о словах, а о критериях перехода между уровнями.
5. Как выглядит рабочая шкала Priority
| Уровень | Что означает для команды |
|---|---|
| P0 | Исправляем немедленно, влияет на релиз или активный инцидент |
| P1 | Исправляем в ближайшем цикле до релиза или сразу после |
| P2 | Планируем в ближайшие итерации, но без режима срочности |
| P3 | Бэклог, исправление при наличии окна или в составе улучшений |
Для части команд достаточно и более простой шкалы: High, Medium, Low. Но важно, чтобы за каждым уровнем стояло конкретное правило по сроку реакции.
6. Почему Critical не всегда означает P0
Пример: в административной панели найден критичный баг в редко используемом отчете. Он серьезно ломает функцию, значит Severity высокий. Но если отчет не влияет на текущий релиз и у бизнеса есть обходной путь, Priority может быть не максимальным.
И обратная ситуация тоже реальна: визуальный баг может иметь низкую Severity, но получить высокий Priority, если он ломает главную маркетинговую страницу перед важной кампанией.
| Сочетание | Когда бывает |
|---|---|
| High Severity + Low Priority | Редкий сценарий, не блокирующий релиз |
| Low Severity + High Priority | Витрина, продажи, промостраница, репутационный риск |
| High Severity + High Priority | Критичный пользовательский поток или production-инцидент |
7. Как QA ставить Severity без ощущения, что вы «давите» на команду
Сильный QA не пишет «Critical, потому что мне кажется». Он опирается на критерии.
Опишите, какой сценарий сломан.
Покажите, есть ли обходной путь.
Зафиксируйте масштаб: один пользователь, сегмент или все.
Укажите последствия: потеря данных, деньги, блокировка операции, неверный расчет.
Привяжите дефект к согласованной шкале Severity.
Рабочая формула: «Ставлю High Severity, потому что сломан сценарий оплаты, обходного пути нет, затронут весь веб-поток». Такая формулировка звучит профессионально и снимает лишние эмоции.
8. Как проводить баг-триаж без бесконечных споров
Баг-триаж нужен не для того, чтобы «переспорить QA», а чтобы быстро синхронизировать техническую и бизнес-важность дефекта.
Минимальный формат triage-встречи
QA коротко показывает сценарий и влияние;
разработка подтверждает техническую сторону и риск исправления;
продакт или менеджер определяет срочность для релиза и бизнеса;
фиксируется итог: Severity, Priority, владелец, срок решения.
Порядок triage:
1. Что сломано
2. Насколько это серьезно
3. Насколько это срочно
4. Кто чинит
5. Когда перепроверяем9. Какие критерии лучше согласовать заранее
Если критерии не описаны, каждый спор начинается с нуля. Лучше зафиксировать внутреннюю таблицу правил.
| Критерий | Что команда должна определить |
|---|---|
| Потеря денег | Когда финансовое влияние автоматически поднимает Severity или Priority |
| Потеря данных | Какие случаи считаются Critical без обсуждений |
| Обходной путь | Снижает ли он Severity или только влияет на Priority |
| Массовость | Какой масштаб затронутых пользователей считается высоким риском |
| Репутационный риск | Когда внешний эффект важнее технической глубины бага |
10. Примеры типичных багов и их правильной классификации
| Ситуация | Severity | Priority | Почему |
|---|---|---|---|
| Оплата не проходит у всех пользователей | Critical | P0 | Сломан ключевой денежный сценарий |
| Неверный текст кнопки в редком окне | Low | P3 | Низкое влияние и нет срочности |
| График в отчете считает неверно | High | P1/P2 | Серьезная ошибка, но срочность зависит от бизнеса |
| Главный баннер ломается перед акцией | Low/Medium | P1 | Технически не критично, но срочно для бизнеса |
11. Ошибки, из-за которых Severity и Priority перестают работать
каждый ставит уровни по личному ощущению;
нет разницы между влиянием на систему и срочностью исправления;
в тикете не описано влияние на пользователя и бизнес;
все дефекты автоматически получают High, чтобы их «не потеряли»;
команда не проводит регулярный triage и копит спорные баги;
после релизов никто не проверяет, были ли приоритеты адекватными.
Если у вас слишком много Critical и P0, проблема почти всегда не в продукте, а в том, что шкала классификации потеряла смысл.
12. Шаблон договоренности для команды QA, разработки и продукта
Полезно один раз зафиксировать короткое внутреннее соглашение.
1. QA ставит предварительный Severity по таблице критериев.
2. Priority назначается на triage или ответственным менеджером.
3. Для P0/P1 есть отдельный SLA реакции.
4. Баг без описания влияния и шагов не идет в triage.
5. Раз в квартал команда пересматривает шкалу по реальным кейсам.Чек-лист хорошего баг-репорта для triage
Понятный заголовок
Шаги воспроизведения
Ожидаемый и фактический результат
Окружение и версия
Влияние на пользователя и бизнес
Предварительный Severity с коротким обоснованием
SLA по Priority: без этого уровни быстро теряют смысл
| Priority | Какой реакции ждет команда |
|---|---|
| P0 | Немедленный разбор и решение в текущем инцидентном окне |
| P1 | Исправление в ближайшем релизном цикле или ближайшем спринте |
| P2 | Планирование в текущий или следующий рабочий цикл без режима аварии |
| P3 | Бэклог с периодическим пересмотром по мере появления окна |
Почему один и тот же баг получает разный Priority в разных продуктах
в e-commerce сбой в корзине или оплате почти всегда выше по срочности, чем аналогичный дефект в backoffice;
в финтехе даже небольшой расчетный баг быстро поднимается в высокий приоритет из-за денег и регуляторных рисков;
для внутренних систем часть визуальных дефектов почти не влияет на бизнес, а на внешней витрине тот же дефект может быть P1;
для B2B SaaS один крупный клиент может сделать средний по технике баг высоким по срочности.
13. Частые вопросы
Может ли QA ставить Priority?
Предварительно — да, как рекомендацию. Но финально Priority лучше закреплять за triage, продактом или владельцем релиза.
Можно ли объединить Severity и Priority в одну шкалу?
Можно, но это обычно упрощает учет слишком сильно и снова смешивает техническую тяжесть с бизнес-срочностью. Для зрелых команд лучше держать их отдельно.
Что делать, если разработчик не согласен с Severity?
Свести разговор к критериям: какой сценарий сломан, есть ли обходной путь, какой масштаб воздействия. Если споры повторяются, нужен общий triage-процесс, а не переписка в комментариях.
Нужно ли ставить High Priority на все баги перед релизом?
Нет. Иначе приоритеты обесцениваются. Важна не дата релиза сама по себе, а влияние бага на релизное решение.
Как часто пересматривать правила классификации?
Раз в квартал или после заметных релизных инцидентов. Если команда видит, что критичные дефекты регулярно получают неправильный приоритет, шкалу нужно обновлять.
14. Итог: договоренность о важности бага — это часть качества, а не бюрократия
Главный вывод: Severity и Priority нужны не ради красивых полей в баг-трекере. Они нужны, чтобы команда одинаково понимала ущерб дефекта и порядок реакции на него.
Если QA, разработка и продукт заранее договорились о критериях, баги перестают быть поводом для споров и становятся нормальным управляемым потоком работы. А это напрямую влияет на качество релизов.
А лучшие вакансии для тестировщиков QA ручных и автоматизированных ищите на hirehi.ru