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

 

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

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 секунд

Исследование багов: учимся у Шерлока Холмса!

В сегодняшнем обзоре я затрону только один доклад — доклад Инны Смирновой на тему «Исследование багов: учимся у Шерлока Холмса!»
Инна подняла отличную и наболевшую тему для многих тестировщиков и их руководителей. У меня давно уже крутилась в мыслях похожая идея. Всё думала как к ней подступиться, а тут прелестный доклад Инны.

Continue reading