Как определить какой severity у бага?

Определение Severity бага: стратегия опытного QA

Severity (серьёзность) бага — это оценка степени его влияния на работоспособность системы или компонента. В отличие от Priority (приоритета), который отражает срочность исправления с точки зрения бизнес-процессов, Severity объективно описывает глубину технической проблемы. За 10+ лет работы я выработал четкий подход к ее определению.

Ключевые критерии для оценки

Я определяю Severity, последовательно анализируя баг по следующим параметрам:

• Масштаб влияния на функционал: Насколько критично нарушение? Блокируется ли основная функция или страдает второстепенная?
• Распространенность: Проблема возникает всегда (100%) или при специфичных условиях?
• Влияние на данные: Приводит ли баг к потере, порче или некорректному отображению данных пользователя?
• Стабильность системы: Вызывает ли ошибка падение приложения (crash), зависание (freeze) или нестабильную работу?
• Обходные пути: Существует ли для пользователя альтернативный способ выполнить ту же задачу без ошибки?
• Влияние на других пользователей: Баг публичный (затрагивает всех) или проявляется в особых сценариях/ролях?

Стандартные уровни Severity и примеры

Обычно используется шкала из 4-5 уровней. Я предпочитаю следующую градацию:

S1: Critical (Критический)

• Критерии: Полный отказ основного функционала, потеря данных, крах системы, критическая уязвимость безопасности.
• Пример: Кнопка "Оплатить" в интернет-банке приводит к ошибке 500, платеж не проходит, деньги "зависают".

  # Условный пример: код, вызывающий критическую ошибку
  def process_payment(amount, account):
      if amount <= 0:
          raise SystemError("Payment gateway failure") # Некорректная обработка приводит к падению сервиса
      # ... логика оплаты ...
  

• Действие: Немедленное уведомление команды, блокировка релиза.

S2: Major (Высокий)

• Критерии: Основная функция работает некорректно, но есть обходной путь. Серьезное отклонение от требований.
• Пример: В отчете "Финансовые итоги" за текущий месяц не отображаются данные по новым категориям расходов. Отчет можно сформировать вручную, экспортировав данные в Excel.
• Действие: Должен быть исправлен в текущем спринте.

S3: Medium (Средний)

• Критерии: Проблема во второстепенной функции, некорректное сообщение об ошибке, косметическая проблема, влияющая на восприятие.
• Пример: В мобильном приложении при повороте экрана на странице профиля "ломается" верстка, часть кнопок уезжает за границы экрана. Функционал доступен после возврата к портретной ориентации.

  // Условный пример: баг, влияющий на UI/UX
  function handleScreenRotation() {
      // Отсутствует перерасчет layout при изменении ориентации
      if (screen.orientation.type.includes('landscape')) {
          applyPortraitLayout(); // Применяются стили для портретного режима!
      }
  }
  

• Действие: Планируется на ближайшие релизы.

S4: Low / Minor (Низкий / Незначительный)

• Критерии: Опечатка в тексте, несоответствие оттенка кнопки гайдлайнам, мелкая косметическая погрешность, не влияющая на функционал.
• Пример: Всплывающее уведомление с текстом "Операция завершена успешно".
• Действие: Исправляется по остаточному принципу или батчем.

Процесс принятия решения на практике

1. Воспроизведение и изоляция: В первую очередь я точно определяю шаги для воспроизведения и контекст (ОС, браузер, данные).
2. Сверка с требованиями: Я сравниваю фактическое поведение с ожидаемым, описанным в спецификации или user story.
3. Анализ по критериям: Прохожу по списку критериев выше, отвечая на вопросы.
4. Консультация с командой: В спорных случаях обсуждаю с разработчиком (технический аспект) и продакт-менеджером (бизнес-аспект). Например, баг с UI может быть Medium для QA, но Major для PM, если он на ключевой странице для конверсии.
5. Документирование в баг-трекинге: Четко указываю выбранный уровень Severity в соответствующем поле (например, Severity: Major), а в описании аргументирую, почему выбран именно он, ссылаясь на критерии.

Важно: Severity может быть пересмотрен. Если в ходе разработки выяснится, что проблема глубже или, наоборот, проще, чем казалось, уровень корректируется. Главное — четкая логика и консенсус в команде, чтобы все говорили на одном языке. Это основа эффективного планирования работ и управления качеством продукта.