Кто должен выставлять критичность

Кто должен выставлять критичность дефектов?

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

Основные участники процесса и их роль

1. Тестировщик (QA Engineer)

Чаще всего первоначальная критичность назначается именно тестировщиком, который обнаружил дефект. Это логично, поскольку он:

• Наиболее глубоко понимает контекст обнаруженной проблемы в момент ее выявления.
• Видит непосредственное влияние на пользовательский опыт или функциональность.
• Может оценить степень отклонения от требований (спецификации).

Тестировщик оценивает дефект по заранее установленной классификации (например, Blocker, Critical, Major, Minor, Trivial). Его оценка основывается на объективных критериях:

• Влияние на бизнес-процессы: блокирует ключевые операции или нет.
• Распространение проблемы: затрагивает один модуль или всю систему.
• Возможность обхода: существует временное решение для пользователя.
• Степень нарушения функциональности: полная потеря функции или незначительное отклонение.

// Пример: Тестировщик описывает дефект и назначает критичность в отчете
BugReport {
    title: "Приложение крашится при попытке сохранения данных без интернет-соединения",
    severity: CRITICAL, // Выставлено тестировщиком
    stepsToReproduce: "1. Отключить Wi-Fi. 2. Нажать 'Сохранить'...",
    expectedResult: "Данные сохраняются в локальную память с ожиданием синхронизации",
    actualResult: "Приложение закрывается с ошибкой 'NetworkError'"
}

2. Руководитель тестирования (QA Lead/Manager)

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

• Унификации оценок внутри команды, чтобы избежать субъективности.
• Балансировки нагрузки на команду разработки, так как поток дефектов с высокой критичностью может парализовать работу.
• Согласования оценки с бизнес-приоритетами проекта.

3. Разработчик (Developer)

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

• Оценивает техническую сложность и время на исправление.
• Видит потенциальные риски и побочные эффекты при внесении изменений в код.
• Может указать, что проблема уже известна или является частью более крупной технической задачи.

4. Владелец продукта / Менеджер проекта (Product Owner / Project Manager)

Это ключевая роль для финального определения приоритета (priority), который часто путают с критичностью. Критичность — техническая оценка влияния, приоритет — бизнес-оценка важности исправления в данный момент. PO/PM должен:

• Согласовывать или переопределять финальный приоритет дефекта, исходя из стратегии релиза, дорожной карты и потребностей пользователей.
• Учитывать, что даже дефект с высокой критичностью (например, краш в нишевой функции) может получить низкий приоритет, если его исправление не важно для текущих бизнес-целей.

Рекомендуемая модель процесса

Наиболее эффективной считается коллаборативная модель с четким протоколом:

1. Тестировщик выставляет первоначальную критичность по формальным критериям.
2. QA Lead ревьювит и стандартизирует оценки внутри потока дефектов.
3. На регулярных митингах (например, triage meetings) команда в составе: тестировщики, разработчики, менеджеры проекта — совместно обсуждают и финально согласовывают критичность и приоритет для ключевых или спорных дефектов. Это позволяет объединить техническую и бизнес-перспективы.
4. Владелец продукта утверждает приоритет для дефектов, влияющих на план релиза.

Почему нельзя назначать критичность одному человеку?

• Субъективность: один участник может недооценить или переоценить влияние из-за ограниченного контекста.
• Несоответствие бизнес-целям: технически серьезный баг может быть неактуальным для рынка.
• Конфликт интересов: разработчик может неосознанно снижать критичность сложных для исправления дефектов.

Итог: Критичность должна выставляться тестировщиком на основе объективных критериев, но обязательно подвергаться ревью и возможной корректировки командой (QA Lead, разработчики) и окончательно синхронизироваться с бизнес-приоритетами владельцем продукта. Этот подход обеспечивает баланс между технической реальностью и бизнес-стратегией, что является фундаментом эффективного процесса управления дефектами.