Severity и priority багов с примерами

Один из вопросов на собеседованиях звучит так:

«Приведи пример бага с высоким severity и низким priority или с низким severity и высоким priority».

На первый взгляд вопрос кажется простым, но как показала практика, многие на нём сильно буксуют. Чтобы корректно на него ответить, важно различать два определения Severity и Priority.

Severity - степень ущерба системе (показывает, насколько сильно дефект нарушает работу приложения или его отдельных компонентов).

Priority - срочность исправления дефекта (определяет, когда баг должен быть взят в работу относительно других задач).

Пример 1. Высокий severity + низкий priority

Ситуация:

При вводе адреса доставки из определённого района система не позволяет оформить заказ.

Контекст:

• проблема возникает только для одного небольшого региона;
• доля таких заказов - менее 0.5%;
• есть возможность выбрать ближайший соседний район.

Severity: высокий (основной сценарий - оформление заказа - блокируется)

Priority: низкий или средний

Баг блокирует важный пользовательский сценарий, поэтому его серьёзность высокая. Но затрагивает очень небольшую часть пользователей, поэтому исправление может быть отложено.

Пример 2. Низкий severity + высокий priority

Ситуация:

В мобильном приложении в разделе «Пользовательское соглашение» отображается старая версия документа.

Контекст:

• на проде должна быть опубликована новая версия соглашения;
• изменение связано с юридическими требованиями.

Severity: низкий (функциональность приложения не нарушена)

Priority: высокий

Баг практически не влияет на работу приложения и пользовательский опыт. Однако для бизнеса он критичен, потому что может нарушать юридические требования или регуляторные нормы.

Пример 3. Высокий severity + высокий priority

Ситуация:

При оплате заказа у части пользователей происходит двойное списание средств.

Контекст:

• это основной сценарий оплаты на проде;
• деньги списываются дважды;
• затрагивает всех пользователей независимо от версии ОС.

Severity: высокий (прямая финансовая ошибка, некорректная работа бизнес-логики)

Priority: высокий

Баг критичный и создаёт прямые финансовые потери и репутационные риски, поэтому его нужно исправлять немедленно.

Пример 4. Низкий severity + низкий priority

Ситуация:

На экране настроек аватар пользователя отображается с небольшим смещением вправо.

Контекст:

• экран используется редко (данные из аналитики);
• функциональность полностью работает.

Severity: низкий (косметический UI-дефект, логика не нарушена)

Priority: низкий

Баг не влияет на функциональность и не создаёт бизнес-рисков, поэтому его можно исправить в рамках плановых правок или редизайна.

Обсудить статью, узнать больше можно в телеграм канале «Тестировщики нужны».