Серьезность и приоритет дефекта: как согласовать оценку на примерах

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

Универсальной шкалы здесь нет. У разных команд различаются продукт, аудитория, допустимые обходные пути и ритм поставки изменений. Поэтому полезнее не искать «правильную» международную таблицу, а договориться о локальных правилах, по которым два человека в вашей команде будут оценивать один и тот же дефект похоже. Ниже — практический способ это сделать и проверить на четырех учебных примерах.

Влияние на пользователя: как ставить серьезность дефекта

Серьезность удобно определять без оглядки на календарь релиза и настроение стейкхолдеров. Это ответ на вопрос: что происходит с пользовательским сценарием, если баг не исправлять прямо сейчас. В triage-подходе обычно сначала фиксируют дефект, потом относят его к категории, оценивают, назначают и отслеживают до закрытия. Для этой оценки особенно важен воспроизводимый отчет: что делал пользователь, что ожидалось, что произошло фактически, есть ли обходной путь.

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

• S1 — основной сценарий недоступен или результат неверен без рабочего обхода.
• S2 — сценарий выполним, но через неудобный обходной путь, с потерей времени или качества результата.
• S3 — сценарий выполняется, но есть заметная помеха, частичная некорректность или путаница.
• S4 — косметический дефект, который не мешает завершить задачу.

Ключевой момент здесь в том, что severity отвечает не на вопрос «что мы берем в работу первым», а на вопрос «насколько сломан опыт пользователя». Если команда записывает это в явных правилах, споров становится меньше. Вместо фразы «мне кажется, это критично» появляется проверка по критериям: сломан ли основной сценарий, есть ли обход, искажается ли результат, сколько шагов требуется для обхода.

Срочность исправления: как ставить приоритет

Приоритет — это уже управленческое решение. Оно зависит не только от силы удара по пользователю, но и от контекста: кого баг задевает, как часто возникает, мешает ли выпуску, создает ли поток обращений, может ли потянуть за собой другие проблемы. В triage-практике приоритизация обычно опирается на severity, влияние и текущие сроки проекта, но это все равно отдельная оценка.

Удобно договориться о своей шкале и здесь. Например:

• P1 — берем в работу немедленно или в ближайший цикл.
• P2 — исправляем следующим заметным блоком задач.
• P3 — планируем, когда появится окно без ущерба для более срочных задач.
• P4 — можно отложить до пакетной правки или ближайшего пересмотра бэклога.

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

Четыре учебных дефекта: как две оценки работают независимо

Учебный пример. Возьмем условный веб-сервис заказов. Команда заранее приняла шкалы S1–S4 и P1–P4 из предыдущих разделов. Два участника, QA и менеджер продукта, независимо оценили четыре дефекта. Ниже — исходные данные и итоговое решение после короткого triage.

Здесь видно главное: дефекты 1 и 3 получили одинаковый приоритет P1, хотя severity у них разная. Для дефекта 1 причина в поломке основной пользовательской покупки. Для дефекта 3 — в срочном операционном контексте. Наоборот, дефект 2 заметен пользователю, но не стал срочным: сценарий сохранен, обход дешевый, дедлайн не поджимает.

Проверяемый результат учебного кейса был таким. При первой независимой оценке QA и менеджер совпали по severity во всех 4 случаях, а по priority — в 3 из 4. Спор возник по дефекту 2: менеджер поставил P2, QA — P3. После обсуждения команда добавила в локальные правила уточнение: если у дефекта есть простой обход и он не мешает релизному сценарию, приоритет не поднимается выше P3 без отдельного подтверждения от поддержки или бизнеса. После этого правило применили повторно, и оценки совпали 4 из 4. Это и есть полезный результат: не «идеальная шкала», а понятные условия, при которых два человека приходят к одному выводу.

Критерии команды: что закрепить письменно

Чтобы договоренность не распадалась после первой же спорной задачи, критерии лучше записать на одной странице и хранить рядом с баг-трекером. В этом документе достаточно пяти блоков: ваша шкала severity, ваша шкала priority, 3–5 примеров на каждую границу, обязательные поля баг-репорта и правило пересмотра оценки на triage.

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

Еще одна полезная практика — разбирать не все баги всей командой, а только спорные и граничные случаи. Регулярный triage нужен не ради длинных встреч, а ради единых решений по тем дефектам, где локальные правила пока неочевидны. После нескольких таких разборов шкала становится точнее, а новые участники быстрее перенимают общий подход.

Как проверить, что ваша шкала действительно работает

Самый простой тест — взять 8–12 свежих дефектов и попросить двух участников оценить их независимо. Затем посчитать, где были расхождения, и посмотреть, что именно вызвало спор: разные представления об обходном пути, разные ожидания от релиза, отсутствие данных в репорте или слишком расплывчатая формулировка уровня S2 и P2. Исправлять нужно не людей, а правила и шаблон описания бага.

Хороший признак рабочей системы — когда после уточнения правил уменьшается число споров одного и того же типа. Плохой — когда каждая встреча начинается заново и одинаковые дефекты получают разные оценки от недели к неделе. Тогда стоит пересмотреть не только шкалу, но и сам triage-процесс: кто участвует, какие данные обязателены, кто имеет право менять priority и в какой момент severity можно пересматривать после новых фактов.

Если вам нужен практический ориентир для обучения, в сохраненном описании каталога курса «Инженер по тестированию» от Училкин есть темы про основы тестирования, тестовую документацию, жизненный цикл бага, приоритетность бага, а также про жизненный цикл ПО и Agile-подходы. Официальная страница курса в исходных данных недоступна, поэтому опираться можно только на это сохраненное описание программы.