Какие знаешь уровни критичности дефекта?

Уровни критичности дефекта в тестировании программного обеспечения

Критичность дефекта (или Severity) — это параметр, который оценивает степень влияния найденной ошибки на работоспособность системы, её ключевые функции и, в конечном итоге, на пользователя или бизнес-процессы. Определение уровня критичности — одна из ключевых задач QA Engineer, так как она напрямую влияет на порядок исправления дефектов и планирование работ разработчиков. Обычно используется градация от блокирующих ошибок до косметических. Я, как практикующий специалист, использую и рекомендую следующую классификацию уровней.

Стандартная классификация уровней критичности (Severity Levels)

В большинстве проектов и систем управления дефектами (например, Jira, Bugzilla, YouTrack) принята четырёхуровневая или пятиуровневая шкала. Вот наиболее распространённая и подробная градация:

1. S1: Critical / Blocker (Критический / Блокирующий)

    *   Дефект полностью блокирует работу ключевой функциональности системы или делает её невозможной для использования.
    *   **Примеры:** Приложение не запускается; критическая функция (например, оплата в банковском приложении) не работает; система падает (**краш**) при выполнении стандартной операции; потеря данных.
    *   Такие дефекты требуют немедленного исправления, часто они являются критерием для остановки выпуска версии (**stop-ship criteria**).

1. S2: High / Major (Высокий / Существенный)

    *   Дефект серьёзно нарушает работу важной функции, но не блокирует всю систему. Работа возможна с использованием обходных путей или других функций.
    *   **Примеры:** Основная функция работает некорректно (например, поиск возвращает неверные результаты); серьёзные ошибки в бизнес-логике, влияющие на результат; проблемы с безопасностью, не являющиеся критическими уязвимостьями.
    *   Дефекты этого уровня исправляются в ближайших плановых релизах.

1. S3: Medium / Normal (Средний / Обычный)

    *   Дефект влияет на неключевые функции или вызывает некритические проблемы в работе. Система остаётся работоспособной, но пользовательский опыт снижается.
    *   **Примеры:** Неправильное сообщение валидации в поле формы; некритичное отклонение от требований UI/UX; нерабочая вспомогательная функция (например, кнопка «Поделиться» в определённом контексте).
    *   Эти ошибки планируются для исправления в следующих итерациях разработки.

1. S4: Low / Minor / Trivial (Низкий / Незначительный / Косметический)

    *   Дефект не влияет на функциональность или бизнес-процессы. Это чаще всего косметические проблемы или очень мелкие недочёты.
    *   **Примеры:** Несоответствие цвета кнопки гайдлайнам в одном месте; неидеальное выравнивание текста; опечатка в тексте, не влияющая на понимание.
    *   Такие дефекты часто исправляются «по остаточному принципу» или могут быть отложены на долгий срок.

Практическое применение и важные принципы

Определение уровня критичности — это не просто механический процесс, он требует анализа контекста.

• Контекст продукта: Для банковского приложения ошибка в расчёте процентов — Critical. Для того же расчёта в демо-версии калькулятора — возможно, Medium.
• Приоритизация vs. Критичность: Важно не смешивать Severity (техническая серьёзность) и Priority (приоритет исправления с бизнес-точки зрения). Бизнес может назначить высокий приоритет (P1) косметической ошибке (S4), если она на главной странице сайта перед крупной маркетинговой кампанией.
• Критерии в тест-плане: Чтобы минимизировать субъективность, критерии оценки Severity должны быть заранее согласованы и зафиксированы в тест-плане или стандартах проекта. Например:

**Критерий для Severity-Critical (S1):**
- Система не запускается для >50% пользователей.
- Ключевая бизнес-функция (определена в списке KBF) недоступна.
- Происходит потеря или некорректное сохранение данных ядра системы.

• Связь с другими атрибутами: Критичность часто связана с приоритетом (Priority) и статусом дефекта (Status) в баг -треккинговой системе. Например, дефект S1 почти всегда автоматически получает высший приоритет P1.

Пример из реальной практики

Рассмотрим пример для иллюстрации. В мобильном приложении для онлайн -покупок обнаружены два дефекта:

1. После нажатия «Оплатить» приложение зависает и требует перезагрузки. Анализ: Ключевая бизнес-функция (оплата) полностью недоступна. Пользователь не может совершить покупку. Решение: Уровень критичности — S1 (Critical).
2. На странице профиля пользователя иконка «Настройки» отображается с размытым контуром. Анализ: Функция настроек работает, навигация возможна. Проблема — чисто визуальная, не влияющая на функциональность. Решение: Уровень критичности — S4 (Low / Cosmetic).

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