Может ли быть в баг репорте приоритет без серьёзности?

Может ли быть в баг репорте приоритет без серьёзности?

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

Различие между приоритетом и серьёзностью

• Серьёзность (Severity) — это объективная мера влияния дефекта на работу системы и пользователя. Она оценивается с точки зрения функциональности, безопасности, стабильности. Часто определяется тестировщиком.

    *   **Примеры уровней:** Critical, Major, Minor, Trivial.
    *   **Пример:** Критическая серьёзность (Critical) — падение приложения при запуске, потеря данных.

• Приоритет (Priority) — это субъективное указание на очередность исправления дефекта. Он определяется бизнес-логикой, сроками релиза, важностью фичи для заказчика. Часто устанавливается менеджером или владельцем продукта.

    *   **Примеры уровней:** High, Medium, Low.
    *   **Пример:** Высокий приоритет (High) — опечатка в логотипе компании на главной странице (серьёзность — Minor/Trivial).

Сценарии, когда приоритет есть, а явной серьёзности может не быть

1. Нефункциональные или бизнес-требования

Дефект может не нарушать явную функциональность (серьёзность низкая), но быть критичным с точки зрения сроков или политики.

• Пример: Найден пропущенный знак копирайта © 2024 в футере сайта за день до официального релиза. Для системы это тривиально (Trivial), но для юридического отдела и релиза приоритет будет самым высоким (High), чтобы избежать рисков.

2. "Косметические" баги в высоковидимых местах

Проблемы с UI/UX, которые не ломают функциональность.

• Пример: Незначительное смещение кнопки на главном экране продукта. Серьёзность — Minor, но т.к. это "лицо" продукта, приоритет на исправление может быть повышен до Medium.

3. Зависимости от других задач

Дефект может быть частью более крупной пользовательской истории или блока функциональности, который находится в активной разработке.

• Пример: В новом модуле есть неработающая кнопка "Расширенный фильтр" (серьёзность — Major). Однако весь модуль запланирован к реализации только в следующем квартале. Поэтому приоритет на исправление конкретно этого бага может быть выставлен как Low, пока не будет готов сам модуль. Здесь приоритет существует, но он низкий, не смотря на серьёзность.

**Упрощённая таблица для наглядности:**

| Серьёзность (Что сломалось?) | Приоритет (Когда чинить?) | Пример |
| :--- | :--- | :--- |
| **Critical** (Система падает) | **High** (Срочно, блокирует работу) | Крах сервера при оплате |
| **Major** (Функция не работает) | **Medium** (До следующего релиза) | Не отправляется email-уведомление |
| **Minor** (Проблема в работе) | **High** (Бизнес-требование) | Опечатка в названии компании |
| **Trivial** (Косметический дефект) | **Low** (По остаточному принципу) | Неидеальное выравнивание в rarely used admin panel |

Почему формально это возможно, но не всегда хорошо

В большинстве трекеров (Jira, YouTrack, Azure DevOps) эти поля независимы и могут выставляться отдельно. Технически ничто не мешает оставить поле Severity пустым или со значением Undefined, пока выставив Priority. Однако это плохая практика.

• Потеря контекста: Серьёзность даёт техническому специалисту (разработчику) понимание масштаба проблемы "в коде".
• Сложность анализа: Статистика и отчёты по качеству продукта (например, тренд критичных багов) теряют смысл.
• Риск недопонимания: Может возникнуть путаница в команде.

Рекомендация: Всегда стараться заполнять оба поля. Даже для тривиального бага следует указать минимальный уровень серьёзности (например, Minor или Trivial), а приоритетом уже регулировать очередь на исправление. Если серьёзность неочевидна, можно использовать значение Normal или Medium по умолчанию, но не оставлять поле пустым.

Вывод: Ситуация, когда в баг-репорте важен приоритет, а серьёзность является низкой или неочевидной — это обычное явление, отражающее баланс между техническими и бизнес-аспектами разработки. Ключ — в чётком понимании и разделении этих понятий всеми членами команды.