В чём разница между Priority и Siverity?

Разница между Priority и Severity

Это два разных параметра бага, которые часто путают. Priority отвечает на вопрос ЧТО СРОЧНО НУЖНО ИСПРАВИТЬ, а Severity отвечает на вопрос НАСКОЛЬКО ПЛОХО БАГИ ВЛИЯЮТ НА ПРИЛОЖЕНИЕ.

Severity (Серьёзность)

Severity описывает СТЕПЕНЬ ПОВРЕЖДЕНИЯ функциональности. Это техническая характеристика.

Уровни Severity:

Critical / Blocker:

• Приложение полностью не работает
• Невозможно выполнить основной сценарий
• Потеря данных
• Пример: Кнопка "Оплатить" не работает в приложении доставки еды

High / Major:

• Функционал работает с серьёзными проблемами
• Отсутствует важная часть функциональности
• Юзер может обойти баг, но с трудностями
• Пример: Оформление заказа требует 5 кликов вместо 1

Medium / Normal:

• Функционал работает, но с недостатками
• Эстетические проблемы
• Незначительные ошибки в расчётах
• Пример: Иконка на кнопке отображается неправильно

Low / Minor:

• Функционал полностью работает
• Только косметические проблемы
• Не влияет на пользовательский опыт
• Пример: Опечатка в тексте помощи

Trivial:

• Улучшение, а не баг
• Практически не влияет на приложение
• Пример: Предложение изменить цвет иконки

Priority (Приоритет)

Priority описывает СРОЧНОСТЬ ИСПРАВЛЕНИЯ. Это бизнес-решение.

Уровни Priority:

Critical / P0 / Urgent:

• Нужно исправить ЧЕМ СКОРЕЕ, может быть уже сегодня
• Влияет на доход компании
• Много пользователей затронуто
• Пример: После нового релиза 50% юзеров не могут зарегистрироваться

High / P1:

• Нужно исправить в этом спринте
• Влияет на важный функционал
• Нарушает user journey
• Пример: Кнопка сохранения профиля иногда не работает

Medium / P2:

• Нужно исправить в ближайших спринтах
• Не критично, но заметно
• Пример: UI выглядит неправильно на планшетах

Low / P3:

• Можно исправить потом
• Не спешно
• Пример: Улучшение в animation

Trivial / P4:

• Очень низкий приоритет
• Может быть добавлено в следующий год
• Пример: Изменить цвет какой-то иконки

Таблица сравнения

Практические примеры

Пример 1: Severity = High, Priority = Low

• Баг: Приложение крашится при попытке экспорта данных в PDF
• Severity High: Потеря функционала
• Priority Low: Только 0.1% пользователей экспортируют в PDF
• Решение: Исправить, но не срочно

Пример 2: Severity = Low, Priority = Critical

• Баг: Опечатка в сообщении про скидку - вместо "50% скидка" написано "5% скидка"
• Severity Low: Это просто текст, функционал работает
• Priority Critical: Это влияет на продажи, нужно исправить сегодня
• Решение: Срочный hotfix

Пример 3: Severity = Critical, Priority = Critical

• Баг: Невозможно войти в приложение после нового релиза
• Severity Critical: Приложение не работает вообще
• Priority Critical: Все пользователи затронуты
• Решение: Немедленный откат или срочный fix

Пример 4: Severity = Low, Priority = Low

• Баг: Иконка в главном меню выглядит нечётко на 4K экранах
• Severity Low: Это косметическая проблема
• Priority Low: Только 2% пользователей используют 4K
• Решение: Можно исправить когда будет время

Как я определяю Severity и Priority

При создании тикета я пишу:

Severity: High

• Обоснование: Функция критична, не работает полностью, влияет на основной функционал

Priority: P1

• Обоснование: 20% наших пользователей это используют, нужно в текущий спринт

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

Важные правила

• Баг с Severity Critical не обязательно имеет Priority Critical
• Баг с Severity Low может иметь Priority Critical
• Severity это ФАКТИЧЕСКОЕ состояние, Priority это СТРАТЕГИЧЕСКОЕ решение
• QA определяет Severity, PM определяет Priority
• После срочного hotfix Priority может измениться, а Severity остаётся той же

Вывод

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