Home

Так уж случилось, что у нас накопилась масса материала, посвященного теме создания идеального отчета об ошибках (bug report). Обобщив эту информацию и вооружившись практическим опытом, мы решили написать статью. Перед вами подробный текст о стандарте написания баг репортов.

Каналы поступления багов

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

• В процессе тестирования — функционального и нефункционального.
• Обращение клиента (заказчика) с информацией о возникшей проблеме.
• Баги, выявленные пользователями. Соответствующая информация может быть передана как разработчикам, так и заказчику.
• Ошибки полученные при помощи систем мониторинга, например Sentry, Errbit, Crashlytics.

Единственным правильным (минимизирующим негативные последствия) каналом поступления информации о багах можно считать первый. Увы, практика иногда расходится с теорией. Случаются проколы, и баги поступают по каналам №2 и №3. Эту практику можно назвать безапелляционно порочной, но ее не избежать. Поэтому мы стараемся сводить подобные инциденты к минимуму. Если второй и третий каналы не подают признаков жизни — вы гуру QA, и у вас определенно есть чему поучиться.

Направления работы отдела QA

С каналами поступления информации о багах мы определились. Теперь перейдем к направлениям работы QA инженеров. Их несколько:

• Веб-приложения;
• Мобильные приложения (iOS и Android);
• API (как часть мобильного или веб-приложения или или же в качестве самостоятельного проекта);

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

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

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

Написание bug report: как это происходит

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

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

Чего делать нельзя? Нельзя информировать сразу о нескольких проблемах в пределах одного баг репорта. Закон джунглей: один bug report = одна проблема. Не ленитесь.

Чем плох баг репорт с несколькими проблемами в пределах одной задачи? Это значительно замедляет процесс их устранения. Следите за руками: после починки дефекта разработчик переназначает задачу на QA специалиста для проверки. Если мы имеем несколько проблем в одной задаче – разработчик не сможет отдать их на проверку, пока не устранит каждую из них. Чувствуете как утекает время? Когда же все баги упакованы в отдельную задачу, QA специалист может приступить к проверке исправлений значительно раньше. Таким образом, жизненный цикл бага (переоткрытие, закрытие) проходит быстрее, и программное обеспечение быстрее продвигается к релизу.

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

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

К слову, баг репорт состоит не только из описания. Любое сообщение о дефекте включает в себя два элемента:

• заголовок;
• описание.

Рассмотрим каждый из них в отдельности.

Заголовок

При составлении заголовка мы используем золотое правило: “Что? Где? При каких условиях?”. Заголовок — это первое, что увидят разработчики, менеджер проекта или ваши коллеги — QA специалисты. Сделав его максимально простым, точным и понятным, вы сразу же зададите верное направление. Итак, заголовок отчета об ошибке должен:

• Содержать предельно краткую, но в то же время достаточную для понимания сути проблемы информацию о баге;
• Ответить на три вопроса: Что? Где? И при каких условиях? (или хотя бы на те 1-2 вопроса, которые применимы к конкретной ситуации);
• Быть достаточно коротким, чтобы полностью помещаться на экране (имеются в виду баг-трекинговые системы, где заголовок обрезается или приводит к необходимости скроллинга);
• Содержать информацию об окружении, под которым был обнаружен баг (в зависимости от типа проекта);
• Быть законченным предложением русского или английского языка, построенным в соответствии с правилами грамматики.

Давайте рассмотрим работу с заголовком на простом примере:

1. Ситуация: поле описания товара в веб-приложении должно допускать ввод максимум 250 символов. В процессе тестирования выяснилось, что необходимое ограничение отсутствует (вводится хоть миллион символов).
2. Суть проблемы: исследование показало, что ни на клиентской, ни на серверной стороне нет никаких механизмов, проверяющих и/или ограничивающих количество символов, вводимых в поле описания товара.
3. Используем золотое правило. Что: отсутствует проверка и ограничение длины вводимого текста. Где: поле описания товара. При каких условиях: при любых, то есть — всегда.
4. Формулировка: отсутствуют проверка и ограничение максимальной длины текста, вводимого в поле описания товара.
5. Сокращение (итоговое summary): Нет ограничения максимальной длины поля «Описание».
6. Англоязычный вариант: No check for max length of Description field.

Небольшой комментарий к информации об окружении и проектных традициях. Приведем простой пример. Мы имеем дело с проектом, в пределах которого разрабатывается мобильное приложение под две платформы: iOS и Android. В зависимости от того, к какой платформе привязан баг, в заголовке указываем: iOS или Android. Например, “iOS. Application accepts dates of birth from the future.”.

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

Описание

Переходим ко второму компоненту bug report. Описание должно содержать следующую информацию:

1. Подготовительные операции, то есть действия, обеспечивающие возможность воспроизведения проблемы.
2. Шаги воспроизведения. Сразу заметим: везде нужна золотая середина. Категорически запрещается пропускать важные шаги. Но в то же время не следует разжевывать очевидные вещи. Например, вставлять скриншоты в каждый отчет об ошибке совершенно не обязательно. Не плодите лишние сущности. Если они ничем не помогут в воспроизведении проблемы — не тратьте время на их изготовление.
3. Актуальный результат.
4. Ожидаемый результат.
5. Дополнительная информация: различного рода уточнения, логины, пароли и прочее. Все, что может понадобиться в процессе воспроизведения проблемы.
6. Уровень проблемы. Чаще всего используются следующие уровни (это не панацея, в зависимости от традиций компании или типа используемой системы отслеживания багов, названия уровней могут меняться):

