Какой знаешь пример бага с высоким Priority и низким Siverity?

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

В своей практике я часто встречаю баги, где приоритет не совпадает с серьёзностью (severity). Это важный аспект управления дефектами, который непрофессионалы часто путают. Расскажу о примерах из реальной работы.

Понимание разницы: Priority vs Severity

Priority — это насколько срочно нужно исправить баг (бизнес-решение, зависит от цели) Severity — это насколько серьёзно баг влияет на функциональность (техническое влияние)

Пример 1: Опечатка в продакшене на главной странице

Баг: На главной странице в заголовке "The Best Soluttion" вместо "Solution"

• Severity: Low — всего одна буква, функциональность не нарушена, сайт работает нормально
• Priority: High/Critical — это публичная главная страница, видима всем пользователям, портит имидж компании

Это реальный баг, который я встретил в крупном SaaS продукте. Несмотря на низкую серьёзность (опечатка не ломает ничего), приоритет был максимальным, потому что это первое впечатление клиентов.

Пример 2: Неправильный цвет иконки в приложении

Баг: Icon при наведении имеет яркий фиолетовый цвет вместо синего (нарушает брендбук)

• Severity: Low — функциональность полностью работает, пользователь может нажать иконку
• Priority: High — компания придерживается строгого дизайн-гайда, это нарушает визуальный стиль

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

Пример 3: Английский текст в русском интерфейсе

Баг: В русской локализации приложения одна кнопка остались на английском ("Confirm" вместо "Подтвердить")

• Severity: Low — пользователь понимает, что нужно нажать, функция работает
• Priority: High — нарушена консистентность UI, это выглядит как незавершённая работа

Пример 4: Неправильное выравнивание текста на странице

Баг: На странице контактов блок с информацией выровнен не по центру, смещён на 10px вправо

• Severity: Low — информация полностью читаемая и доступная
• Priority: High — это портит эстетику, пользователи могут заметить в рекламных материалах

Пример 5: Неправильная ссылка в подвале на тестовый сервер

Баг: В footer'е ссылка на terms указывает на staging.example.com вместо example.com

• Severity: Medium (или Low) — функциональность работает, пользователь получит нужную информацию
• Priority: Critical — это критично, так как публикуется на всех страницах для всех пользователей

Пример 6: Аватарка пользователя загружается медленно на определённом браузере

Баг: На Firefox аватарка загружается 5 секунд, на Chrome 0.5 секунды (проблема с CSS фильтром)

• Severity: Low — функциональность полностью работает, это просто медленнее
• Priority: Medium-High — Firefox популярен в Европе, если целевая аудитория там, это влияет на UX

Почему это важно для QA

Правильная классификация приоритета и серьёзности критична:

1. Управление ресурсами — разработчики сосредоточатся на действительно критичных багах
2. Планирование релизов — high priority баги могут заблокировать release
3. Коммуникация со стейкхолдерами — нужно объяснить, почему опечатка критична, а критический баг может подождать

Практический пример из моей работы

В последнем проекте я нашел баг: в прайс-листе сумма итога считалась неправильно при определённой комбинации товаров (высокая severity). Но это был только на странице просмотра корзины в черновике, не влиял на финальный расчёт. Приоритет был средний — нужно исправить, но не срочно.

Одновременно я нашёл баг, где цена была выведена красным текстом вместо чёрного в одном из писем. Severity низкая, но это письмо отправляется всем новым клиентам при регистрации. Приоритет — высокий.

Правильное разделение priority и severity — это признак зрелости QA процесса в организации.