Severity и priority багов с примерами
Один из вопросов на собеседованиях звучит так:
«Приведи пример бага с высоким severity и низким priority или с низким severity и высоким priority».
На первый взгляд вопрос кажется простым, но как показала практика, многие на нём сильно буксуют. Чтобы корректно на него ответить, важно различать два определения Severity и Priority.
Severity - степень ущерба системе (показывает, насколько сильно дефект нарушает работу приложения или его отдельных компонентов).
Priority - срочность исправления дефекта (определяет, когда баг должен быть взят в работу относительно других задач).
Severity - степень ущерба системе (показывает, насколько сильно дефект нарушает работу приложения или его отдельных компонентов).
Priority - срочность исправления дефекта (определяет, когда баг должен быть взят в работу относительно других задач).
Пример 1. Высокий severity + низкий priority
Ситуация:
При вводе адреса доставки из определённого района система не позволяет оформить заказ.
Контекст:
Severity: высокий (основной сценарий - оформление заказа - блокируется)
Priority: низкий или средний
Ситуация:
При вводе адреса доставки из определённого района система не позволяет оформить заказ.
Контекст:
- проблема возникает только для одного небольшого региона;
- доля таких заказов - менее 0.5%;
- есть возможность выбрать ближайший соседний район.
Severity: высокий (основной сценарий - оформление заказа - блокируется)
Priority: низкий или средний
Баг блокирует важный пользовательский сценарий, поэтому его серьёзность высокая. Но затрагивает очень небольшую часть пользователей, поэтому исправление может быть отложено.
Пример 2. Низкий severity + высокий priority
Ситуация:
В мобильном приложении в разделе «Пользовательское соглашение» отображается старая версия документа.
Контекст:
Severity: низкий (функциональность приложения не нарушена)
Priority: высокий
Ситуация:
В мобильном приложении в разделе «Пользовательское соглашение» отображается старая версия документа.
Контекст:
- на проде должна быть опубликована новая версия соглашения;
- изменение связано с юридическими требованиями.
Severity: низкий (функциональность приложения не нарушена)
Priority: высокий
Баг практически не влияет на работу приложения и пользовательский опыт. Однако для бизнеса он критичен, потому что может нарушать юридические требования или регуляторные нормы.
Пример 3. Высокий severity + высокий priority
Ситуация:
При оплате заказа у части пользователей происходит двойное списание средств.
Контекст:
Severity: высокий (прямая финансовая ошибка, некорректная работа бизнес-логики)
Priority: высокий
Ситуация:
При оплате заказа у части пользователей происходит двойное списание средств.
Контекст:
- это основной сценарий оплаты на проде;
- деньги списываются дважды;
- затрагивает всех пользователей независимо от версии ОС.
Severity: высокий (прямая финансовая ошибка, некорректная работа бизнес-логики)
Priority: высокий
Баг критичный и создаёт прямые финансовые потери и репутационные риски, поэтому его нужно исправлять немедленно.
Пример 4. Низкий severity + низкий priority
Ситуация:
На экране настроек аватар пользователя отображается с небольшим смещением вправо.
Контекст:
Severity: низкий (косметический UI-дефект, логика не нарушена)
Priority: низкий
Ситуация:
На экране настроек аватар пользователя отображается с небольшим смещением вправо.
Контекст:
- экран используется редко (данные из аналитики);
- функциональность полностью работает.
Severity: низкий (косметический UI-дефект, логика не нарушена)
Priority: низкий
Баг не влияет на функциональность и не создаёт бизнес-рисков, поэтому его можно исправить в рамках плановых правок или редизайна.