Важно стандартизировать ошибки (баги/дефекты), чтобы все стейкхолдеры могли видеть процессы с одной точки зрения. В этой статье я расскажу о практике использования и важности Severity и Priority. Но сначала уточним эти два понятия.
Приоритет
Понятие приоритета определяет порядок устранения бага в нашем QA-департаменте, как и в любом другом. В SDLC-цикле мы учитываем многие моменты, но именно приоритет бага определяет срочность, с которой баг должен быть устранен. Приоритет устанавливается на основе требований заказчика.
Список приоритетов:
- Trivial (Тривиальный): дефект не влияет на функциональность или данные. Он не влияет на производительность или эффективность. Это просто неудобство в чём-то.
- Low (Низкий): дефект является раздражающим фактором, его необходимо устранить, но устранение можно отложить до устранения более серьезных.
- Medium (Средний): Этот тип дефектов не приводит к полному отказу системы или полной остановке рабочих процессов. Однако даже незначительные ошибки могут вызывать значительное раздражение, разочарование пользователей, или могут снижать эффективность и производительность приложения.
- High (Высокий): Такого типа дефекты могут иметь много общих критериев с «критикалами» или дефектами типа блокер/show-stopper, которые нужно устранять в самую первую очередь. Однако они не классифицируются настолько серьезно, поскольку не приводят к полной остановке рабочего процесса или приложения. Кроме того, дефекты с высоким приоритетом обычно можно «обойти» при помощи временных «заплаток».
- Critical (Критикал, Критический): дефект влияет на основную функциональность приложения, и без его устранения приложение не может быть передано.
Severity
Severity (серьезность) является более широкой метрикой. Severity дефекта дает представление, насколько сильно система затронута данным дефектом.
Серьезность как бы частично дополняет приоритет.
Серьезность (в данной компании) может быть:
- Critical (Критическая): дефект, приводящий к прекращению работы всей системы, или нескольких ее важнейших компонентов, и/или вызывающий значительное повреждение данных. Функция с дефектом критической серьезности — непригодна для использования, и если нет приемлемого альтернативного метода достижения требуемых результатов — тогда степень серьезности будет указана как критическая.
- Major(Существенный/Значительный): Дефект, приводящий к прекращению работы всей системы или одного (нескольких) ее компонентов, и вызывающий значительное повреждение данных. Отказавшая функция непригодна для использования, но если существует приемлемый альтернативный метод достижения требуемых результатов, тогда степень серьезности будет указана как серьезная.
- Moderate (Средний/Умеренный): Дефект, который не приводит к прекращению работы, но приводит к тому, что система выдает неправильные, неполные или противоречивые результаты — тогда степень серьезности будет указана как Moderate.
- Minor (Незначительный): Дефект, который не приводит к прекращению работы, не нарушает удобство использования системы, и желаемые результаты могут быть легко получены путем «обхода» дефектов, тогда серьезность указывается как Minor.
- Cosmetic (Косметический): Дефект, связанный с усовершенствованием системы, при котором изменения касаются лишь внешнего вида и ощущений от приложения — тогда степень серьезности указывается как Cosmetic.
Матрица
Теперь рассмотрим матрицу сопоставления серьезности и приоритета.
Приоритет отображает порядок устранения разрешения бага, а серьезность — ее влияние на систему.
В данном контексте для одного и того же дефекта может быть более одной возможной комбинации.
В таблице данные представлены в наглядном виде. Дефекты распределяются по 5 основным группам. Однако при рассмотрении крайних точек вероятности может быть 4-уровневая таблица.
Примеры
High Severity — High Priority — Level 1:
Большинство дефектов в этой области связано с нарушением критически важных путей и возникновением ошибок. Благодаря такой большой серьезности эта область является первой в очереди.
Например, одним из наиболее важных этапов на сайте магазина являются способы оплаты. Любая ошибка, которая может возникнуть в платежных системах в этом процессе, классифицируется на этом уровне.
High Severity — Low Priority — Level 2:
Приоритет уровня дефектов в этой области важен, но в части серьезности порядок устранения таков, что дефекты должны быть исправлены немедленно; хотя на систему эта ошибка влияет не сильно.
Например, невозможность попасть на страницу комментариев к товару — можно отнести к этой области. В этом процессе произошел сбой в свойствах системы; однако, поскольку этот сбой не относится к основному потоку, его целесообразно классифицировать на этом уровне.
Low Severity — High Priority — Level 3:
Это уровень для дефектов, которые практически не влияют на работу системы, но могут нанести определенный вред заказчику или компании.
Например, ошибка в логотипе на сайтах электронной коммерции может быть отнесена к этому уровню. Ошибка, которая при этом нанесет ущерб репутации бренда, классифицируется на этом уровне, так как не будет иметь серьезных последствий на стороне клиента.
Low Severity — Low Priority — Level 4:
Это уровень ошибки, которая практически не оказывает влияния на систему и клиента и, как правило, только портит восприятие удобства работы пользователя (юзабилити).
К этому уровню можно отнести, например, неработающие ссылки на условия использования или перенаправление не туда куда нужно. Поскольку частота возникновения этой проблемы невелика, она классифицируется как самого низкого уровня.
При работе с крайними точками вероятности можно достичь следующих уровней. В нашей компании мы (QA) вместе с Product-группой распределяем дефекты в соответствии с этими уровнями.
Приведем несколько примеров,
Одинаковая серьезность:
В этом примере Приоритет обозначен как Major (Level 1), а Серьезность — на уровне Level 4.
В данном примере Приоритет обозначен как Trivial (Level 1), а серьезность — как Level 4.
Одинаковый приоритет:
В данном примере приоритет обозначен как Minor (Level 2), а серьезность — как Level 5.
Далее приоритет обозначен как Minor (Level 2), а серьезность — как Level 1.
Как видно из приведенных примеров, могут быть разные ситуации, и абсолютно точное соответствие не является необходимым.
Благодаря использованию такой матрицы команды Product и Development могут смотреть на дефекты с одинаковой точки зрения. Это дает дополнительную скорость и стабильность в работе с дефектами. Можно сказать, что, придерживаясь этой концепции матрицы, мы укрепили нашу систему управления дефектами.
При этом мы работаем в соответствии с Agile-процессом и обеспечиваем управление ограниченными ресурсами и временем. Таким образом, в управлении дефектами решения о том, какие дефекты должны быть включены в спринт, определяются с помощью продуманного подхода. Благодаря этому процессу мы всегда поддерживаем наш Agile в порядке и избегаем перегрузок.
Приоритизируя критические дефекты, мы стремимся обеспечить устойчивую структуру для клиентов. Мы стремимся проводить классификацию ошибок более эффективным методом и завершать этот процесс как можно быстрее.
Дополнительным преимуществом этого процесса для нас является то, что он позволяет работать с максимальной производительностью. Благодаря такой эффективности мы планируем предотвращать возникновение дефектов.
Подводя итог, можно сказать, что мы на собственном опыте убедились в том, что такой подход работает.
