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

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 можно пользоваться таблицей ниже.

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

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

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

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