Home

Автор: Алена Балакина, тренер Первого Онлайн Института Тестировщиков, http://pointschool.ru/

Здравствуйте, дорогие друзья!

Бесспорно, постановка задач - одна из крупнейших составляющих работы практически любого тестировщика.

От того, насколько качественно вы опишите дефект, будет зависеть срок его исправления, отношение к вам коллег и общая удовлетворенность работой.

А как описать дефект качественно и составить грамотный баг-репорт?

Читайте дальше - в этой статье мы поделимся некоторыми полезностями по составлению самых важных частей баг-репорта!

Заголовок баг-репорта

Несмотря на то, что информации по составлению заголовков довольно много, она часто разнится. От этого многие продолжают путаться в формулировках и составляют неинформативные заголовки.

Почему заголовок это так важно?

1)Заголовки в первую очередь видит руководитель проектов.

В случае правильно составленного заголовка, он сможет определить критичность, быстрее, понять где проблема и делегировать такой дефект на исправление нужному исполнителю.

2)  Заголовки могут пригодиться вам самим.

Представьте, что вы отработали какое то время на проекте, завели кучу дефектов, эти дефекты передали на исправление разработчикам, а вы временно ушли заниматься другими проектами.

Спустя какое то время вы возвращаетесь на проект и получаете задачу - в ускоренном темпе проверить исправленные баги (которые вы сами завели ранее).

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

Принцип “Где? Что? Когда?”

Есть один полезный прием, который подходит для заголовков почти любых багов - это структура “Где? Что? Когда?”

• Где?: В каком месте находится проблема (предложение начинается с существительного, не с предлога)
• Что?: Что происходит или не происходит (согласно ТЗ или представлению о нормальной работе)
• Когда?: При каких условиях проявляется

Единообразное оформление заголовков по данной структуре поможет не только радоваться эстетике списка ваших багов, но и избегать заведения дубликатов.

Шаги воспроизведения проблемы

О важности шагов даже не стоит много писать - они несомненно самая важная часть баг-репорта.

Цель шагов в том, чтобы пройдя по ним, достигнуть фактического результата (именно такого, о котором вы докладываете в репорте и именно одного, а не нескольких).

Маршрут

Вообразите, что подсказываете человеку дорогу до определенного места и описываете маршрут.

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

Шаги  можно представить как точки маршрута.

Они должны быть последовательными, легко и понятно выполняемыми, не требовать от исполнителя лишних размышлений и описывать ориентиры.

В одном шаге должно быть одно ключевое действие, опять таки для того, чтобы не путать исполнителя и сократить ему раздумья.

Наклонение шагов

Шаги лучше всего описывать в одном наклонении, а именно в повелительном.

Это побуждает к конкретному действию и четче выглядит:

Ориентиры

В качестве ориентиров можно и нужно использовать скриншоты.

Если проблема на сайте, то можно сделать скриншот с открытой консолью, а также захватить адресную строку.

Не забудьте акцентировать внимание на проблемном месте:

Видно куда смотреть, открыта консоль с ошибкой, виден URL (разработчик часто первым делом видит скрин и по URL сразу понимает на какой странице проблема)

Ссылки и дополнительные данные в шагах

Тестовые данные для входа (если проблема актуальна, например, только для авторизованных) помогут быстрее воспроизвести ошибку.

По поводу ссылок в шагах есть разные мнения (ведь URL могут измениться и ссылка станет бесполезной), но бесспорно одно - актуальная ссылка под рукой упрощает жизнь и очень не хотелось бы совсем от нее отказываться.

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

Например: кликнуть по ссылке “Акция” (https://mysite.ru/offer) слева в верхнем углу страницы.

Ссылка на ТЗ

Кто помнит ТЗ наизусть? Наверное никто:)

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

Здесь же можно добавить и замечание про ложный след.

Если вы не уверены в причине проблемы, а уточнить ее совсем не у кого, то не нужно эту причину придумывать.

Например, мы знаем, что в разделе с 30% скидкой отображаются товары без скидки.

Но непонятно:

• в раздел попали не те товары (а это задача для того, кто наполняет базу контентом, например отдел контент маркетинга).
• или же товары там нужные, но причина в ошибке скрипта, который не рассчитывает скидку? (а это уже задача к разработчику).

Вынеся неверный вердикт, мы рискуем пнуть задачу не в тот отдел, тем самым затянув время решения проблемы.

Еще рекомендуем ссылаться на ТЗ в шагах.

Например, мы пишем:

“заполнить поле валидными данными”.

Мы сейчас подсмотрели в ТЗ и знаем, что такое валидные данные, а разработчик вряд ли об этом вспомнит и обязательно придет к вам (не очень довольный) за уточнениями.

Поэтому лучше написать: “Заполнить поле числом от 50 000 до 100 000 включительно (согласно ТЗ), например 52 000”

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

Генерализация

В кратце, генерализация дефекта - это процесс проверки различных условий, при которых проблема воспроизводится.

К сожалению, указывая в шагах только определенные условия, мы получаем риск того, что разработчик будет исправлять проблему только для них.

Пояснить можно на очень простом примере, представим, что мы поймали баг:

при вводе в поле промокод текста, содержащего пробелы, возникает ошибка 500.

При воспроизведении этой ошибки мы конечно проверим другие варианты, например: введем только пробелы или поставим пробелы до и после текста.

Но разработчик то не знает, что еще мы проверили и хорошо, если спросит.

Указываем, при каких еще условиях проблема актуальна или неактуальна и получаем меньше пинг понга в задачах :)

Еще, чтобы исполнитель понимал, что проблема шире и повторяется не только с указанными значениями, можно использовать в шагах конструкцию “Любыми.., например”.

Сравните:

"Ввести в поле "Сумма" 500" (как будто проблема только с числом 500)

"Ввести в поле "Сумма" любые положительные числа, например 500" (сразу понятно, что проблема с любыми числами)

Перечитать

Перед тем как сохранить баг-репорт перечитайте его, а потом

.. еще раз внимательно перечитайте.

Проверьте ошибки, проанализируйте понятность.

Во многих проектах прав на редактирование поставленных дефектов не выдают, поэтому нужно очень внимательно отнестись к их постановке.

Эксперимент

Вместо заключения, предлагаем провести эксперимент ;)

1. Сохраните описание одного из своих багов в блокнот, этот файл положите подальше (чтобы не маячил на глазах);
2. Загляните туда через недельки две.
   

Если сможете сразу понять о чем речь и воспроизвести дефект, то поздравляем - баг заведен хорошо

(и сомневаемся, что доставит много радости искать ссылку, ТЗ, проверять какие данные валидны, а какие нет и еще кучу всего вспоминать).

Надеемся, данные советы помогут вам в работе!

До встречи в блоге «Лаборатории качества».

Тренер Первого Онлайн Института тестировщиков (ПОИНТ), Алена Балакина.

Узнать больше о программе и записаться на тренинг можно по ссылке http://pointschool.ru/

Обсудить в форуме