Какие знаешь виды Priority?

Виды Priority в тестировании

В контексте тестирования программного обеспечения (QA) термин Priority обычно относится к приоритету дефекта (Bug Priority) – это показатель, который определяет порядок и срочность исправления найденной ошибки. Он устанавливается совместно QA-инженером и разработчиками (часто через систему управления проектами, например, Jira) и служит для планирования работы команды. Priority часто комбинируется с другим параметром – Severity (Критичность). Severity описывает влияние дефекта на пользователя и систему, а Priority – на команду разработки и план работ.

Основные виды/уровни Priority, которые я использую и часто встречаются в практике:

1. Immediate / Critical / Blocker

Это наивысший приоритет. Дефект блокирует дальнейшую работу – тестирование или разработку основных функций. Его исправление требуется немедленно, часто "вне очереди".

• Примеры: Ошибка, которая полностью блокирует вход в систему; дефект, приводящий к постоянному краху основного модуля приложения.

2. High

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

• Примеры: Не работает основной поток оплаты в приложении; данные не сохраняются в ключевой форме.

3. Medium / Normal

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

• Примеры: Неверное сообщение об ошибке в неключевом разделе; некритичная проблема с отображением UI (например, небольшое смещение элементов).

4. Low / Minor

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

• Примеры: Оптимизация (не ошибка), например, предложение изменить цвет кнопки для лучшего соответствия гайдлайнам; незначительная опечатка в вспомогательном тексте.

5. Trivial / Very Low

Это самый низкий уровень. Дефекты часто остаются в системе долгое время или даже не исправляются, если они не представляют никакого риска.

• Примеры: Минимальное несоответствие дизайну в элементе, который редко используется; косметическая проблема, заметная только при очень специфических условиях.

Важно отметить, что классификация может варьироваться в разных компаниях. Иногда используется более простой подход: High, Medium, Low. Ключевой принцип – приоритет должен отражать бизнес-важность и техническую срочность исправления.

Как определяется Priority?

Приоритет дефекта оценивается по нескольким критериям, часто в комбинации с Severity:

• Влияние на бизнес-процессы: Ошибка в модуле отчетности для CFO будет иметь высокий приоритет.
• Влияние на релиз: Дефект, нарушающий承诺 (commitment) по релизу, получит высокий Priority.
• Количество пользователей, затрагиваемых ошибкой: Баг в публичной части сайта vs. баг в админ-панели для нескольких менеджеров.
• Наличие обходных путей (workaround): Если пользователь может выполнить действие другим способом, Priority может быть снижен.
• Сложность и риск исправления: Иногда низкий Priority может быть повышен, если исправление простое и безопасное.

Пример записи дефекта с Priority в Jira

{
  "Issue Key": "PROJ-123",
  "Summary": "Поле 'Email' не валидируется на корректность формата при регистрации",
  "Severity": "High (возможна регистрация с нерабочим email, потеря пользователей)",
  "Priority": "Medium (функция регистрации критична, но есть другие поля для контакта)",
  "Steps to Reproduce": [
    "1. Открыть страницу регистрации /signup",
    "2. В поле 'Email' ввести 'invalidemail'",
    "3. Нажать 'Зарегистрироваться'"
  ],
  "Expected Result": "Система показывает ошибку 'Введите корректный email адрес'",
  "Actual Result": "Система принимает форму и создает пользователя"
}

Заключение

Правильное определение Priority – это критически важный навык для QA Engineer. Он помогает управлять ресурсами команды разработки, фокусироваться на наиболее важных проблемах и обеспечивать стабильный прогресс проекта. Работа с приоритетами требует не только технического понимания дефекта, но и осознания бизнес-контекста продукта. Часто приоритеты обсуждаются и пересматриваются на регулярных встречах по планированию (planning meetings) или triage-сессиях.