Название компании с ошибкой на главной странице и сбой в редко используемой функции экспорта: что исправить в первую очередь? Подобные аргументы объясняют, почему команды тестирования разделяют критичность и приоритет. Один описывает технический ущерб, а другой описывает срочность бизнеса.

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

Короткий ответ

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

Приоритетные ответы: как скоро нам следует это исправить? Это зависит от затронутых клиентов, сроков, доходов, юридической ответственности и репутации бренда.

Подумайте о больнице. Тяжесть – это то, насколько серьезно состояние пациента. Приоритетом является порядок лечения пациентов, который также зависит от других факторов, например, от того, кто может безопасно ждать и какие ресурсы свободны.

Серьезность и приоритет рядом

Уровни серьезности

Большинство команд используют около четырех или пяти уровней. Вот общий масштаб:

Уровни приоритета

Запишите, что означает каждый уровень для вашей команды, в идеале указав целевое время ответа для каждого. «P1 означает, что кто-то начнет в течение часа» гораздо полезнее, чем «P1 означает очень важно».

Четыре комбинации с примерами

Самый ясный способ понять это — рассмотреть каждую комбинацию:

Высокая серьезность, высокий приоритет

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

Высокая серьезность, низкий приоритет

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

Низкая серьезность, высокий приоритет

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

Низкая серьезность, низкий приоритет

Небольшая опечатка в редко посещаемой справочной статье. Исправьте, когда будет удобно. Если в вашем журнале таких задач полно, рассмотрите возможность объединения их в одну задачу очистки.

Одна ошибка, два разных приоритета

Один и тот же дефект может заслуживать разных приоритетов в зависимости от контекста. Предположим, письмо с подтверждением заказа пришло с неправильным логотипом.

Серьезность не изменилась, поскольку влияние на систему такое же. Но деловая ситуация сделала свое дело. Время тоже может изменить ситуацию. Ошибка, которая сегодня имеет статус P3, может стать P1 за неделю до запуска крупного клиента.

Кто определяет серьезность и приоритет?

• Тестировщики обычно предлагают степень серьезности, поскольку они видели поведение и понимают его влияние на систему.
• Владельцы или менеджеры продукта обычно определяют приоритеты, взвешивая клиентов, доходы и план действий.
• Разработчики добавляют информацию о причине, риске исправления и сроках его устранения.
• Команды поддержки предоставляют доказательства того, сколько клиентов пострадало и насколько сильно.

Источники и команды различаются по этим обязанностям, и в небольшом стартапе все это может делать один человек. Важно то, что все знают, кто принимает окончательное решение, поэтому разногласия заканчиваются принятием решения.

Как оценить ошибку

Если вы не уверены, проработайте эти вопросы.

По серьезности:

1. Потеряет или повредит ли он данные или раскроет личную информацию?
2. Мешает ли это работе основной функции?
3. Есть ли обходной путь и может ли его найти обычный пользователь?
4. Какая часть функции затронута?

В приоритете:

1. Сколько пользователей пострадало и какие?
2. Стоит ли это денег или создает юридический риск или риск несоблюдения требований?
3. Будет ли релиз, демо-версия или распродажа?
4. Насколько это заметно и может ли это повредить вашей репутации?
5. Блокирует ли это другую работу, например тестирование?

Запуск сортировки ошибок

Сортировка — это регулярное собрание, на котором команда рассматривает новые ошибки и решает, что делать дальше. Простой формат работает хорошо:

1. Подготовьтесь. Тестировщик следит за тем, чтобы каждая новая ошибка имела четкие этапы, доказательства и предполагаемую серьезность.
2. Подтвердите. Убедитесь, что его можно воспроизвести и он не является дубликатом.
3. Принятие решения. Согласуйте степень серьезности, установите приоритет и назначьте владельца.
4. Замкните цикл. Отклоните, отложите или запланируйте каждую ошибку и запишите причину.

Делайте это коротко и часто. В последние дни перед освобождением обычно проводится ежедневная 15-минутная сортировка. Серьезность и приоритет также влияют на ваше решение о выпуске, поэтому заранее согласуйте правила, такие как «не допускать открытых ошибок S1 или S2 при выпуске», как часть ваших критериев выхода.

Серьезность и приоритет в отчете об ошибке

Короткая и понятная запись поможет каждому принять правильное решение:

Title:    Checkout returns error 500 when a coupon is applied
Severity: S1 - blocks purchase, no workaround
Priority: P1 proposed - sale starts Friday
Build:    2.14.0, production
Reach:    All customers using a coupon (around 30% of orders)
Steps:    1. Add an item  2. Apply SAVE10  3. Click Pay
Result:   Error 500 and no order is created
Expected: Order is created with the discount applied

Эти цифры являются примерами. В реальном отчете используйте измеренные значения из журналов и объясните свои рассуждения. Узнайте больше в нашем руководстве о том, как написать отчет об ошибке. Это также поможет узнать, что означают коды ошибок, поэтому держите под рукой нашу шпаргалку по кодам состояния HTTP.

Распространенные ошибки

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

Итоги

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

Часто задаваемые вопросы

Продолжайте учиться