Какие знаешь дефекты с Blocking Severity и с Low Priority?

Дефекты с блокирующей серьезностью (Blocking Severity) и низким приоритетом (Low Priority)

В управлении дефектами Severity (Серьезность) и Priority (Приоритет) — это две независимые, но часто взаимосвязанные характеристики. Severity объективно описывает влияние дефекта на функциональность системы, тогда как Priority субъективно определяет очередность его исправления с точки зрения бизнеса или проекта.

1. Дефекты с Blocking Severity и Low Priority

Это дефекты, которые полностью блокируют выполнение определенной функциональности или тестирования (Severity: Blocker), но при этом бизнес или продукт-менеджмент не считает их срочными для исправления (Priority: Low). Такие ситуации возникают редко, но являются классическим примером расхождения между технической и бизнес-оценкой.

Характерные примеры:

• Блокировка устаревшей или "замороженной" функциональности: Дефект полностью ломает возможность отправки отчетов в старом формате (например, .doc), в то время как вся команда и клиенты уже год используют новый формат (.pdf). Технически доступ к функции невозможен (Blocker), но так как ею никто не пользуется, приоритет исправления низкий.

    *   **Сценарий:** "При попытке экспорта отчета в формате .doc приложение аварийно завершается (Crash). Экспорт в .pdf и .xlsx работает корректно. Согласно документации и PO, поддержка .doc объявлена устаревшей и будет удалена в следующем мажорном релизе."

• Блокировка некритичного для бизнеса сценария в определенном окружении: Фундаментальная ошибка (например, падение сервиса) возникает только при очень специфической и редко используемой конфигурации, не характерной для продакшена или большинства пользователей.

    *   **Сценарий:** "Веб-приложение перестает отвечать (блокируется) при попытке авторизации через LDAP, если имя пользователя содержит кириллические символы и его длина превышает 50 символов. Все клиенты используют латиницу, а политика компании ограничивает длину логина 20 символами."

• Блокирующий дефект в feature, отложенном на будущие версии: Найден критический баг в новом модуле "AI-аналитик", который делает модуль непригодным для использования. Однако решение о внедрении этого модуля было перенесено на неопределенный срок по стратегическим соображениям.

    *   **Сценарий:** "Новый модуль 'Прогнозирование нагрузок' при запуске вызывает утечку памяти, приводящую к остановке основного сервиса через 2 минуты работы. Решение о внедрении модуля отложено до конца года, текущий релиз фокусируется на стабильности ядра."

2. Критерии оценки и действия QA-инженера

При обнаружении и заведении такого дефекта QA-инженер должен четко обосновать обе оценки.

В отчете о дефекте должно быть ясно указано:

1. Severity: Blocker — Обоснование: "Дефект делает функцию X полностью недоступной, тестирование невозможно. Падение приложения/сервиса."
2. Priority: Low — Обоснование: "Функция X не используется в текущем цикле разработки / не задействована ключевыми клиентами / является устаревшей. Работа над исправлением может быть отложена без влияния на текущие релизные цели."

Пример структуры отчета:

Заголовок: [Blocker][Low] Crash приложения при попытке открыть раздел "Устаревшие архивы"
Шаги воспроизведения:
1. Авторизоваться под любой учетной записью.
2. В главном меню навести курсор на пункт "Архив".
3. В выпадающем списке выбрать "Устаревшие архивы (до 2020 года)".
Фактический результат: Мгновенное падение (Crash) клиентского приложения.
Ожидаемый результат: Открытие окна с информацией о том, что доступ к архивам отключен, или корректное отображение раздела.
Серьезность (Severity): Blocker. Полная потеря работоспособности приложения.
Приоритет (Priority): Low. Раздел "Устаревшие архивы" был отключен для пользователей 3 года назад согласно публичному changelog. В текущем интерфейсе пункт меню должен быть скрыт, его наличие является отдельной баг-фичей.
Окружение: Prod-like Stand, версия клиента 5.2.

3. Работа команды с такими дефектами

• Триаж (Triage): На регулярных встречах по триажу дефектов команда (QA, разработчики, продукт-овнер) подтверждает обе оценки. Важно, чтобы Low Priority не означал "забудем навсегда". Часто такие дефекты либо исправляются "по остаточному принципу", либо принимается решение об их целенаправленном удалении (например, полное отключение устаревшего функционала).
• Риски: Игнорирование Blocking-дефектов, даже с Low Priority, несет риски:

    *   **Технический долг:** Баг может мешать рефакторингу кода или миграции на новые технологии.
    *   **Запутывание новых членов команды:** Разработчик или тестировщик может случайно наткнуться на него и потратить время.
    *   **Всплытие в будущем:** При изменении бизнес-требований устаревшая функция может неожиданно понадобиться, и блокирующая проблема встанет на критическом пути.

Таким образом, дефекты с Blocking Severity и Low Priority — это не парадокс, а отражение реалий разработки, где техническая критичность не всегда совпадает с бизнес-срочностью. Грамотное документирование и коммуникация по таким дефектам — признак зрелости QA-процесса.