• Blocker — устанавливается, если баг блокирует дальнейшую работу приложения или процесс тестирования.
• Critical — присваивается при значительном влиянии проблемы на поведение ПО, но без блокировки его работы или процесса тестирования.
• Major — указывается при незначительном влиянии на эталонное поведение ПО. Проблема такого уровня не блокирует работу программного обеспечения и процесс тестирования. В качестве примера можно привести некорректный подсчет количества записей в каком либо списке.
• Minor — ставится в тех случаях, когда баг не оказывает влияния на функционал и поведение ПО. Например, это может быть опечатка или грамматическая ошибка в тексте, очень сложно воспроизводимый дефект.

При работе с Pivotal Tracker мы привыкли маркировать уровни проблемы цифровым значением от 1 до 4, это значение указывается в качестве label. По уровням градация следующая: 1 — это Blocker и Critical, 2 — это Major, 3 — это Minor и 4 — это Trivial. Такая градация уровня проблемы используется на всех проектах, которые ведутся в Pivotal Tracker.

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

• Подготовительные операции. Самый простой пример: авторизация перед совершением каких-либо действий в панели управления.
• Шаги воспроизведения проблемы. Последовательность действий, приводящих к возникновению (проявлению) дефекта. Шаги могут сопровождаться скриншотами или видео. Однако наличия набора медиафайлов недостаточно. Текстовое описание шагов должно присутствовать всегда и в обязательном порядке.
• Актуальный результат — ошибка или поведение ПО, не соответствующее описанию в спецификации проекта.
• Ожидаемый результат — описание типового поведения ПО, без ошибки и соответствующего описанию в спецификации проекта.
• Информация об окружении, если она необходима для воспроизведения бага (версия приложения и/или браузера, операционная система, разрешение экрана, логин и пароль, примеры файлов, локализация)
• Уровень проблемы (minor, major, critical или blocker).

Примеры

Пример #1

Один из баг репортов для мобильного приложения. Проект ведется в Pivotal Tracker. Уровню проблемы присваивается значение в диапазоне от 1 до 4, где наиболее важные моменты — это “1” и далее по убыванию. Приложение разрабатывалось сразу под две платформы — Android и iOS. Поэтому мы решили прописывать платформу в заголовок задачи.

Переходим к составляющим баг репорта:

Заголовок — Android. About Track screen. Nothing happens after tap on the Label. Как было сказано выше, мы указываем платформу, тем самым  отвечая на вопрос “где?”. То есть: на платформе Android, на экране About Track. Далее мы отвечаем на вопросы “что?” и “когда?” — Nothing happens after tap on the Label.

Так как отдельных полей о тестовом окружении в Pivotal Tracker не предусмотрено, мы добавляем информацию о билде (Build v2.0.6) и версии Android, на которой был воспроизведен баг (Android 6.0), в поле Description.

В этом же поле прописываем шаги воспроизведения бага:

1. Open a track with related Label (as the example EDX — My Friend Extended Mix)
2. Tap on the Info icon (top right corner)
3. Tap on the Label name, nothing happens

И ожидаемый результат: Expected behaviour: Label screen should be opened.

Кроме того, к задаче были прикреплены скриншоты экрана About Track с явным указанием проблемной надписи. При нажатии на нее ожидался переход на другой экран.

Пример #2

Следующий пример — баг репорт из проекта, связанного с реализацией REST API для мобильных приложений. Проблема состояла в том, что в ответе не возвращалась необходимая информация (атрибуты).

Кликните на изображение для увеличения

Проект также велся в Pivotal Tracker, поэтому уровень проблемы был указан с помощью label. Использовалась аналогичная шкала (от 1 до 4). Мы присвоили проблеме уровень “2”, так как отсутствие данной в ответе метода не позволяло выполнить некоторые операции в профиле пользователя.

Итак, заголовок — The method «View User Profile» should return information about user’s location. Мы совершенно отчетливо указываем на метод и проблему. Далее в поле Description мы даем понять, что речь идет о стейджинге.

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

     Email: Этот e-mail адрес защищен от спам-ботов, для его просмотра у Вас должен быть включен Javascript

     Password: qwerty

     Token: xVjowqgm-FHjNwB9tAbG

Описываем проблему и добавляем техническую информацию: пример вызова метода при помощи curl и текущий ответ.

Наконец, указываем что мы ожидали увидеть в ответе недостающие атрибуты.

Expected attributes:

• Location name (location_name)
• location ID (location_id)
• location type (location_type).

Выводы

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

Что еще важно отметить? На сегодняшний день существует масса систем для автоматического сбора информации об ошибках. Например, Errbit для веб или Crashlitics для мобильных приложений. Они могут быть интегрированы с вашей системой отслеживания ошибок и передавать все технические подробности проблемы. Однако автоматически созданные задачи должны тщательно исследоваться тестировщиком для определения и добавления шагов воспроизведения проблемы. Лишь после этого задача передается разработчикам.

Использование общих шаблонов и практик дизайна отчетов об ошибках в пределах компании позволяет существенно сократить время коммуникации между разработчиками и QA специалистами. Дело в том, что согласование задач (то есть случаи, когда разработчики возвращают тестировщикам задачи со статусами rejected, can’t reproduce, more info) зачастую существенно затягивается. Соблюдение же правил написания bug reports позволяет решить эту проблему. В результате мы экономим кучу драгоценного времени. Даже не сомневайтесь, что заказчики и пользователи ПО оценят это положительно.

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