В чем разница между приоритетом и серьезностью?

Разница между приоритетом (Priority) и серьезностью (Severity)

В тестировании ПО, приоритет и серьезность — это два взаимосвязанных, но фундаментально различных атрибута дефекта, которые часто путают. Их корректное разделение критически важно для эффективного управления процессом исправления ошибок и расстановки задач в команде разработки.

Определения и ключевые отличия

Серьезность (Severity) — это объективная характеристика дефекта, которая показывает степень его влияния на функциональность, стабильность или безопасность системы. Она отвечает на вопрос: "Насколько серьезно нарушение, вызванное этим багом?"

Приоритет (Priority) — это субъективная характеристика, определяющая очередность устранения дефекта. Она отвечает на вопрос: "Как быстро этот баг должен быть исправлен?" Приоритет напрямую зависит от бизнес-контекста, релизных планов и стратегических целей.

Уровни серьезности (Severity Levels)

Как правило, выделяют четыре основных уровня:

• Критическая (Critical/Blocker): Дефект, который полностью блокирует работу системы, приводит к ее падению, потере данных или делает ключевую функцию недоступной.

  # Пример (условный): Падение сервера при отправке запроса.
  # POST /api/process_payment -> Возвращает 500 Internal Server Error и сервис недоступен.
  

• Высокая (Major): Ключевая функция работает некорректно, но система не падает. Нет обходного пути.

  # Пример: Невозможно завершить покупку в корзине.
  Когда я нажимаю "Оплатить"
  Тогда я вижу сообщение "Ошибка валидации" без деталей
  И заказ не создается
  

• Средняя (Medium/Minor): Функция работает с отклонениями, но есть обходной путь. Дефект не влияет на основной поток.

  // Пример: Неверное сообщение об ошибке при некритичной валидации.
  public String getErrorMessage() {
      return "Неверный формат телефона"; // На самом деле ошибка была в email
  }
  

• Низкая (Low/Trivial): Косметические проблемы: опечатки в тексте, незначительное смещение элементов UI, которые не влияют на функциональность.

Уровни приоритета (Priority Levels)

• Высокий (High): Дефект должен быть исправлен немедленно, в текущем спринте или билде. Часто относится к багам, блокирующим дальнейшее тестирование или критические для релиза.
• Средний (Medium): Дефект должен быть исправлен в одном из ближайших спринтов.
• Низкий (Low): Дефект может быть исправлен, когда у команды появится свободное время, или отложен до будущих версий.

Соотношение серьезности и приоритета на практике

Важно понимать, что эти параметры не всегда прямо пропорциональны. Бизнес-логика часто определяет приоритет.

• Пример 1: Высокая серьезность, но низкий приоритет.

    **Дефект:** На странице "О компании" приложение падает (Critical Severity).  
    **Контекст:** Внутренний релиз основного продукта для клиентов через 2 дня.  
    **Решение:** Страница "О компании" не является критической для работоспособности продукта. Приоритет будет **Low/Medium**. Команда сфокусируется на багах в платежном модуле.

• Пример 2: Низкая серьезность, но высокий приоритет.

    **Дефект:** Опечатка в логотипе компании на главной странице (Low Severity).  
    **Контекст:** Логотип написан с ошибкой, что вредит репутации. Релиз завтра.  
    **Решение:** Приоритет **High**, так как бизнес-риски велики, хотя функционально все работает.

Кто принимает решение?

• Серьезность (Severity) в идеале определяет тестировщик (QA Engineer), так как он объективно оценивает влияние бага на систему.
• Приоритет (Priority) устанавливает менеджер продукта (Product Owner, Project Manager) или владелец продукта, поскольку для этого требуется понимание бизнес-стратегии, сроков и дорожной карты.

Вывод для процесса автоматизации

При создании автотестов и работе с баг-трекинг системами (Jira, Azure DevOps) это разделение крайне важно:

1. Автотесты часто фокусируются на проверке функционала с высокой серьезностью (критические пути).
2. Падение автотеста с Critical или Major severity должно триггерить высокий приоритет на исследование, так как это угрожает стабильности продукта.
3. В отчетах о тестировании необходимо четко разделять метрики по severity (качество продукта) и priority (эффективность процессов команды).

Таким образом, серьезность — это техническая мера критичности дефекта, а приоритет — управленческая директива о порядке его исправления. Грамотное владение этими понятиями позволяет QA-инженеру не просто находить баги, но и эффективно коммуницировать с командой, аргументированно влияя на процесс разработки.