Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

.
Регламент по работе с дефектами на проекте
13.11.2014 12:12

Пример регламента по работе с дефектами на проекте для статьи Alien bugs или пришельцы из мира дефектов, Павел Новик, ЗАО «Технологии качества», бренд A1QA

I. Описание полей, принципы заполнения

Заводя дефект, заполняется следующие 8 полей:

  • Приоритет;
  • Тема;
  • Описание;
  • Компоненты;
  • Проявляется в версиях;
  • Окружение;
  • Исправить в версиях;
  • Вложение;

II. Подробнее про заполнение каждого из них:

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

  • Блокирующий – тестирование значительной части функциональности вообще недоступно.
  • Критический – не работает важная часть одной какой-либо функции либо не работает значительная часть, но имеется workaround, позволяющий продолжить тестирование.
  • Важный – не работает важная часть одной какой-либо функции, но при выполнении специфических условий, либо есть workaround, позволяющий продолжить ее тестирование либо не работает не очень значительная часть какой-либо функции. Также относится к дефектам с высокими visibility – обычно не сильно влияющие на функциональность дефекты дизайна, которые, однако, сразу бросаются в глаза.
  • Желательный – часто ошибки GUI, которые не влияют на функциональность, но портят юзабилити или внешний вид. Также незначительные функциональные дефекты, либо которые воспроизводятся на определённом устройстве.
  • Незначительный – почти всегда дефекты на GUI -опечатки в тексте, несоответствие шрифта и оттенка и т.п.

Тема – краткое (в пределах 20 слов) описание ошибки, состоит из трех частей: < где найден дефект>: <короткое описание самой ошибки и места проявления><влияние (импакт) на пользователя>

  • <где найден дефект> – обычно описание функциональной части где найден дефект.
  • <короткое описание самой ошибки и места проявления> – отвечает на вопрос "В чем заключается дефект?" - из этой части должно быть четко понятно, что случилось – возникла ошибка, отсутствует кнопка, произошло "зависание" или что-то еще. Кроме того, должно быть указано, где именно встретили ошибку – какая-то форма, поле и т.п.
  • <влияние (импакт) на пользователя> – отвечает на вопрос "На что влияет дефект?" - особенно важно для дефектов с высоким приоритетом.

Описание – самое большое поле, предназначенное для подробного описания проблемы. Состоит из следующих частей:

  • Пользователь – указывается пользователь под которым воспроизводится дефект (опционально, в случае если данный факт не важен, можно не указывать)
  • Шаги воспроизведения – подробное и последовательное описание на русском языке кратчайшего пути для воспроизведения дефекта. Для удобства восприятия шаги нумеруются: 1...2...3... В описании шагов важно найти тонкую грань между избыточностью (описание каждого движения мышкой) и недостаточностью (пропуск важных для воспроизведения шагов или отсутствие описания, где находится то окошко, в котором воспроизвелась ошибка).
  • Результат – описание фактического поведения со всеми необходимым деталями.
  • Ожидаемый результат – описание ожидаемого поведения, обычно вытекает из функциональных требований или является общепринятым и очевидным поведением.

Компоненты – указывается модуль, для которого актуален дефект. Список доступных значений: Модуль регистрации; Модуль поиска; Модуль настроек, Общее;

Проявляется в версиях – указывается версия билда, в котором был найден дефект.

Окружение – указывается устройство и версия iOS (опционально несколько), на которых воспроизводится дефект.

Исправить в версиях – указывается версия билда, в котором должен быть исправлен дефект.

Вложение – логи, скриншоты или видео при необходимости, которые помогут понять путь воспроизведения дефекта и в чём его суть. Необходимо прикладывать для всех заводимых дефектов (для всех функциональных дефектов обязательно необходимо прикладывать логи).

III. Общие правила заведения дефектов:

Перед тем, как регистрировать ошибку в баг-трекер, необходимо провести как минимум три основных действия:

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

IV. Описание типичного жизненного цикла дефектов.

Возможные состояния и резолюции описаны в Jira, a также дополнительно приведены на скриншоте ниже.

V. Пример описания дефекта несоответствующего регламенту.

{необходимо привести описание реального дефекта с вашего проекта}

VI. Пример описания дефекта соответствующего регламенту.

{необходимо привести описание реального дефекта с вашего проекта}