Приведи пример бага с низкой серьезностью и высокой приоритетностью

Пример бага с низкой серьезностью и высокой приоритетностью

В практике тестирования серьезность (Severity) и приоритет (Priority) — это независимые, но часто взаимосвязанные характеристики бага. Серьезность отражает степень влияния дефекта на работоспособность продукта (например, от критического сбоя до косметической ошибки). Приоритет определяет очередность исправления дефекта, исходя из бизнес-логики, требований заказчика или маркетинговых соображений.

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

Конкретный сценарий

Продукт: Мобильное приложение крупного банка для розничных клиентов.
Функция: Главный экран приложения после входа пользователя.
Баг: В разделе с акционным предложением на главном экране допущена орфографическая ошибка в слове "инвестиции" (написано "инвистиции"). При этом все функции приложения (переводы, платежи, просмотр баланса) работают корректно.

Почему серьезность низкая?

• Функциональное воздействие: Основные функции банковского приложения не нарушены. Пользователи могут без проблем совершать все финансовые операции.
• Работоспособность: Приложение не падает, данные не теряются, безопасность не нарушена.
• Область влияния: Ошибка локализована в текстовом контенте, а не в коде бизнес-логики. Это косметический дефект (Cosmetic Bug).
• С технической точки зрения: Серверная часть, API, алгоритмы расчетов работают без сбоев.

Почему приоритет высокий?

Здесь вступают в силу бизнес- и репутационные факторы, которые заставляют поднять приоритет исправления до максимального:

1. Вредит бренду и имиджу. Для банка, особенно крупного и международного, образ надежности, профессионализма и внимания к деталям — ключевой актив. Грамотность — базовая составляющая этого образа. Ошибка в самом заметном месте подрывает доверие.
2. Нарушает законодательство (риск для бизнеса). В некоторых юрисдикциях ошибки в рекламных материалах, особенно финансовых продуктов, могут привести к штрафам со стороны регуляторов (например, если ошибка искажает суть предложения).
3. Влияет на конверсию. Акционное предложение на главном экране — это мощный маркетинговый инструмент для привлечения клиентов. Опечатка снижает доверие к предложению и может отпугнуть потенциальных инвесторов, напрямую влияя на бизнес-показатели.
4. Проблема на самом видном месте. Главный экран — это "лицо" приложения, которое видят 100% пользователей при каждом входе. Дефект в таком месте гораздо заметнее, чем, например, опечатка в разделе "Справка" на третьем уровне вложенности.
5. Быстрое и дешевое исправление. Как правило, исправить текстовый контент (строку в файле локализации или в CMS) можно за минуты силами одного разработчика или контент-менеджера. Низкая стоимость и скорость исправления при высоких бизнес-рисках делают приоритет очевидно высоким.

Как это может выглядеть в баг-трекинговой системе (Jira)

**Заголовок:** [Главный экран] Орфографическая ошибка в слове "инвестиции" в блоке акционного предложения.
**Описание:**
1.  Открыть мобильное приложение Банка Х и авторизоваться.
2.  Обратить внимание на центральный баннер с текстом "Выгодные инвистиции".
**Ожидаемый результат:** Текст соответствует норме: "Выгодные инвестиции".
**Фактический результат:** В слове "инвестиции" допущена ошибка: "инвистиции".
**Шаги воспроизведения:** Всегда воспроизводится.
**Окружение:** iOS 17.4, Android 14, любая версия приложения.
**Серьезность:** Low (Trivial) / S4. Функционал не нарушен.
**Приоритет:** High (P1). Критично для бренда и маркетинга. Требуется исправление до следующего релиза.
**Вложения:** Скриншот главного экрана.

Итог

Этот пример наглядно показывает, что приоритет диктуется бизнес-контекстом, а не только технической тяжестью дефекта. Задача QA-инженера — не только находить сбои в логике, но и понимать продукт с точки зрения пользователя и бизнеса, чтобы правильно расставлять акценты при репортинге. Такой баг, несмотря на свою простоту, должен быть исправлен в первую очередь, даже если в тот же день найден более сложный, но менее заметный функциональный дефект в глубине системы.