Как на вашем проекте определяли критичность и приоритет дефекта?

«Как на вашем проекте определяли критичность и приоритет дефекта?» — вопрос из категории Управление тестированием, который задают на 10% собеседований QA Тестировщик. Ниже — развёрнутый ответ с разбором ключевых моментов.

Ответ

Определение критичности (Severity) и приоритета (Priority) дефекта — это совместный процесс, в котором участвуют QA, разработчики и менеджер продукта (Product Owner/Manager).

Разделение понятий:

  • Критичность (Severity) — объективная оценка влияния бага на работу системы (от QA/Dev).
  • Приоритет (Priority) — субъективное решение о порядке исправления, основанное на бизнес-логике и сроках (от PO/PM).

Типичный workflow:

  1. QA-инженер обнаруживает дефект и выставляет первоначальную оценку Severity, основываясь на его влиянии.
  2. Разработчик оценивает сложность и риски исправления, может скорректировать оценку.
  3. Менеджер продукта определяет Priority, исходя из бизнес-ценности, сроков релиза и ожиданий пользователей.
  4. Финальное решение по приоритету и срокам фикса часто принимается на ежедневном стендапе или планировании спринта.
Пример: Дефект Severity (QA) Влияние (Dev) Priority (PO) Итог
Падение сервера при оплате Блокирующий (S1) Критично, влияет на всех пользователей Высокий (P1) Исправить немедленно, внепланово
Неверная иконка в меню Незначительный (S4) Косметическая проблема Низкий (P4) Исправить в одном из будущих спринтов
Функция поиска не работает в Firefox Критичный (S2) Влияет на часть пользователей, фикс займет 3 дня Высокий (P2) Включить в следующий спринт

Такой подход обеспечивает баланс между технической необходимостью и бизнес-требованиями.