Как выставляешь Priority баг репорта

Принципы выставления Priority в баг-репортах

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

Ключевые факторы, влияющие на Priority

Я всегда оцениваю приоритет на основе комбинации следующих критериев:

1. Бизнес-логика и критичность функционала:

    *   Баг в основном сценарии оплаты или оформления заказа всегда получает высший приоритет (P0/P1), так как его наличие блокирует выручку.
    *   Дефект в нишевой или редко используемой функции может получить низкий приоритет (P3/P4).

1. Частота воспроизведения и количество затронутых пользователей:

    *   Баг, который воспроизводится у 100% пользователей на ключевой странице, — это **P0/P1**.
    *   Проблема, возникающая у 0.1% пользователей при специфических настройках, часто получает **P3**.

1. Влияние на другие процессы и команды:

    *   Дефект, который блокирует работу тестировщиков или разработчиков (например, падает среда), требует немедленного внимания (**P0**).
    *   Баг, мешающий работе смежных команд (например, отделу аналитики), получает повышенный приоритет.

1. Внешние факторы и сроки:

    *   Приближение релиза или демонстрации заказчику резко повышает приоритет для всех багов, влияющих на ключевые демо-сценарии.
    *   Наличие публичного баг-трекера, где пользователи видят статус дефектов, также влияет на приоритизацию.

Типовая градация приоритетов

В моей практике я чаще всего использую 4-уровневую шкалу:

• P0 (Blocker / Критический): Дефект необходимо исправить немедленно. Работа над ним начинается в тот же день. Примеры: полная недоступность сервиса, критическая утечка данных, падение основного функционала для всех пользователей.
• P1 (High / Высокий): Дефект должен быть исправлен в текущем спринте или итерации. Серьезно влияет на основные функции, но есть обходной путь.

# Пример: P1. Кнопка "Оплатить" в корзине неактивна после применения промокода.
# Основной сценарий покупки нарушен, но пользователь может оформить заказ без промокода.

• P2 (Medium / Средний): Дефект планируется к исправлению в одном из следующих спринтов. Влияет на второстепенные функции или является косметической проблемой в важном месте.

# Пример: P2. Неверное склонение города в сообщении об успешном заказе.
# Логика не нарушена, но портит впечатление от ключевого события.

• P3 (Low / Низкий): Дефект может быть исправлен, когда появится свободное время (tech debt, refactoring). Часто это мелкие UI-проблемы, опечатки в текстах, не влияющие на понимание.

Процесс и коммуникация

Выставление Priority — это не единоличное решение QA. Это результат обсуждения и согласования.

1. Первоначальная оценка: Как QA, я выставляю предполагаемый приоритет (и severity) на основе чек-листа выше, сразу при создании баг-репорта. Это помогает команде быстро сориентироваться.
2. Триада (QA + DEV + PM): Окончательный приоритет утверждается на планировании спринта или на ежедневном стендапе. Разработчик оценивает сложность исправления, а продакт-менеджер — бизнес-ценность.
3. Динамическая переоценка: Приоритеты не высечены в камне. Они могут меняться:

    *   **Повышаться:** если баг начал проявляться чаще или был обнаружен в связанном, более важном модуле.
    *   **Понижаться:** если найден более критичный дефект или изменились бизнес-требования.

Пример комплексной оценки в баг-репорте

Заголовок: При повторном добавлении одного и того же товара в корзину из "Избранного" итоговая сумма рассчитывается неверно.

• Severity: Major (функциональность работает, но выдает некорректный результат).
• Priority (первоначальная оценка QA): P2.
• Обоснование: Функция "Избранное" — важна, но не основная. Дефект затрагивает расчет суммы — критичную часть. Однако есть обходной путь: удалить товар и добавить заново. Процент пользователей, использующих это действие, невысок.
• Итоговый Priority (после обсуждения с PM): P1. Продакт-менеджер уточнил, что на следующей неделе запускается email-рассылка с прямыми ссылками на добавление из "Избранного", и дефект может затронуть большую аудиторию. Бизнес-риск возрастает.

Итог: Правильно выставленный Priority — это баланс между техническим влиянием бага, бизнес-требованиями и ресурсами команды. Это не просто ярлык, а инструмент управления потоком работ, который требует четких критериев, постоянной коммуникации и готовности к пересмотру.