Какой знаешь баг с низким Priority и высокой Siverity?

Приоритет (Priority) и Серьёзность (Severity): классический парадокс

В практике тестирования (QA) классический пример бага с низким Priority (приоритетом) и высокой Severity (серьёзностью) — это критический дефект, который проявляется в очень редких или специфических условиях, не влияющих на основную функциональность продукта или не блокирующих бизнес-цели.

Конкретный пример: "Серверный сбой при обработке экзотического часового пояса"

Описание бага: Приложение для управления финансами корректно работает для 99% пользователей. Однако, если пользователь выставляет свой часовой пояс как "Antarctica/McMurdo" (стандартная зона IANA) и пытается создать отчёт за период, включающий переход на летнее время (DST) для этой зоны, серверное приложение падает с 500 Internal Server Error (фатальная ошибка). Все данные сохраняются, но операция прерывается, и пользователь видит экран критической ошибки.

Почему высокая Severity (серьезность = Critical/Blocker)?

• Влияние на систему: Полный отказ сервиса (краш) для конкретного пользователя.
• Потеря данных: Операция не завершена, хотя данные сохранены. Пользователь может предпринять повторные действия, что приведёт к дублированию.
• Восприятие пользователя: Получает экран критической ошибки, что подрывает доверие к надёжности продукта.
• Тип дефекта: Crash/Bug уровня сервера, а не просто косметическая проблема.

Почему низкий Priority (приоритет = Low)?

• Частота воспроизведения: Дефект затрагивает ничтожно малую часть пользовательской базы — возможно, одного-двух человек в Антарктиде, использующих именно этот софт.
• Бизнес-влияние: Не блокирует основные денежные потоки, не влияет на релиз ключевых функций. Работа для подавляющего большинства клиентов (в распространённых часовых поясах) не нарушена.
• Обходной путь (Workaround): Пользователь может временно переключиться на другой часовой пояс (например, UTC+12) для генерации отчёта без потери ключевой функциональности.
• Срочность: Для исправления требуются глубокие изменения в парсинге дат на сервере. Разработчики сосредоточены на более насущных задачах — исправлении дефектов, влияющих на массового пользователя, или разработке новой функциональности.

Разбор кейса и стратегия работы с таким багом

-- Пример: Логирование такого инцидента в баг-трекинговой системе (Jira, Youtrack и т.д.)
-- Summary: [Critical] Server crash (500 Error) when generating a report with timezone "Antarctica/McMurdo" during DST transition.
-- Severity: Critical
-- Priority: Low
-- Steps to Reproduce:
-- 1. Set user profile timezone to "Antarctica/McMurdo".
-- 2. Navigate to Reports section.
-- 3. Set date range from 2023-09-23 to 2023-09-25 (includes DST shift on 2023-09-24).
-- 4. Click "Generate Report".
-- Expected Result: Report is generated successfully.
-- Actual Result: White screen with "500 Internal Server Error". Server logs show unhandled DateTime exception.
-- Workaround: Temporarily switch timezone to "UTC+12".

Что делает QA-инженер, найдя такой баг?

1. Документирует максимально полно: Фиксирует точные шаги, логи, скриншоты, окружение. Чем реже баг, тем детальнее должна быть инструкция по его воспроизведению.
2. Обосновывает Severity: Чётко объясняет в описании, почему дефект критический (краш, потеря данных).
3. Аргументирует предлагаемый Priority: Проводит анализ:

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

1. Эскалирует на обсуждение: Выносит баг на триаж-встречу (c участием PM, тимлида, разработчиков) для коллективного принятия решения о судьбе дефекта. Решение может быть:

    *   **Исправить, но отложить:** Запланировать на далёкий спринт или версию.
    *   **Принять риски (Won't Fix):** Осознанно оставить, если стоимость исправления несоизмерима с риском.
    *   **Частичное исправление:** Например, добавить валидацию на фронтенде, запрещающую выбор экзотических зон, или глобальный try-catch на сервере с падением в "безопасный" часовой пояс UTC.

Вывод

Такой парадоксальный баг наглядно демонстрирует ключевое различие между Severity (объективная техническая тяжесть дефекта для системы) и Priority (субъективная важность его исправления для бизнеса и команды в текущий момент времени). Умение правильно классифицировать и аргументировать оба этих атрибута — важный навык senior QA-инженера, напрямую влияющий на эффективность процессов разработки и распределения ресурсов в команде. Он показывает, что даже самая критическая поломка может быть отложена, если её влияние на бизнес минимально, а риски исправления — высоки.