Ответ
На проекте использовалась классическая модель оценки дефектов по Severity (влияние на систему) и Priority (важность для бизнеса). Окончательное решение по severity принимал QA-инженер, а по priority — Продуктовый менеджер / Владелец продукта, после чего оно согласовывалось с командой разработки.
Критерии оценки Severity:
| Уровень | Описание | Пример |
|---|---|---|
| S1: Блокирующий (Blocker) | Полная неработоспособность ключевой функции, падение системы, потеря данных. Нет обходного пути. | «Приложение крашится при запуске для 100% пользователей на iOS 17». |
| S2: Критический (Critical) | Ключевая функция не работает, но есть обходной путь. Серьезная ошибка логики, влияющая на бизнес. | «Кнопка "Оплатить" неактивна после выбора способа доставки. Покупку можно завершить только через корзину». |
| S3: Значительный (Major) | Функция работает с ограничениями или ошибками, не критичными для основного сценария. | «В отчете за прошлый месяц не отображаются транзакции, созданные 31-го числа». |
| S4: Незначительный (Minor) | Косметическая проблема, опечатка, неверное сообщение об ошибке. Не влияет на функциональность. | «Не выровнена кнопка "Отмена" в модальном окне». |
Процесс на практике:
- QA выставляет предварительную severity на основе таблицы выше.
- На ежедневном стендапе или в баг-трекинге (Jira) severity обсуждается с разработчиком (оценивается сложность исправления) и менеджером (оценивается влияние на пользователей).
- Менеджер выставляет final priority (P0-P2), который определяет очередь на исправление.
Важно: Severity — объективный технический параметр, Priority — субъективный бизнес-параметр. Баг может иметь высокую severity, но низкий priority, если проблема возникает в редко используемом функционале.