Для чего нужен Severity?

Severity — критическое свойство для приоритизации багов

Severity (серьёзность) — это один из ключевых атрибутов дефекта в системах управления ошибками, который определяет уровень влияния ошибки на работоспособность приложения. Это не менее важно, чем Priority, и QA инженер должен уметь правильно классифицировать баги по severity.

Основное назначение Severity

Severity определяет, насколько критична найденная ошибка с точки зрения функциональности приложения:

• Помогает разработчикам приоритизировать работу — баги с высоким severity обычно фиксятся в первую очередь
• Влияет на release decision — приложение не может быть выпущено, если есть Critical или Blocker баги
• Помогает менеджерам риски оценить — высокая severity = высокий риск для бизнеса
• Используется в метриках качества — количество Critical багов отслеживается как KPI
• Определяет сроки фиксации — Critical ошибки должны быть закрыты до релиза

Уровни Severity

Ниже представлена стандартная классификация severity (разные компании могут использовать немного разные названия):

1. Critical/Blocker — критическая ошибка

• Приложение полностью неработоспособно или потеряна основная функциональность
• Примеры:
  • Приложение крашится при старте
  • Невозможно авторизоваться (основная функция)
  • Потеря данных пользователя
  • Платежная система полностью не работает (в платежном приложении)
• Действие: Фиксится немедленно, часто требует hotfix на продакшене

2. High/Major — серьёзная ошибка

• Существенное влияние на функциональность, ключевой workflow нарушен
• Примеры:
  • Основная функция работает неправильно (например, поиск не возвращает результаты)
  • Значительная часть функциональности недоступна
  • Ошибки в расчётах (финансовые данные неверны)
  • UI полностью разломан на определённом экране
• Действие: Должна быть закрыта до релиза в production

3. Medium/Normal — средняя ошибка

• Частичное нарушение функциональности, пользователь может найти обходной путь
• Примеры:
  • Опечатка в тексте
  • Кнопка размещена не совсем правильно
  • Второстепенная функция не работает (но основные функции работают)
  • Сообщение об ошибке неинформативно
• Действие: Должна быть в стандартном sprint'е, можно отложить на следующий релиз

4. Low/Minor — низкая ошибка

• Косметические дефекты, не влияет на функциональность
• Примеры:
  • Небольшое смещение элемента UI на 2px
  • Неправильный цвет в небольшой части интерфейса
  • Опечатка в справке
  • Некритичные элементы размещены не оптимально
• Действие: Может быть исправлено когда будет время, часто откладывается

5. Trivial/Wishlist — незначительно

• Улучшения и пожелания, не баги в классическом смысле
• Примеры:
  • Было бы хорошо добавить тёмный режим
  • Можно сделать кнопку больше?
  • Улучшения в документации
• Действие: Рассматривается как feature request, не обязательно в текущем релизе

Severity vs Priority — важное различие

Много QA путают эти два понятия, но это разные атрибуты:

• Severity: Влияние на функциональность (устанавливает QA инженер)
• Priority: Очередность фиксации (устанавливает Project Manager)
• Пример: Critical баг в малоиспользуемой функции может иметь низкую priority, если это не критично для бизнеса
• Влияние на release: Оба параметра важны, но Critical/High severity блокирует релиз в любом случае

Как правильно устанавливать Severity

При создании bug report'а в Jira, Azure DevOps или другом трекере:

1. Проанализируй влияние на пользователя:

   • Может ли пользователь вообще использовать приложение?
   • Какая часть функциональности нарушена?
   • Есть ли обходной путь?

2. Определи область влияния:

   • Влияет ли на одного пользователя или на всех?
   • Какой процент пользователей затронут?

3. Учти данные:

   • Есть ли потеря данных?
   • Может ли привести к финансовым потерям?

4. Примени стандарты компании — обычно в каждой компании есть гайдлайны

Практические примеры из реальной жизни

Сценарий 1: Кнопка Оплатить не отправляет запрос на сервер

• Severity: Critical (основная функция не работает)
• Действие: Фиксится немедленно

Сценарий 2: Поле для ввода email не валидирует email корректно

• Severity: High (нарушает основной workflow)
• Действие: Должна быть закрыта до релиза

Сценарий 3: Название кнопки содержит опечатку

• Severity: Low (косметический дефект)
• Действие: Может быть исправлено позже

Сценарий 4: При отправке множества запросов подряд UI зависает на 0.5 сек

• Severity: Medium (функция работает, но UX нарушен)
• Действие: Нужно исправить, но не блокирует релиз

Правильная классификация severity — это базовый навык QA инженера, который влияет на качество выпускаемого продукта и репутацию QA отдела.