Какие знаешь приоритеты багов?

Приоритеты багов в тестировании ПО

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

Стандартные уровни приоритета

На практике чаще всего используется четырехуровневая система, хотя названия могут незначительно варьироваться в разных компаниях.

1. P1: Критический / Высокий (Critical/High)

    *   **Описание:** Баг должен быть исправлен немедленно. Его наличие блокирует дальнейшую разработку, тестирование или выпуск продукта.
    *   **Примеры:**
        *   Падение (crash) основного приложения при запуске.
        *   Блокирующий дефект, который не позволяет протестировать другие важные функции.
        *   "Show-stopper" баг, обнаруженный за день до релиза.
        *   Ошибка в процессе сборки (build), препятствующая развертыванию.
    *   **Действия:** Исправление — первоочередная задача для разработчика. Все остальные работы могут быть приостановлены.

1. P2: Высокий / Средний (High/Medium)

    *   **Описание:** Баг важно исправить в ближайшее время, но он не блокирует работу полностью. Часто связан с серьезными функциональными проблемами в основном сценарии использования.
    *   **Примеры:**
        *   Не работает ключевая бизнес-функция (например, "Оплата заказа" в интернет-магазине).
        *   Существенная ошибка в логике, приводящая к неверным расчетам.
        *   Проблема, затрагивающая большую часть пользователей.
    *   **Действия:** Исправление планируется в текущем спринте или итерации разработки.

1. P3: Средний / Низкий (Medium/Low)

    *   **Описание:** Баг следует устранить, но он не является срочным. Обычно это проблемы, не мешающие основному функционалу.
    *   **Примеры:**
        *   Незначительные косметические дефекты UI (например, небольшое смещение элемента).
        *   Опечатка в тексте не на главном экране.
        *   Сбои в работе второстепенной функции, имеющие простой workaround (обходной путь).
    *   **Действия:** Исправление откладывается на следующие спринты или релизы, выполняется по остаточному принципу.

1. P4: Очень низкий / Отложенный (Very Low/Deferred)

    *   **Описание:** Баг может быть исправлен, когда появится свободное время. Часто это улучшения или "баги-ниндзи", которые заметит только QA-инженер.
    *   **Примеры:**
        *   Неидеальное выравнивание текста в скрытом меню.
        *   Консольная ошибка (error в логах), не влияющая видимо на поведение приложения.
        *   Предложение по улучшению, оформленное как дефект.
    *   **Действия:** Баг может оставаться в бэклоге неопределенно долго или быть закрыт с пометкой "Won't Fix" (не будет исправлен).

Взаимосвязь приоритета и серьезности (Severity)

Эти два атрибута часто путают. Их комбинация дает полную картину:

• Высокая серьезность + Высокий приоритет: Критическая ошибка в основном функционале, требующая немедленного исправления (например, потеря данных пользователя).
• Высокая серьезность + Низкий приоритет: Серьезная проблема в части системы, которая редко используется, или для которой есть готовый патч. Её исправление можно запланировать.
• Низкая серьезность + Высокий приоритет: Незначительный дефект на главной странице, который, однако, портит впечатление ключевым клиентам или нарушает корпоративные стандарты. Может быть исправлен быстро для "галочки".
• Низкая серьезность + Низкий приоритет: Типичный косметический баг, не влияющий на работу.

Критерии для определения приоритета

Назначение приоритета — это неформальный процесс, учитывающий множество факторов:

• Влияние на бизнес: Прямые финансовые потери, репутационные риски, несоответствие регуляторным требованиям.
• Частота возникновения: Баг, проявляющийся у 80% пользователей, получит более высокий приоритет, чем возникающий у 1%.
• Блокирующий характер: Мешает ли дефект работе команды (разработки, тестирования).
• Стадия проекта: На этапе активной разработки приоритеты гибче. В стадии стабилизации перед релизом — критические баги исправляются в первую очередь, а малозначительные откладываются.
• Наличие обходного пути (Workaround): Если пользователь может легко обойти проблему, приоритет часто снижается.

Пример в контексте

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

• Серьезность: Критическая (Critical). Приоритет: P1. Кнопка "Скачать" не работает вообще, файл не генерируется. Функция полностью недоступна.
• Серьезность: Значительная (Major). Приоритет: P2. Отчет создается, но скачивается в нечитаемом формате (.tmp). Функция работает частично.
• Серьезность: Незначительная (Minor). Приоритет: P3. Отчет скачивается корректно, но в имени файла есть опечатка ("repot.pdf" вместо "report.pdf").

Заключение

Правильное назначение приоритетов багов — это критически важный навык для QA-инженера, особенно в автоматизации, где мы часто работаем с большими объемами дефектов из автотестов. Это позволяет команде эффективно управлять ресурсами, фокусироваться на главном и обеспечивать своевременный выпуск качественного продукта. Четкая система расстановки приоритетов минимизирует хаос в процессе разработки и способствует продуктивной коммуникации между тестировщиками, разработчиками и менеджерами.