Как правильно выбрать 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 секунд

Декомпозиция в тестировании и при анализе приложения

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

Декомпозиция, как процесс расчленения, позволяет рассматривать любую исследуемую систему как сложную, состоящую из отдельных взаимосвязанных подсистем, которые, в свою очередь, также могут быть расчленены на части. Continue reading

Планирование и оценка трудозатрат на тестирование

С очень хорошим и сильным докладом на конференции SQA Days-15 выступила Александа Ковалева – “Планирование трудозатрат на тестирование”. Саша, как и на прошлых свои выступлениях,  была воодушевляюща, мила, открыта, профессиональна! Восторгаюсь ей. Всё очень по делу.

Как и ранее, я транслирую конспект доклада, совмещенный с моим пониманием этой темы и моими дополнениям.

Планирование тестирования – это целый комплекс работ, состоит из следующих этапов:

  1. Определение требований к тестам
  2. Оценка продуктовых и проектных рисков
  3. Разработка плана тестирования:
    1. Разработка стратегии тестирования
    2. Определение ресурсов
    3. Проработка конкретных задач по тестированию
  4. Оценка трудозатрат на каждую из работ
  5. Создание графика работ с распределением ресурсов
  6. Мониторинг и сравнение результатов работы и на соответствие плану и графику. Перепланирование по необходимости.

Continue reading

SQA Days 15. Обзор докладов про тестировщиков-автоматизаторов

Давно отошла от автоматизации, поэтому обзор докладов по этой теме у меня маленький и не технический, а связанный с людьми:

  • Про обучение автоматизации людей, совершенно незнакомых с программированием, – Вадим Зубович “SikuliScript как идеальный инструмент для обучения автоматизации”
  • Про то, каким автоматизатором не нужно быть, – Игорь Мирошниченко ” Антипаттерны поведения и развития тестировщиков – автоматизаторов”.

Continue reading

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

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

Continue reading

SQA Days 15. Обзор докладов из секции функционального тестирования

Во втором обзоре докладов SQA Days-15 рассмотрены следующие:

  •  Дмитрий Химион “Тестирование игровой механики в компьютерных играх”
  •  Наталья Голодюк “Quality Assurance в условиях тотального A/B тестирования”
  •  Сергей Остапенков «Обеспечение качества: практические советы»

Continue reading

SQA Days 15. Обзор докладов по тестированию мобильных приложений, кроссплатформенному и кроссбраузерному тестированию

Лично мне SQA Days #15 очень понравилась: профессиональная атмосфера, полезное содержание докладов, отличная фан-зона (особенно громкая виртуальная реальность, заставляющая дрожать коленки)!

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

  • Наташа Брич “Непереносимая переносимость кроссплатформенных приложений на примере десктоп приложений”
  • Юлия Горлова “Лайхаки ручного тестирования на мобилках”
  • Таисия Рыбак “Как оптимизировать тестирование мобильных приложений”
  • Алёна Пономаренко “Ошибки при проверке внутренних платежей Android-iOS и их решение”
  • Максим Белявский “Подготовка апдейта мобильного приложения “Одноклассники”
  • Дмитрий Штепура “Кроссбраузерное тестирование с популяризацией HTML5 и CSS3. Internet Explorer, не такой как все”

Continue reading