Ключевое различие

Серьёзность и приоритет — два наиболее путаемых понятия в управлении багами. Путаница приводит к неправильному распределению ресурсов — критические баги игнорируются, а косметические получают срочное внимание.

Серьёзность (Severity) = Насколько серьёзно влияние на систему? (Техническая оценка) Приоритет (Priority) = Как скоро нужно исправить? (Бизнес-решение)

Они связаны, но независимы. Баг может иметь высокую серьёзность и низкий приоритет, или наоборот.

Уровни серьёзности

Серьёзность — объективная техническая оценка влияния бага на систему.

Критическая (S1)

Падение системы, потеря данных, брешь безопасности или полный отказ функции без обходного пути.

Примеры:

  • Приложение падает при запуске для всех пользователей
  • Платёжная система списывает средства дважды
  • Данные пользователей доступны неавторизованным лицам

Серьёзная (S2)

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

Примеры:

  • Вход не работает для пользователей с двухфакторной аутентификацией
  • Поиск возвращает некорректные результаты со спецсимволами
  • Экспорт в PDF создаёт повреждённые файлы

Незначительная (S3)

Функция работает, но с косметическими проблемами, мелкими проблемами юзабилити или сбоями в edge cases.

Примеры:

  • Формат даты MM/DD/YYYY вместо DD/MM/YYYY для европейской локали
  • Текст подсказки перекрывает соседнюю кнопку на маленьких экранах

Тривиальная (S4)

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

Примеры:

  • Опечатка в подвале: «Copyrite» вместо «Copyright»
  • Цвет кнопки #0066CC вместо указанного в дизайне #0066FF

Уровни приоритета

Приоритет — бизнес-решение о том, когда баг должен быть исправлен.

P1 — Немедленный (Исправить сейчас)

Должен быть исправлен немедленно. Блокирует релиз или наносит активный вред.

P2 — Высокий (Исправить в этом спринте)

Должен быть исправлен в текущем спринте. Важен для качества релиза.

P3 — Средний (Исправить в следующем спринте)

Должен быть исправлен скоро, но может подождать следующего спринта.

P4 — Низкий (Бэклог)

Исправить при удобном случае. Нет немедленного бизнес-влияния.

Когда серьёзность и приоритет не совпадают

Высокая серьёзность, низкий приоритет

Баг технически серьёзен, но затрагивает функцию, которой никто не пользуется.

Пример: Приложение падает при загрузке файла ровно 2GB. Лимит системы — 1GB, и UI запрещает загрузку свыше 1GB. Crash существует, но пользователи не могут его вызвать при нормальном использовании.

Низкая серьёзность, высокий приоритет

Баг технически мелкий, но имеет значительное бизнес-влияние.

Пример: Имя CEO неправильно написано на странице «О нас». Технически тривиально (S4), но CEO заметил, и это позорит на встречах с инвесторами. Приоритет: P1.

Матрица приоритетов

Высокий приоритетНизкий приоритет
Высокая серьёзностьИсправить немедленноИсправить из бэклога
Низкая серьёзностьИсправить в этом спринтеИсправить при случае

Кто что устанавливает?

АтрибутУстанавливаетНа основании
СерьёзностьQA EngineerОценка технического влияния
ПриоритетProduct Owner / ManagerБизнес-влияние, дедлайны, потребности клиентов

Упражнение: Классифицируйте баги

Назначьте серьёзность (S1-S4) и приоритет (P1-P4) каждому багу. Обоснуйте выбор.

  1. Мобильное приложение падает при повороте экрана во время воспроизведения видео
  2. Ссылка «Terms of Service» на странице регистрации ведёт на страницу 404
  3. Дашборд администратора показывает данные графиков с отставанием в 1 час
  4. Email-уведомления используют старый логотип (ребрендинг был 2 месяца назад)
  5. Токен сброса пароля не истекает — действует бессрочно
Решение

1. Crash при повороте во время видео: S2/P2 — Crash ограничен конкретным действием 2. Terms of Service 404: S3/P1 — Риск юридического compliance, все новые пользователи видят страницу регистрации 3. Дашборд отстаёт на 1 час: S2/P2 — Бизнес-решения зависят от точных данных 4. Старый логотип в письмах: S4/P3 — Консистентность бренда важна, но не срочно 5. Токен сброса не истекает: S1/P1 — Критическая уязвимость безопасности

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

  1. Считать серьёзность и приоритет одним и тем же — они измеряют разное
  2. QA единолично устанавливает приоритет — приоритет — бизнес-решение
  3. Завышать серьёзность для ускорения исправления — подрывает доверие к QA
  4. Не пересматривать приоритет со временем — баг P3, существующий 6 месяцев при жалобах пользователей, должен быть переоценён

Ключевые выводы

  • Серьёзность измеряет техническое влияние (объективно); приоритет — бизнес-срочность (субъективно)
  • Они независимы — баг может быть высокой серьёзности/низкого приоритета и наоборот
  • QA оценивает серьёзность; Product Owner/Manager устанавливает приоритет
  • Приоритет корректируется на triage-встречах с учётом бизнес-контекста
  • Никогда не завышайте серьёзность для манипуляции системой — это разрушает доверие к QA