Приведите примеры серьезного, но не приоритетного бага.qa-29

Критерии серьезности vs приоритета

Прежде чем приводить примеры, важно понять разницу:

Серьезность (Severity) - влияние бага на систему
Приоритет (Priority) - срочность его исправления

Пример 1: Утечка памяти в rarely used feature

Описание: В модуле "Архив отчетов" после 5 часов работы возникает утечка 2MB/час.
  • Почему серьезный:
    • Может привести к падению системы при длительной работе
    • Нарушает стандарты качества ПО
  • Почему низкий приоритет:
    • Функция используется 1 раз в месяц
    • Можно устранить перезапуском приложения

Пример 2: Несовместимость с экзотическим браузером

Описание: Веб-приложение не работает в Netsurf 3.10 (доля рынка 0.001%).
  • Почему серьезный:
    • Полная нефункциональность для определенных пользователей
    • Нарушение принципа accessibility
  • Почему низкий приоритет:
    • Крайне малая пользовательская база
    • Браузер не входит в supported-лист

Пример 3: Косметический дефект в enterprise-софте

Описание: В темной теме интерфейса текст "#303030" на фоне "#333333".
  • Почему серьезный:
    • Нарушает стандарты доступности (WCAG 2.1 AA)
    • Профессиональный имидж продукта
  • Почему низкий приоритет:
    • Не мешает функциональности
    • Основные пользователи работают в светлой теме

Пример 4: Edge-case в payment-системе

Описание: При сумме 999999.99 + 0.01 расчеты дают 1000000.00 (не 1000000.00).
  • Почему серьезный:
    • Финансовые расчеты должны быть точными
    • Потенциальные юридические последствия
  • Почему низкий приоритет:
    • Вероятность такого перевода ≈ 0
    • Есть workaround (округление вручную)

Как определять приоритет?

Используем матрицу решений:

graph TD
    A[Баг] --> B{Влияет на core business?}
    B -->|Да| C[Высокий приоритет]
    B -->|Нет| D{Частота воспроизведения?}
    D -->|Часто| C
    D -->|Редко| E[Низкий приоритет]

Резюмируем

Серьезные, но не приоритетные баги часто:

  1. Касаются edge-cases
  2. Имеют рабочие обходные пути
  3. Затрагивают малозначимые сценарии использования
  4. Требуют больших усилий для исправления при малой пользе

Главное - обосновать приоритетность, ссылаясь на бизнес-потребности, а не только на техническую сложность!