post

Severity (критичность) бага выставляется после анализа двух факторов:

  1. насколько та область (модуль) приложения, в которой найден баг, важна для пользователя или бизнеса компании-разработчика
  2. как проявляется проблема — креш, проблема интерфейса, нарушение логики работы и т.п.

Если баг относится к фичам “для бизнеса”, “для менеджмента” или “для продуктивной работы всей команды разработки”, то при выборе критичности бага стоит подумать о том, не теряет ли статус компания, не теряется ли рейтинг приложения, не уменьшатся ли доходы компании, какими будут потери команды (временные, материальные, психологические) в случае, если баг останется в приложении не исправленным.

  • Blocker - это баги, ведущие к бизнес потерям: риск непрохождения ревью в appstore; критически большое уменьшение количества скачиваний приложения; уменьшение доходов, понижение рейтинга приложения в appstore; расхождение реализованного и планов маркетологов (например, неверная иконка приложения). Примеры багов: нет попапа на ревью, не отображаются smart news (новостные и рекламные попапы), неверная иконка приложения и т.п.
  • Critical и Medium - нарушения в логике работы бизнес-фич. Например, smart news отображаются, но первый раз появляются на 3й вызов приложения, а не на 2й.  Разницу между критичностями уровня critical и medium необходимо определять интуитивно.
  • Minor и Trivial. То, что относится к удобству работы команды и к бизнес-фичам, но не мешает их работе никаким образом. Например, в коде приложения стоит неверная ссылка на файл smart news, или опечатка в названии папки с библиотеками, которая видна только через iFunbox и пользователю должна быть безразлична, или ключ для  локализации в string файле написан с грамматической ошибкой. Разницу между критичностями уровня minor и trivial необходимо определять интуитивно.

Если же баг относится к фичам “для пользователей”, то для выставления severity необходимо ответить на вопрос о том, сколько пользователей заметят проблему. “Заметят” — это ситуация, когда пользователь не просто открывает экран с какой-то неточностью, а видит её и для себя воспринимает как проблему.

Для выбора severity можно пользоваться таблицей ниже.

 

Баг в “пользовательской фиче”: сколько пользователей столкнутся с проблемой либо обратят на неё внимание?

bug severity

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

Для каждого проекта и каждой операции необходимо продумывать свои критерии. Ниже таблица представлена как пример.

 

Cколько времени выполняется некая операция на iPhone 4 в зависимости от количества файлов?

Кол-во объектов Blocker Critical Medium
до 5 > 1 сек около 1 секунды 0,5-1 секунда
5 — 15 > 2 сек около 2 секунд 1-2 секунд
16 — 50 > 3 сек около 3 секунд 2-3 секунд
> 50 > 5 сек около 5 секунд 3-5 секунд

2 thoughts on “Как правильно выбрать severity для бага?

  1. для некоторых приложений вам придётся разделить пользователей на тех кто платит и тех кто использует и для них разные фичи и разные уровне работоспособности будут важны, а ещё фичи на те за которые платят и те которыми дополнительно пользуются…

    в конечном итоге нужно быть проще и пусть жизнь (бизнес) решает что фиксить в каком порядке.

    • для некоторых приложений вам придётся разделить пользователей на тех кто платит и тех кто использует

      Да. Я про то же и писала. Это и есть фичи «для бизнеса», где важно думать получаем мы деньги или не получаем, теряем или не теряем.

      И безусловно — приоритет и критичность разные вещи. Что фиксить, а что нет решает приоритет.

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Можно использовать следующие HTML-теги и атрибуты: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>