Какие знаешь критерии оценки дефекта?

Критерии оценки дефектов в QA

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

1. Критерии, определяющие влияние на продукт и пользователей

• Серьезность (Severity) — объективная мера степени влияния дефекта на работоспособность системы. Часто имеет градации:

    *   **Блокирующая (Blocker/Show-stopper):** Система неработоспособна, ключевая функция недоступна. Пример: падение приложения при запуске, невозможность совершить покупку.
    *   **Критическая (Critical):** Основная функция работает некорректно, нет обходного пути. Пример: неверный расчет итоговой суммы заказа, потеря сохраненных данных.
    *   **Значительная (Major):** Функция работает, но с существенными отклонениями, есть обходной путь. Пример: некорректное отображение данных в отчете, сбой в неосновном сценарии.
    *   **Незначительная (Minor):** Проблема не влияет на основную функциональность, часто связана с UI/UX. Пример: опечатка в тексте, неверный оттенок кнопки.
    *   **Тривиальная (Trivial/Cosmetic):** Несущественные недочеты. Пример: неидеальное выравнивание элемента, который редко видит пользователь.

• Приоритет (Priority) — субъективное указание на очередность исправления дефекта с точки зрения бизнеса и релизного планирования. Уровни:

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

Важно: Серьезность и приоритет часто связаны, но не всегда. Например, опечатка в лозунге на главной странице (низкая серьезность) может получить высокий приоритет из-за репутационных рисков.

2. Критерии, связанные с воспроизведением и анализом

• Воспроизводимость (Reproducibility): Насколько стабильно и при каких условиях проявляется ошибка.

    *   **Стабильная (Consistent):** Дефект воспроизводится каждый раз по четкому сценарию.
    *   **Нестабильная (Intermittent/Random):** Воспроизводится время от времени, что усложняет анализ и фиксацию.
    *   **Единичная (Once):** Воспроизведена единожды, что требует тщательного сбора контекста (логи, скриншоты, видео).

• Область воздействия (Scope/Impact Area): Какие именно компоненты, модули или функции системы затронуты. Помогает оценить объем регрессионного тестирования после фикса.

• Сценарий возникновения (Steps to Reproduce): Четкая, последовательная инструкция для воспроизведения. От ее качества напрямую зависит скорость анализа дефекта разработчиком.

3. Дополнительные и комплексные критерии

• Риск (Risk): Оценка потенциального ущерба для бизнеса, безопасности или пользователей, если дефект уйдет в прод. Может повысить приоритет даже у дефекта со средней серьезностью.
• Стоимость исправления (Cost of Fix): Оценка трудозатрат на анализ, правку кода и тестирование. Иногда низкоприоритетный, но дорогой в исправлении баг может быть отложен.
• Вероятность возникновения (Probability/Likelihood): Насколько часто типичный пользователь может столкнуться с этой проблемой. Редкий, но критический баг может иметь более низкий приоритет, чем частый, но незначительный.

Практический пример оценки в баг-трекинговой системе

При создании отчета о дефекте эти критерии формализуются в полях. Вот пример структурированного описания:

**Заголовок:** [Критично] Приложение падает при попытке оплаты картой после ввода CVV.
**Серьезность:** Critical
**Приоритет:** High
**Среда:** iOS 17.5, iPhone 14, версия приложения 2.5.1
**Шаги воспроизведения:**
1. Добавить товар в корзину.
2. Перейти к оформлению заказа.
3. Выбрать оплату картой.
4. Ввести валидные номер карты (4111 1111 1111 1111) и срок действия.
5. Ввести CVV код (любой).
6. Нажать "Оплатить".
**Ожидаемый результат:** Переход на экран успешной оплаты.
**Фактический результат:** Приложение аварийно завершает работу (crash to home screen).
**Частота:** 10/10 раз.
**Дополнительно:** Логи crash прикреплены. Проблема не воспроизводится при оплате через Apple Pay.

Заключение

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

• Разработчикам фокусироваться на самых важных задачах.
• Менеджерам принимать обоснованные решения о сроках выпуска.
• QA-команде эффективно управлять процессом верификации исправлений и регрессионного тестирования. Именно системный подход к оценке делает процесс управления дефектами предсказуемым и способствует непрерывному повышению качества продукта.