Что такое критерии severity и priority для багов и как они используются?

Что проверяют

Умеете ли вы отделять техническое влияние дефекта от решения, когда его чинить. Это ежедневная работа тестировщика: severity вы проставляете сами и защищаете фактами, priority назначает тот, кто отвечает за продукт и сроки.

Как отвечать

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

Главная мысль ответа в том, что оси независимы, и интереснее всего углы матрицы.

Низкая severity и высокий priority: опечатка в названии продукта на главной, неверная цена в витрине, битая ссылка в рассылке. Система жива, но бизнесу больно прямо сейчас.

Высокая severity и низкий priority: падение в редкой конфигурации, в браузере с исчезающе малой долей или в сценарии, который включают раз в год. Чинить надо, но не ценой релиза.

Полезно добавить, как это живёт в трекере: severity обосновывается шагами и наблюдаемым результатом, priority обсуждается с аналитиком и владельцем продукта, а сами шкалы описаны в тестовой стратегии, иначе слово «критично» каждый понимает по-своему.

Где спотыкаются

Ставят обе оси одинаково и превращают их в одно поле. Если severity всегда равна priority, матрица не нужна, а вместе с ней пропадает разговор про бизнес-влияние.

Завышают severity, чтобы задачу взяли в работу. Шкала обесценивается быстро: когда половина багов блокирующие, на поле перестают смотреть и чинят по знакомству с автором.

Спорят про приоритет как про свою зону ответственности. Тестировщик приносит факты: сколько пользователей задето, есть ли обход, что случится при отказе. Решение о сроке принимает продукт, и это нормальное разделение ролей.