Ответ
Да, такое сочетание (High Severity / Low Priority) не только возможно, но и встречается на практике. Эти атрибуты оценивают разные аспекты дефекта.
Определения:
- Severity (Серьезность): Объективная оценка технического воздействия дефекта на систему (насколько сильно он ломает функциональность).
- Priority (Приоритет): Субъективная оценка бизнес-важности его исправления (насколько срочно нужно чинить).
Классический пример:
Дефект: "Система полностью падает (возвращает 500 ошибку) при попытке входа через устаревший метод аутентификации, который используется менее 0.1% клиентов".
- Severity: Blocker/Critical. Функциональность полностью недоступна для этого сценария.
- Priority: Low. Сценарий используется крайне редко, не влияет на основную массу пользователей и выручку. Ресурсы команды направлены на более важные задачи.
Еще один пример — дефект в deprecated API:
# v2/api/users — основной, работает.
# v1/api/users — устаревший, планируется к удалению.
# Баг: v1/api/users падает с ошибкой 500 при определенном запросе.
# Severity: High (полный отказ endpoint).
# Priority: Low (endpoint deprecated, клиенты мигрировали на v2).Вывод: Приоритет определяется бизнес-контекстом и частотой использования сценария, а серьезность — чисто техническими последствиями. Такой дефект будет зафиксирован, но его исправление отложено в бэклог.