Как определяли severity (критичность) бага на проекте?

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

Ответ

Severity (критичность) бага определялась по его влиянию на работоспособность системы и пользовательский опыт. Использовалась стандартная классификация:

  • Critical (Критический): Полный отказ системы, блокирующий дальнейшую работу (например, падение сервера или невозможность запуска приложения).
  • Major (Высокий): Ключевая функциональность не работает (например, пользователь не может завершить оплату заказа).
  • Minor (Средний): Ошибка в неосновной функциональности или незначительное отклонение (например, некорректная валидация в необязательном поле).
  • Trivial (Низкий): Косметические дефекты, не влияющие на функциональность (например, опечатка в тексте или неверный отступ).

Пример оформления в баг-репорте:

Severity: Major
Шаги воспроизведения:
1. Добавить товар в корзину.
2. Перейти в корзину и нажать "Оформить заказ".
Ожидаемый результат: Открывается форма оплаты.
Фактический результат: Возвращается ошибка HTTP 500.

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