Severity и Priority: в чём разница и как их проставлять

Вопрос, который задают почти на каждом собеседовании, и место, где путаются даже работающие тестировщики. Разница простая, если запомнить, кто отвечает за каждое из полей.

Разница в одном предложении

Severity (серьёзность) — насколько сильно сломано. Priority (приоритет) — насколько срочно чинить. Первое — техническая характеристика дефекта, второе — решение о порядке работ.

	Severity	Priority
Отвечает на вопрос	Что именно сломалось и насколько	Когда это чинить
Кто выставляет	Тестировщик	Продакт, менеджер, тимлид
От чего зависит	От поведения системы	От бизнеса, сроков, релиза
Меняется ли со временем	Почти никогда	Часто: перед релизом всё меняется

Отсюда главное правило: тестировщик не спорит о приоритете. Он даёт факты и оценку серьёзности, а очередь работ определяет тот, кто отвечает за продукт.

Шкала severity

Уровень	Когда ставить	Пример
Blocker	Работа с продуктом или тестирование невозможны	Не открывается главная, не работает вход
Critical	Ключевая функция не работает, обхода нет; потеря данных; утечка	Оплата не проходит; чужой заказ виден по прямой ссылке
Major	Функция работает частично, обходной путь есть	Поиск не находит по части слова, но фильтры работают
Minor	Мелкое несоответствие, на сценарий почти не влияет	Сообщение об ошибке не по формату из макета
Trivial	Косметика	Лишний отступ, опечатка в редком месте

Почему severity и priority расходятся

Именно этот вопрос задают на собеседовании. Классические пары:

Ситуация	Severity	Priority	Почему
Опечатка в названии компании на главной	Trivial	Highest	Видят все, бьёт по репутации, чинится за минуту
Падение при редком сочетании настроек	Critical	Low	Ломается серьёзно, но встречается у единиц
Не работает кнопка в админке для двух сотрудников	Major	Low	Есть обход, пользователей мало
Съехала вёрстка баннера акции, которая стартует завтра	Minor	Highest	Дата не сдвигается

Общий смысл: severity смотрит внутрь системы, priority — наружу, на людей, деньги и сроки. Одно не выводится из другого.

Как обосновать оценку, чтобы её приняли

Оценка без аргумента вызывает спор. Оценка с аргументом — обсуждение по существу. В репорте достаточно одной строки, отвечающей на три вопроса.

1. Что не работает. Не «корзина сломана», а «товары исчезают после перезагрузки».
2. Есть ли обход. «Обхода нет» или «можно добавить заново, но это неочевидно».
3. Кого задевает. «Всех пользователей на этапе оформления» или «только администраторов в редком сценарии».

После такой строки разговор про severity занимает секунды. Полный шаблон полей — в шаблоне баг-репорта.

Что делать, если приоритет занизили

Ситуация обычная: вы завели Critical, а приоритет поставили Low. Это не повод спорить, но и не повод молчать.

• Убедитесь, что в репорте видно последствие, а не только симптом. Часто приоритет занижают, потому что из текста непонятно, чем это грозит.
• Добавьте цифры, если они есть: сколько заказов затронуто, с какой частотой воспроизводится.
• Если решение всё равно «не чиним сейчас» — зафиксируйте это в задаче. Тогда после инцидента будет видно, что риск был известен, а не пропущен.

Задача тестировщика — чтобы решение приняли осознанно, а не чтобы приняли его решение.

Как severity влияет на работу команды

Оценка — не формальность в поле, а вход в несколько процессов сразу, и поэтому её точность важна.

• Критерии выпуска. Во многих командах релиз не уходит, пока есть открытые Blocker и Critical. Завышенная оценка задерживает выпуск, заниженная — пропускает проблему в прод.
• Разбор инцидентов. После сбоя смотрят, был ли дефект известен и с какой оценкой. Заниженный severity в этот момент выглядит очень плохо.
• Метрики качества. Распределение дефектов по серьёзности показывает, где продукт слабее. Если все дефекты Major, картина бесполезна.
• Планирование. По количеству Critical оценивают, сколько времени уйдёт на стабилизацию перед релизом.

Отсюда простое правило: оценка ставится по состоянию системы, а не по тому, как удобнее выглядеть в отчёте. Тестировщик, который занижает серьёзность, чтобы «не портить статистику», ломает сразу все четыре процесса.

Чем шкалы отличаются в разных командах

Названия уровней не стандартизированы. Где-то используют цифры от 1 до 5, где-то только три уровня, где-то одно поле вместо двух. Спорить о правильности бессмысленно — важно, чтобы внутри команды понимали одинаково.

Практический совет на новом месте: в первую неделю откройте два десятка закрытых дефектов и посмотрите, какие оценки там стоят. Это точнее любой инструкции — вы увидите, что команда на самом деле считает Critical.