Как определить приоритет дефекта

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

Замечу сразу, приведенная процедура не является универсальной для практического применения.

На что влияет приоритет бага

Приоритет — это один из ключевых атрибутов бага, который в первую очередь влияет на:

1) Качественный показатель продукта в целом и/или его компонентов. Оперируя нижеприведенными свойствами, возможен сбор необходимых метрик, которые определяют показатели качества продукта на текущей стадии его жизненного цикла:
— количество багов соответствующих приоритетов;
— показатели комплексности/сложности функционала;
— статистика распределения багов по функциональным модулям;
— временные характеристики процесса тестирования (например, для формализации Zero Bug Bounce, Code Freeze etc);
— прочие аналогичные данные.

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

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

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

5) Готовность к проведению приемо-сдаточных работ, демонстраций, сдачи проекта в производственную эксплуатацию.

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

Глобальный приоритет (Global Severity)

Глобальный приоритет (Global Severity) бага определяется 3-мя составляющими:

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

— Приоритет (Priority)- свойство тестового артефакта, влияющее на очередность выполнения задачи или устранения дефекта. Является характеристикой, определяемой с точки зрения бизнеса.

— Частота (Frequency) — свойство тестового артефакта, характеризующее частоту (%) возникновения при использовании приложения конечными пользователями. Является характеристикой, определяемой с точки зрения пользовательских сценариев использования продукта.

Таким образом, глобальный приоритет определяется на основании значений трёх свойств:
globalSeverity = F(Priority, Severity, Frequency).

Далее рассмотрим более подробно данную зависимость и уточним ее.

Принцип определения составляющих свойств

1) Серьезность (Severity)

Определяется QA специалистом, Lead QA или Team Lead после анализа требований, программного продукта и специфики конкретной проблемы:

Blocker — дефект относится к критичной (с точки зрения работоспособности) функциональности или критичным данным. У пользователя нет возможности выполнить целевое действие другими способами.

Примеры:
— Нет возможности залогиниться, зарегистрироваться;
— Нет возможности получить доступ как целевым данным, целевым разделам приложения;
— Происходит краш приложения на конкретном окружении.

Critical — дефект относится к важной (с точки зрения работоспособности) функциональности или важным данным. Пользователь может выполнить целевое действие обходным путем, но он (путь) не очевиден.

Примеры:
— Падения (crash) приложения;
— Исключения (exeptions) в процессе работы с приложением;
— Не работоспособность функционала на одном из доступных пользователю окружениях;
— Несанкционированный доступ к данным/функциональности.

Major — дефект относится к не приоритетной (с точки зрения работоспособности) функциональности или не приоритетным данным. Есть очевидный и простой обходной путь выполнения целевой функциональности.

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

Trivial — дефект не относится напрямую к функциональности и данным. Нет необходимости в обходных путях для выполнения целевого действия. Не влияет на продуктивность, скорость использования приложения.

Пример:
— Небольшие расхождения верстки с макетами;
— Орфографические ошибки в не приоритетном контенте;
— Несущественые улучшения UI, UX.

В данной методике рассматривается 4-уровневая модель Severity. В зависимости от специфики вашего проекта или процессов, могут быть использованы альтернативные модели. Например, данную модель Severity можно расширить такими уровнями градации, как average (normal) и minor.

2) Приоритет (Priority)

Определяется менеджером (PM/PO) проекта на основании влияния проблемы на бизнес задачи/цели программного продукта:

— Высокий (High): дефект должен быть исправлен как можно скорее, так как он влияет на наиболее критичный с точки зрения бизнеса функционал.

— Средний (Medium): дефект должен быть обязательно исправлен, так как он влияет на важный с точки зрения бизнеса функционал. Однако исправление может быть отложено до ближайших этапов/спринтов разработки.

— Низкий (Low): дефект не обязателен к исправлению, так как он не влияет на важный с точки зрения бизнеса функционал и ее исправление может быть отложено до момента появления ресурсов.

3) Частота (Frequency)

Определяется специалистом по маркетингу или заказчиком проекта на основании анализа поведенческих паттернов конечных пользователей:

— Высокая (High): более 80% конечных пользователей сталкиваются с проблемой.

— Средняя (Medium): менее 80%, но более 30% конечных пользователей сталкиваются с проблемой.

— Низкая (Low): менее 30%, но более 10% конечных пользователей сталкиваются с проблемой.

— Незначительная (Very low): менее 10% конечных пользователей сталкиваются с проблемой.

Алгоритм определения глобального приоритета

Частота (Frequency) проблемы прямым образом влияет на приоритет. Приоритет (Priority) и серьезность (Severity) прямым образом влияют на глобальный приоритет (Global Severity) дефекта: globalSeverity = F(Priority, Severity), где Priority = F(BasePriority, Frequency). Глобальный приоритет (globalSeverity) определяем по следующему алгоритму:

1. Первоначально изолировано от других факторов определяем серьезность дефекта (Blocker, Critical, Minor, Trivial).

2. Независимо от серьезности, определяем приоритет дефекта (High, Medium, Low).

3. Независимо от серьезности и приоритета, определяем частоту дефекта (High, Medium, Low, Very low).

4. Далее рассчитываем влияние частоты на первоначально определенный приоритет:

5. Наконец, рассчитываем глобальный приоритет:

— Critical — обязательно к исправлению. Сдача проекта не возможна с наличием данных дефектов.
— Minor — допустимо в небольшом количестве. Сдача проекта не желательна с наличием данных дефектов, однако возможна с некоторым их наличием.
— Trivial — сдача проекта возможна с наличием данных дефектов.

Процедура определения приемо-сдаточных критериев

Традиционно, в разных методологиях управления проектами существуют понятия Acceptance Criteria и Done Criteria — как для продукта в целом, так и для его отдельных релизов. Работа с баг-репортом как документом, несущим основную информацию о качественных характеристиках программного продукта, именно на конечном этапе итерации (sprint, milestone и т.п) несет особое значение:
— Acceptance Criteria являются основой для написания тестовых сценариев (чеклистов, тест-кейсов, end-to-end сценариев etc);
— Done Criterias активно использует баг-репорты для формирования оценки, характеризующей степень соответствия продукта ранее заявленным требованиям.

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

Основная цель данной модели — показать, что приоритизация багов зависит от достаточно большого количества факторов. И, к примеру, подход в ранжировании потенциальных и существующих проблем в SaaS проекте продуктового формата в области e-commerce должен отличаться от подхода в аутсорсинг-проекте по расширению или поддержке существующего бизнеса клиента. Так, для первого проекта будут существенно больший вес иметь факторы маркетинг-составляющей в приоритизации проблем, нежели для второго проекта.

Статья написана в соавторстве с Юлией Колесник.