Как правильно описать дефект
Ожидает приглашения
В этой статье я напишу пошаговую инструкцию по описанию дефектов. Каждый раздел — отдельный структурный элемент бага. Конечно, на проектах требованию к оформлению могут отличаться, но я озвучу стандартные базовые правила, которые применяются везде.
Этот раздел должен содержать краткое описание проблемы, оно должно быть составлено так, что даже без открывания тикета было понятно в чем суть проблемы.
Когда описываете summary, отвечайте для себя на три вопроса: ЧТО? ГДЕ? и КОГДА?
Практический пример:
Calendar events recurring bug — плохое оглавление.
Recurring calendar events are not deleted if we uncheck ‘Make this event recurring’ on the event Edit page — оглавление созданное с помощью описанной выше методике.
Разберем summary по частям:
Recurring calendar events are not deleted — отвечает на вопрос «Что работает не так?»
if we uncheck ‘Make this event recurring’ — теперь мы понимаем когда воспроизводиться проблема
on the event Edit page — описание места воспроизведения бага. Это может быть название страницы, окна, поля или любого другого веб элемента.
Description расширяет summary, довольно часто возникает ситуация, что оглавление получается слишком громоздким, что не хорошо. Тут к нам на помощь приходит description, где мы можем без ограничений в формализованной форме описать проблему. Также данный раздел может содержать подробности для воспроизведения(окружение на котором воспроизводился дефект, дополнительные условия и т.д). Я описываю важные и уникальные детали, без которых невозможно отловить баг, к примеру:
«NOTE: Account time zone = Atlantic time(Canada)».
P.S Да, для описания Envirmoment есть отдельный раздел, однако часто его не читают или пропускают, я не знаю с чем это связано, поэтому выношу эту информацию дополнительно в раздел «Описание».
Содержит подробные шаги для воспроизведения ишью. Соглашусь, иногда сложно и нудно описывать по 10 шагов для создания определенных данных, а затем еще столько же для описания того, что же нужно с ними сделать, но это крайне важно, чтобы через неделю не ломать голову над тем «Как же это воспроизвести?!».
Также нужно добавлять ссылки на места для воспроизведения проблемы. Ведь, если база данных не пренакатывалась, или вы сделали импорт тестовых данных разработчику не прийдется терять время на их пересоздание. Однако, не ленитесь описывать шаги по созданию тест даты в steps to reproduce, ибо не понятно, когда будет фикситься та или иная проблема, и чтобы Вы не забыли, как создавали тест дату. Именно это может привести к «can`t to reproduce», а Вы и сами уже не вспомните, что да как делали.
Пример описания с шагами по созданию тест даты со ссылкой:
1. Open Calendar page
2. Create a recurring event:
Title: Not recurring event
Description: Calendar testing
Location: Sumy, Ukraine
Make this event recurring: Checked
Start time: 9:00 AM
Finish time: 2:45 PM
4. Set Start date: actual date+1 day
5. Set End date: actual date +3days
6. Recurring schedule: Daily -> Create
[LINK ON THE CREATED ENTITY]
7. Click on the first event -> Uncheck 'Make this event recurring'
8. Save -> Confirm changes
Пример плохого описания:
1. Open Calendar
2. Create a recurring event
3. Click on the first event -> Uncheck 'Make this event recurring'
4. Save -> Confirm changes
Сравните два описания: какой дефект Вы бы смогли воспроизвести?
После шагов для воспроизведения идет сначала ER(expected result), потом AR(actual result).
ER — описание того, как система ДОЛЖНА работать
AR — описание РЕАЛЬНОГО/ТЕКУЩЕГО поведения системы
Пример:
ER: Only one event present on Calendar, previous should be deleted
AR: All events moved to one day
И АР, и ЕР могут содержать видео или скриншоты. Я бы сказал, что это обязательное требование, просто оно не всегда реализуемо.
5. Priority
Для того, чтобы поставить тикету нужный приоритет, ответьте на вопрос «На сколько проблема критична?» Чтобы получить ответ, воспользуйтесь двумя параметрами:
Зачастую в Jira они соединены в единый атрибут «Priority» — что-то смешанное между Severity и Priority, поэтому стоит учитывать и то, и другое.
«Радуйте» своих коллег-разрабочтиков граматно оформленными дефектами!
1. Оформление оглавления (Summary)
Этот раздел должен содержать краткое описание проблемы, оно должно быть составлено так, что даже без открывания тикета было понятно в чем суть проблемы.
Когда описываете summary, отвечайте для себя на три вопроса: ЧТО? ГДЕ? и КОГДА?
Практический пример:
Calendar events recurring bug — плохое оглавление.
Recurring calendar events are not deleted if we uncheck ‘Make this event recurring’ on the event Edit page — оглавление созданное с помощью описанной выше методике.
Разберем summary по частям:
Recurring calendar events are not deleted — отвечает на вопрос «Что работает не так?»
if we uncheck ‘Make this event recurring’ — теперь мы понимаем когда воспроизводиться проблема
on the event Edit page — описание места воспроизведения бага. Это может быть название страницы, окна, поля или любого другого веб элемента.
2. Описание (Description)
Description расширяет summary, довольно часто возникает ситуация, что оглавление получается слишком громоздким, что не хорошо. Тут к нам на помощь приходит description, где мы можем без ограничений в формализованной форме описать проблему. Также данный раздел может содержать подробности для воспроизведения(окружение на котором воспроизводился дефект, дополнительные условия и т.д). Я описываю важные и уникальные детали, без которых невозможно отловить баг, к примеру:
«NOTE: Account time zone = Atlantic time(Canada)».
P.S Да, для описания Envirmoment есть отдельный раздел, однако часто его не читают или пропускают, я не знаю с чем это связано, поэтому выношу эту информацию дополнительно в раздел «Описание».
3. Далее идет раздел Steps to reproduce
Содержит подробные шаги для воспроизведения ишью. Соглашусь, иногда сложно и нудно описывать по 10 шагов для создания определенных данных, а затем еще столько же для описания того, что же нужно с ними сделать, но это крайне важно, чтобы через неделю не ломать голову над тем «Как же это воспроизвести?!».
Также нужно добавлять ссылки на места для воспроизведения проблемы. Ведь, если база данных не пренакатывалась, или вы сделали импорт тестовых данных разработчику не прийдется терять время на их пересоздание. Однако, не ленитесь описывать шаги по созданию тест даты в steps to reproduce, ибо не понятно, когда будет фикситься та или иная проблема, и чтобы Вы не забыли, как создавали тест дату. Именно это может привести к «can`t to reproduce», а Вы и сами уже не вспомните, что да как делали.
Пример описания с шагами по созданию тест даты со ссылкой:
1. Open Calendar page
2. Create a recurring event:
Title: Not recurring event
Description: Calendar testing
Location: Sumy, Ukraine
Make this event recurring: Checked
Start time: 9:00 AM
Finish time: 2:45 PM
4. Set Start date: actual date+1 day
5. Set End date: actual date +3days
6. Recurring schedule: Daily -> Create
[LINK ON THE CREATED ENTITY]
7. Click on the first event -> Uncheck 'Make this event recurring'
8. Save -> Confirm changes
Пример плохого описания:
1. Open Calendar
2. Create a recurring event
3. Click on the first event -> Uncheck 'Make this event recurring'
4. Save -> Confirm changes
Сравните два описания: какой дефект Вы бы смогли воспроизвести?
4. ER/AR
После шагов для воспроизведения идет сначала ER(expected result), потом AR(actual result).
ER — описание того, как система ДОЛЖНА работать
AR — описание РЕАЛЬНОГО/ТЕКУЩЕГО поведения системы
Пример:
ER: Only one event present on Calendar, previous should be deleted
AR: All events moved to one day
И АР, и ЕР могут содержать видео или скриншоты. Я бы сказал, что это обязательное требование, просто оно не всегда реализуемо.
5. Priority
Для того, чтобы поставить тикету нужный приоритет, ответьте на вопрос «На сколько проблема критична?» Чтобы получить ответ, воспользуйтесь двумя параметрами:
- Серьезность (Severity) — это атрибут, характеризующий влияние дефекта на работоспособность приложения. (Какое влияние на бизнес заказчика)
- Приоритет (Priority) — это атрибут, указывающий на очередность выполнения задачи или устранения дефекта. (На сколько сложно и важно устранить проблему для процесса разработки)
Зачастую в Jira они соединены в единый атрибут «Priority» — что-то смешанное между Severity и Priority, поэтому стоит учитывать и то, и другое.
«Радуйте» своих коллег-разрабочтиков граматно оформленными дефектами!