Home

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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