Баг репорт что где когда
Тестирование
Требования к обязательным полям баг репорта
Отметим, что обязательными полями баг репорта являются: короткое описание (Bug Summary), серьезность (Severity), шаги к воспроизведению (Steps to reproduce), результат (Actual Result), ожидаемый результат (Expected Result). Ниже приведены требования и примеры по заполнению этих полей.
Короткое описание
Название говорит само за себя. В одном предложении вам надо уместить смысл всего баг репорта, а именно: коротко и ясно, используя правильную терминологию сказать что и где не работает. Например:
В дополнение предлагаем вам изучить Принцип «Где? Что? Когда?», описанный на страницах блога «QA Nest»:
«В чем этот принцип состоит?
Составьте предложение, в котором факты дефекта изложены в следующей последовательности:
Серьезность
В двух словах можно отметить, что если проблема найдена в ключевой функциональности приложения и после ее возникновения приложение становится полностью недоступно, и дальнейшая работа с ним невозможна, то она блокирующая. Обычно все блокирующие проблемы находятся во время первичной проверки новой версии продукта (Build Verification Test, Smoke Test), т.к. их наличие не позволяет полноценно проводить тестирование. Если же тестирование может быть продолжено, то серьезность данного дефекта будет критическая. На счет значительных, незначительных и тривиальных ошибок вопрос достаточно прозрачный и на наш взгляд не требует лишних объяснений.
Шаги к воспроизведению / Результат / Ожидаемый результат
Очень важно четко описать все шаги, с упоминаем всех вводимых данных (имени пользователя, данных для заполнения формы) и промежуточных результатов.
Шаги к воспроизведению
1. Войдите в системы: Пользователь Тестер1, пароль xxxXXX
—> Вход в систему осуществлен
2. Кликните линк Профайл
—> Страница Профайл открылась
3. Введите Новое имя пользователя: Тестер2
4. Нажмите кнопку Сохранить
Результат
На экране появилась ошибка. Новое имя пользователя не было сохранено
Ожидаемый результат
Страница профайл перегрузилась. Новое значение имени пользователя сохранено.
Основные ошибки при написании багов репортов
Недостаточность предоставленных данных
Не всегда одна и таже проблема проявляется при всех вводимых значениях и под любым вошедшим в систему пользователем, поэтому настоятельно рекомендуется вносить все необходимые данные в баг репорт
Определение серьезности
Очень часто происходит либо завышение, либо занижение серьезности дефекта, что может привести к неправильной очередности при решении проблемы.
Язык описания
Часто при описании проблемы используются неправильная терминология или сложные речевые обороты, которые могут ввести в заблуждение человека, ответственного за решение проблемы.
Отсутствие ожидаемого результата
В случаях, если вы не указали, что же должно быть требуемым поведением системы, вы тратите время разработчика, на поиск данной информации, тем самым замедляете исправления дефекта. Вы должны указать пункт в требованиях, написанный тест кейс или же ваше личное мнение, если эта ситуация не была документирована.
Заполнение полей баг репорта
В описанной ниже таблице представлены основные поля баг репорта и роль работника, ответственного за заполнение данного поля. Красным цветом выделены обязательные для заполнения поля:
Что такое правильный баг репорт и по какому шаблону его оформить: базовые правила
Хочешь узнать, что такое баг репорт и какие у него есть правила оформления? Мы собрали самую полную инструкцию о том, по какому шаблону и по каким правилам оформлять баг репорты, которая поможет даже новичкам.
В этом материале о багах вы узнаете:
Что такое баг репорт
Баг репорт — это документ, который создает тестировщик, когда он обнаружил баг или ошибку. Дословно с английского Bug Report переводится как «отчет об ошибке».
Это технический документ. Поэтому он создается по определенным правилам и структуре. Формат баг репорта иногда меняется в зависимости от компании, в которой вы работаете, но костяк и суть всегда сохраняются.
Хотите научиться распознавать баги писать правильные баг репорты на примерах? Вам помогут наши менторы-тестировщики!
Шаблон и правила оформления баг репортов
Вот примерная форма и шаблон:
Степени серьезности и приоритетов в баг репортах
В таблице, которая расположена выше, есть две строки, которые мы обещали раскрыть подробнее. Степени серьезности и приоритетов.
Степень серьезности — это то, насколько критичен баг для программы, как из-за него изменяется ее работа. Существует пять основных степеней серьезности:
Хотите научиться писать идеальные баг репорты на примерах? Вам помогут наши менторы-тестировщики!
Степени приоритета — это то, в каком порядке нужно решать проблемы. Существует три степени приоритетности:
Понятия степени серьезности и степени приоритета связаны напрямую. Степень приоритета определяется исходя из степени серьезности.
Как правильно оформить баг репорт
Баг репорт — это технический документ. Поэтому он должен быть написан в техническом стиле: без художественности, четко и понятно. Чтобы ничего не пропустить, советуем идти по тому шаблону, который принят у вас в компании. Если его нет, можете использовать нашу таблицу, из раздела «Структура».
Отдельно обратите внимание на раздел «Шаги воспроизведения». Начинающие тестировщики часто ошибаются именно там. Во-первых, в этом разделе должны быть только необходимые шаги. Во-вторых, они должны гарантировать воспроизведение. Чтобы не ошибиться, после заполнения остальной части таблицы, перечитайте этот раздел и перепроверьте его.
Жизненный цикл бага
Баг репорт может изменяться в зависимости от того, на какой стадии жизни находится сам баг.
По умолчанию после обнаружения он попадает на стадию «Новый». После завершения всех по работ по нему, он переходит в стадию «Закрытый».
Между этими крайними стадиями есть еще 5 стадий, в которых он может побывать:
Эту схема проще понять, если представить ее визуально. Схема жизненного цикла бага:
Локализация дефектов и оформление баг-репортов
В этой статье мы расскажем о том, что делает QA-специалист, когда он находит тот или иной баг. Также рассмотрим, какие бывают дефекты и с чем их «едят».
Основные термины:
Дефект (или баг) — изъян в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию. Дефект, обнаруженный во время выполнения, может привести к отказам компонента или системы. Например: невозможно сохранить данные после заполнения анкеты.
Ошибка — действие человека, которое может привести к неправильному результату. Например: ввод букв в поле для ввода даты (должны приниматься только цифры) с последующим сохранением данных.
Отказ (failure) — отклонение компонента или системы от ожидаемого результата, выполнения, эксплуатации. Например: при переходе на следующую страницу анкеты данные предыдущей страницы затираются.
— не сохраняются изменения данных в профиле;
— не работает добавление комментария;
— не работает удаление товара из корзины;
— не работает поиск.
— текст вылезает за границы поля;
— элемент управления сайтом наслаивается на нижестоящий элемент;
— не отображается картинка.
— можно поставить дату рождения «из будущего», а также несуществующие даты — 31 февраля, 32 декабря и т.п.;
— можно сделать заказ, не указав адрес доставки;
— логика поиска работает неправильно.
— орфографические и пунктуационные ошибки;
— картинка товара не соответствует карточке товара;
— конвертация валют идет по неправильному курсу (калькулятор считает правильно, но при программировании указан неверный курс).
— отсутствие подсветки или уведомления об ошибке при некорректно заполненных полях формы;
— сброс всех данных при ошибке заполнения регистрационной формы;
— перегруженный интерфейс.
— можно получить логин, пароль в результате использования SQL-инъекций;
— неограниченное время жизни сессии после авторизации.
Итак, мы рассмотрели типы и виды дефектов. Теперь расскажем о том, как их документировать.
Документирование ошибок
Отчет об ошибке (Bug Report) — это документ, описывающий ситуацию или последовательность действий, приведшую к некорректной работе объекта тестирования, с указанием причин и ожидаемого результата.
«Следующий этап заключается в документировании ошибок», — могли бы подумать вы, но оказались бы неправы.
Нельзя просто взять и задокументировать найденный дефект. Прежде всего, важно выполнить локализацию.
Перепроверка дефекта
Нужно проверить себя еще раз: воспроизвести баг снова при тех же условиях. Если ошибка не повторилась при очередном тестировании, то нужно разобраться, точно ли были соблюдены все действия и шаги воспроизведения, приведшие к этому результату. Возможно, дефект появляется только при первоначальной загрузке системы (при первом использовании). Для того, чтобы более точно определить условия воспроизведения ошибки, необходимо эту ошибку локализовать.
Локализация дефекта
Чтобы локализовать баг, необходимо собрать максимальное количество информации о его воспроизведении:
Например, не проходит восстановление пароля. Необходимо выявить, откуда приходит запрос на сервер в неверном формате — от backend либо frontend.
Например, в одной из форм, которую редко используют, возникает ошибка при нажатии на кнопку «Редактировать». Если в качестве временного варианта решения проблемы скрыть кнопку, это может повлиять на аналогичную форму в другом окне/вкладке, к которой пользователи обращаются чаще. Для качественного анализа необходимо знать, как работает приложение и какие зависимости могут быть между его частями.
Нужно проверить, соответствует ли результат тестирования ожидаемому результату. Справиться с этой задачей помогает техническое задание (в частности, требования к продукту), где должна быть задокументирована информация о тестируемом ПО и его функционировании. Пропускать этот шаг при тестировании не следует: если специалист недостаточно опытен, не зная требований, он может ошибаться и неправильно понимать, что относится к багам, а что нет. Внимательное изучение документации позволяет избежать таких ошибок.
Необходимо воспроизвести баг в разных операционных системах (iOS, Android, Windows и т.д.) и браузерах (Google Chrome, Mozilla, Internet Explorer и др.). При этом нужно проверить требования к продукту, чтобы выяснить, какие системы должны поддерживаться. Некоторые приложения работают только в определенных ОС или браузерах, поэтому проверять другие варианты не нужно.
Например, desktop-приложение предназначено для использования на компьютерах, поэтому зачастую нет необходимости тестировать его на мобильных устройствах. Для смартфонов в идеале должна быть разработана отдельная мобильная версия, которую, в свою очередь, нет смысла тестировать на компьютерах. Кроме того, есть web-приложения, которые могут работать и на компьютерах, и на мобильных устройствах, а тестировать их нужно на всех типах устройств. Для тестирования можно использовать эмулятор той или иной среды, но в рамках статьи мы не будем затрагивать этот вопрос.
Мобильную версию приложения нужно тестировать на нескольких устройствах с разной диагональю экрана. При этом можно руководствоваться требованиями к ПО, в которых должно быть указано, с какими устройствами это ПО совместимо.
Для того, чтобы не запутаться в реализованных задачах, в разработке используют версионность ПО. Иногда тот или иной баг воспроизводится в одной версии продукта, но не воспроизводится в другой. Этот атрибут обязательно необходимо указывать в баг-репорте, чтобы программист понимал, в какой ветке нужно искать проблему.
Возможно, дефект был найден при нехватке внутренней или оперативной памяти устройства. В таком случае баг может воспроизводиться на идентичных устройствах по-разному.
Для того, чтобы оптимизировать сроки тестирования, мы рекомендуем использовать техники тест-дизайна.
Фиксирование доказательств
Доказательства воспроизведения бага нужно фиксировать при помощи логов, скринов или записи экрана.
Live-логирование – это снятие системных логов в режиме реального времени. Для этого можно использовать следующие программы: Fiddler, Visual Studio для Windows, iTools, Xcode для iOS, Android Debug Monitor, Android Studio для Android и др.
Оформление баг-репорта
Все найденные дефекты обязательно нужно документировать, чтобы каждый задействованный на проекте специалист мог получить инструкции по воспроизведению обнаруженного дефекта и понять, насколько это критично. Если в команде принято устно передавать разработчику информацию о найденных дефектах, есть риск упустить что-то из вида.
Дефект, который не задокументирован – не найден!
Когда вся необходимая информация собрана, а баг локализован, можно приступать к оформлению баг-репорта в таск-трекере. Чем точнее описание бага, тем меньше времени нужно для его исправления. Список атрибутов для каждого проекта индивидуален, но некоторые из них – например, шаги воспроизведения, ожидаемый результат, фактический результат – присутствуют практически всегда.
Баг должен быть описан кратко и ёмко, иметь понятное название. Это поможет разработчику разобраться в сути ошибки и в том, может ли он взять этот случай в работу, если занимается соответствующим разделом системы. Также это позволяет упростить подключение новых специалистов на проект, особенно если разработка ведется много лет подряд, а запоминать баги и отслеживать их в таск-трекере становится все сложнее. Название проекта можно составлять по принципу «Где? Что? Когда?» или «Что? Где? Когда?», в зависимости от внутренних правил команды.
Например:
Где происходит? — В карточке клиента (в каком разделе системы).
Что именно происходит? — Не сохраняются данные.
Когда происходит? — При сохранении изменений.
В какой части функциональности тестируемого продукта найден баг.
Версия продукта, ветка разработки, в которой воспроизводится ошибка.
Этот атрибут показывает влияние дефекта на функциональность системы, например:
· Blocker — дефект, блокирующий использование системы.
· Critical — ошибка, которая нарушает основную бизнес-логику работы системы.
· Major — ошибка, которая нарушает работу определенной функции, но не всей системы.
· Minor — незначительная ошибка, не нарушающая бизнес-логику приложения, например, ошибка пользовательского интерфейса.
· Trivial — малозаметная, неочевидная ошибка. Это может быть опечатка, неправильная иконка и т.п.
Приоритет определяет, насколько срочно нужно исправить ошибку. Обычно выделяют следующие виды приоритетов:
Статус указывает стадию жизненного цикла бага, взят он в работу или уже решен. Примеры: to do, in progress, in testing (on QA), done. В зависимости от особенностей проекта возможны дополнительные статусы (например, аналитика).
Баг-репорт отправляют тимлиду проекта или разработчику, который будет заниматься исправлением дефекта, в зависимости от принятых в команде договоренностей.
Где найден баг: операционная система, наименование и версия браузера.
Необходимо для описания действий, которые предшествовали воспроизведению бага. Например, клиент авторизован в системе, создана заявка с параметрами ABC и т.д. Баг-репорт может не содержать предусловие, но иногда оно бывает необходимо для того, чтобы проще описать шаги воспроизведения.
Один из самых важных атрибутов — описание шагов, которые привели к нахождению бага. Оптимально использовать 5-7 понятных и кратких шагов для описания бага, например:
1. Открыть (. )
2. Кликнуть (…)
3. Ввести в поле А значение N1
4. Ввести в поле B значение N2
5. Кликнуть кнопку «Calculate»
Что произошло после воспроизведения указанных выше шагов.
Что должно произойти после воспроизведения шагов тестирования, согласно требованиям.
Логи, скриншоты, видеозапись экрана — всё, что поможет разработчику понять суть ошибки и исправить ее.
После составления баг-репорта обязательно нужно проверить его, чтобы избежать ошибок или опечаток.
Локализация и оформление багов — необходимые составляющие работы QA-специалиста с программным продуктом. Приглашаем подробнее ознакомиться с услугами тестирования и обеспечения качества в SimbirSoft.
Как составить баг-репорт: мини-гайд
Среди всех вещей, связанных с тестированием, есть кое-что, с чем тестировщик сталкивается ежедневно. Это баг-репорт: документ, описывающий баг, его серьезность и приоритет, а также шаги, позволяющие его воспроизвести. Опираясь на баг-репорты, разработчики могут быстро определить, какая часть кода работает неправильно, и исправить ее.
Хорошо написанный баг-репорт гарантирует эффективное сотрудничество между командами разработчиков и тестировщиков. Поэтому умение писать баг-репорты — один из самых важных навыков тестировщика.
Как же писать баг-репорты, чтобы разработчики были ими довольны? В этой статье вы найдете несколько советов.
Как написать хороший баг-репорт
Когда дело касается написания документации, есть одно универсальное правило: пишите попроще. Чем проще, тем лучше.
Но «попроще» не значит «покороче». Баг-репорты должны содержать подробности, позволяющие читателю понять природу бага. То есть в них должно быть достаточно сведений, чтобы понять, почему описываемое поведение — баг, и как его воспроизвести. Вместе с тем нужно стараться не включать в баг-репорт лишнего и не повторяться.
Что же мы подразумеваем под «хорошим» баг-репортом? Мы можем сказать, что баг-репорт эффективен, если:
Не пытайтесь использовать баг-репорт как доказательство того, что кто-то совершил ошибку. Указывайте только значимую информацию и придерживайтесь нейтрального тона. Всегда перечитывайте то, что написали, прежде чем отправить.
Непременно воспроизведите баг два-три раза, прежде чем начать его документировать. Не включайте в репорт больше одного дефекта. Наконец, прежде чем написать репорт о новом баге, убедитесь, что его нет в списке уже известных багов (чтобы избежать дублирования).
Структура баг-репорта
Если вы ищете пример баг-репорта, вот список вещей, которые должны в нем быть:
Можете использовать этот список в качестве плана для своего следующего баг-репорта. Давайте еще разберем вкратце каждый пункт.
1. Краткое описание
В идеале, описание бага должно раскрывать ответы на три вопроса: что, где и когда. Например: «(что?) Появляется Console Error (где?) во вкладке Статистика (когда?) после того, как пользователь нажимает на кнопку Скачать». Иногда часть «где» можно опустить. Например: «Приложение падает после того, как пользователь нажимает на кнопку Войти». Можно указать страницу, на которой это происходит. Но если у вас есть единственное место, где пользователь может найти эту форму, то и так очевидно, где он нажимает на кнопку.
2. Продукт
В этой части обычно пишется версия сборки, которая тестируется. Тестировщик указывает эту информацию, чтобы разработчик мог сравнить последнюю, тестируемую версию продукта с предыдущей и посмотреть, что изменилось. Благодаря этому куда легче найти причину поломки.
3. Платформа
Тестировщик должен указать, на какой платформе проявляется баг. Для десктопных проектов укажите операционную систему. Для веб-проектов — самые важные сведения о браузере. Что касается мобильных проектов, для них нужно указать модель девайса и его операционную систему.
4. Статус
Указание статуса бага помогает держать всю команду в курсе процесса исправления. Статус может сообщать о том, что разработчик принял баг в работу, вернул на повторное тестирование, исправил и закрыл и т. п. Количество возможных статусов зависит от принятого в команде рабочего процесса.
5. Приоритет
Приоритет бага показывает, насколько критичен дефект для бизнеса, и определяет очередность исправления. Обычно приоритет устанавливают менеджер продукта, собственник продукта или тимлид.
6. Серьезность
В отличие от приоритета, серьезность определяется тестировщиком. Устанавливая уровень серьезности, он исходит из того, насколько опасен баг для всей системы, в какой степени он затрагивает самый важный функционал и т. п.О серьезности и приоритетности багов можно почитать в статье «Серьезность и приоритет багов — в чем разница?»
7. Предусловия
В предусловиях описываются действия, которые нужно выполнить, и параметры, которые нужно применить перед выполнением шагов, позволяющих воспроизвести баг. Это описание не имеет какого-то четкого формата, просто придерживайтесь логического порядка.
8. Шаги воспроизведения
Наилучший способ описать эти шаги — составить пронумерованный список с последовательностью действий пользователя, приводящих к проявлению бага. Используйте простые предложения.
9. Фактический результат
Фактический результат — это проблема, появляющаяся, когда пользователь выполняет шаги, указанные выше.
Опишите результат, придерживаясь того же правила, что и для краткого описания бага. Обозначьте, что происходит, где и когда. Это поможет разработчику понять, в чем проблема. Лаконичное и четкое описание пригодится и QA-команде в будущем.
10. Ожидаемый результат
В этом разделе опишите ожидаемый результат шагов, описанных в п.8. То есть изложите, как приложение должно было бы себя вести.
Ошибка тоже может быть ожидаемым результатом — если тестировщик проверяет негативный сценарий. Например, если пользователь вводит неправильные учетные данные, он не должен войти в систему, вместо этого он должен увидеть сообщение об ошибке.
11. Прикрепленные файлы
Это дополнительные материалы, которые можно добавить к баг-репорту. Часто с визуальными руководствами бывает проще воспроизвести баг. Особенно, если баг сложно описать словами.
Добавление скриншотов или коротких видео поможет избежать недопонимания. Только не забывайте, что визуальные материалы должны быть релевантными и понятными.
Итоги
Документацию нужно создавать так, чтобы она была легкой в использовании и понятной другим членам команды. Такая документация сэкономит вам много времени в будущем, когда проект разрастется, а в команде появятся новички.
Теперь вы знаете, как написать баг-репорт. Более того: вы знаете, как написать его так, чтобы разработчики были довольны. Сохраните себе этот план и пользуйтесь им в работе!
Ты ж тестировщик или как правильно составлять Bug report
Так уж случилось, что у нас накопилась масса материала, посвященного теме создания идеального отчета об ошибках (bug report). Обобщив эту информацию и вооружившись практическим опытом, мы решили написать статью. Перед вами подробный текст о стандарте написания баг репортов.
Каналы поступления багов
Начнем с каналов поступления багов. Мы можем столкнуться с проблемами и получить информацию об их появлении следующим образом:
Единственным правильным (минимизирующим негативные последствия) каналом поступления информации о багах можно считать первый. Увы, практика иногда расходится с теорией. Случаются проколы, и баги поступают по каналам №2 и №3. Эту практику можно назвать безапелляционно порочной, но ее не избежать. Поэтому мы стараемся сводить подобные инциденты к минимуму. Если второй и третий каналы не подают признаков жизни — вы гуру QA, и у вас определенно есть чему поучиться.
Направления работы отдела QA
С каналами поступления информации о багах мы определились. Теперь перейдем к направлениям работы QA инженеров. Их несколько:
В зависимости от направления работы состав информации, подаваемой в баг репорт, будет изменяться. Однако окончательная цель QA специалиста останется неизменной. Речь, разумеется, идет об устранении бага.
Вот здесь начинается самое интересное. Чем полнее и точнее подана информация, тем проще QA инженеру или менеджеру проекта определить приоритет проблемы, а разработчику — ее устранить. Все просто, у команды общие цели — стабильный проект, довольный заказчик и счастливые пользователи программного обеспечения, отсутствие переработок.
Написание bug report — один из кирпичиков, которые закладываются в фундамент достижения этих целей. Он должен быть ровным и красивым. В противном случае мы сталкиваемся с проблемами: разработчикам приходится тратить время на воспроизведение бага, вместо того чтобы писать код.
Написание bug report: как это происходит
В идеальном мире QA специалист добавляет баг в трекинговую систему только в том случае, если он может воспроизвести проблему. Сообщения же о дефектах, которые приходят от заказчика и пользователей, не всегда содержат максимум полезной информации. В таких случаях QA специалист должен либо самостоятельно определить проблему, либо связаться с лицами, заявившими о ее наличии и собрать все недостающие сведения.
Прежде чем создавать баг-репорт, убедитесь, что такого же дефекта нет в системе отслеживания ошибок. Если он уже зафиксирован, при необходимости дополните описание актуальной информацией.
Чего делать нельзя? Нельзя информировать сразу о нескольких проблемах в пределах одного баг репорта. Закон джунглей: один bug report = одна проблема. Не ленитесь.
Чем плох баг репорт с несколькими проблемами в пределах одной задачи? Это значительно замедляет процесс их устранения. Следите за руками: после починки дефекта разработчик переназначает задачу на QA специалиста для проверки. Если мы имеем несколько проблем в одной задаче – разработчик не сможет отдать их на проверку, пока не устранит каждую из них. Чувствуете как утекает время? Когда же все баги упакованы в отдельную задачу, QA специалист может приступить к проверке исправлений значительно раньше. Таким образом, жизненный цикл бага (переоткрытие, закрытие) проходит быстрее, и программное обеспечение быстрее продвигается к релизу.
Нельзя заводить, как баг, то, что не имеет отношения к спецификации проекта. Не нужно отнимать у разработчиков время на работу, которая не согласована.
По аналогии поступаем и с code-review. Весьма полезно иногда показывать коллегам свежесозданный отчет об ошибке. Возможно они подскажут, что следует добавить и/или исключить из описания проблемы.
К слову, баг репорт состоит не только из описания. Любое сообщение о дефекте включает в себя два элемента:
Рассмотрим каждый из них в отдельности.
Заголовок
При составлении заголовка мы используем золотое правило: “Что? Где? При каких условиях?”. Заголовок — это первое, что увидят разработчики, менеджер проекта или ваши коллеги — QA специалисты. Сделав его максимально простым, точным и понятным, вы сразу же зададите верное направление. Итак, заголовок отчета об ошибке должен:
Давайте рассмотрим работу с заголовком на простом примере:
Небольшой комментарий к информации об окружении и проектных традициях. Приведем простой пример. Мы имеем дело с проектом, в пределах которого разрабатывается мобильное приложение под две платформы: iOS и Android. В зависимости от того, к какой платформе привязан баг, в заголовке указываем: iOS или Android. Например, “iOS. Application accepts dates of birth from the future.”.
Дополнительный вариант — использование так называемых ярлыков (labels). Некоторые системы отслеживания ошибок предоставляют соответствующий функционал.
Описание
Переходим ко второму компоненту bug report. Описание должно содержать следующую информацию:
При работе с Pivotal Tracker мы привыкли маркировать уровни проблемы цифровым значением от 1 до 4, это значение указывается в качестве label. По уровням градация следующая: 1 — это Blocker и Critical, 2 — это Major, 3 — это Minor и 4 — это Trivial. Такая градация уровня проблемы используется на всех проектах, которые ведутся в Pivotal Tracker.
А теперь рассмотрим каждый из компонентов описания баг репорта в отдельности.
Примеры
Пример #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.
В этом же поле прописываем шаги воспроизведения бага:
И ожидаемый результат: 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, пароль и токен.
Описываем проблему и добавляем техническую информацию: пример вызова метода при помощи curl и текущий ответ.
Наконец, указываем что мы ожидали увидеть в ответе недостающие атрибуты.
Выводы
Как видите, сведения об окружении и технические детали могут меняться в зависимости от направления проекта. В остальном состав подаваемой информации в отчетах об ошибках идентичен.
Что еще важно отметить? На сегодняшний день существует масса систем для автоматического сбора информации об ошибках. Например, Errbit для веб или Crashlitics для мобильных приложений. Они могут быть интегрированы с вашей системой отслеживания ошибок и передавать все технические подробности проблемы. Однако автоматически созданные задачи должны тщательно исследоваться тестировщиком для определения и добавления шагов воспроизведения проблемы. Лишь после этого задача передается разработчикам.
Использование общих шаблонов и практик дизайна отчетов об ошибках в пределах компании позволяет существенно сократить время коммуникации между разработчиками и QA специалистами. Дело в том, что согласование задач (то есть случаи, когда разработчики возвращают тестировщикам задачи со статусами rejected, can’t reproduce, more info) зачастую существенно затягивается. Соблюдение же правил написания bug reports позволяет решить эту проблему. В результате мы экономим кучу драгоценного времени. Даже не сомневайтесь, что заказчики и пользователи ПО оценят это положительно.
Если вам понравилась статья, не забудьте расшарить ее в социальных сетях.