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

Две шкалы, которые путают все. Учимся расставлять их осознанно и защищать свою оценку фактами. С тренажёром.

Две шкалы, которые постоянно путают даже опытные команды. Разница простая:

• Серьёзность (severity) — насколько сломан продукт. Оценивает тестировщик, это техническая характеристика.
• Приоритет (priority) — когда чинить. Оценивает продакт или лид, это бизнес-решение.

Шкала серьёзности

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

Шкала приоритета

• High — чинить в текущей итерации, до релиза. Блокирует пользователей или деньги.
• Medium — в ближайших планах.
• Low — когда будет время.

Как обосновывать оценку

Оценка «мне кажется, это критично» не работает. Работают факты:

• Охват — сколько пользователей затронуто: все, только мобильные, только один браузер, 0,3% клиентов.
• Деньги — теряется ли выручка прямо сейчас.
• Данные — теряются ли или портятся данные пользователя. Это почти всегда поднимает оценку.
• Обходной путь — есть ли и насколько он очевиден для обычного пользователя.
• Репутация и юридические риски — персональные данные, реклама, публичные тексты.
• Частота — воспроизводится всегда или раз в двадцать попыток.

Тренажёр: расставьте оценки

Разговор о приоритете

Ситуация: вы считаете дефект критичным, продакт — нет. Правильная тактика:

1. Убрать эмоции и оценочные слова.
2. Назвать охват и последствия числами: «затронуты все, кто платит картой, это 60% заказов».
3. Назвать риск невыпуска и риск выпуска. Оба.
4. Предложить компромисс: временное решение, отключение функции, предупреждение для пользователей.
5. Зафиксировать решение письменно в задаче. Не для «прикрытия», а чтобы через месяц не выяснять, кто что решил.

Итог модуля

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