Профессия тестировщика ПО очень многогранна, ведь она требует внимания к деталям, креативности, коммуникативных навыков и усидчивости. Последнее качество особенно пригодится для такой части работы QA-инженера, как составление тестовой документации.
Один из примеров ― баг-репорт (от англ. bug report ― отчёт об ошибке), который содержит описание всех найденных дефектов в работе приложения. Не имеет значения, тестируете ли вы компьютерную игру, приложение для банка или сайт онлайн-магазина ― составление правильного отчёта является залогом продуктивного QA-процесса.
Баг-репорт содержит ответы на следующие вопросы:
- что идёт не так;
- где проявляется дефект;
- когда ошибка воспроизводится.
С этим техническим документом предстоит ознакомиться разработчикам, которые внесут изменения в программный код и исправят ошибки. Именно поэтому баг-репорт должен быть лаконичным, понятным и содержать максимум полезной информации.
Разберёмся, как добиться этого сочетания.
Как выявляют баги?
Вы, как инженер по обеспечению качества, можете узнать о наличии дефектов в программном обеспечении несколькими способами:
- во время проведения тестирования ПО;
- при обращении заказчика с описанием ошибки;
- из сообщений пользователей, которые столкнулись с проблемами во время использования программного продукта.
Идеальный сценарий ― первый, когда дефекты выявляются до релиза специалистами по обеспечению качества. Но иногда до начала составления баг-репорта тестировщику приходится изучать чужой опыт взаимодействия с ПО при появлении ошибки.
Какой инструмент используют для документирования дефектов?
Самой распространённой системой для отслеживания дефектов является JIRA. Данный ресурс позволяет фиксировать ошибки и следить за их жизненным циклом. Но эта программа не такая простая, особенно для новичков в ИТ. Поэтому важно ознакомиться с её функционалом.
Студенты QA Academy уже на базовом курсе получают необходимый багаж знаний для эффективной работы с JIRA, а в этой статье мы подробно рассказали, как прокачать своё мастерство поиска в этой баг-трекинговой системе.
Некоторые компании отдают предпочтение и менее известным инструментам, например, Redmine или Mantis.
Каких правил придерживаться при написании баг-репорта?
Правило №1: следуйте принципу «1 дефект = 1 баг-репорт». Это позволит сохранить прозрачность процессов на проекте и детально следить за исправлением недочётов.
Правило №2: пишите баг-репорт простым и лаконичным языком, ведь от того, насколько быстро разработчик поймёт суть проблемы зависит скорость внесения правок в код.
Правило №3: описывайте дефект кратко, но с сохранением максимума полезной информации.
Правило №4: удостоверьтесь в воспроизводимости ошибки до заведения баг-репорта, повторите свой алгоритм действий и по возможности сократите число шагов.
Правило №5: проверьте, нет ли идентичного дефекта, который уже был зафиксирован.
Если всё в порядке, можно переходить к описанию.
Из каких элементов состоит баг-репорт?
Форма заполнения баг-репорта включает несколько полей (атрибутов). Туда тестировщик вносит характеристики дефекта. Число атрибутов может варьироваться в зависимости от баг-трекинговой системы и особенностей проекта, но с некоторыми тестировщики работают постоянно. Рассмотрим их:
Summary (заголовок)
Первый элемент баг-репорта — это краткое описание сути проблемы. В этом поле мы должны коротко и ясно описать выявленный дефект. Уже на этом этапе вы можете придерживаться правила «Где? Что? Когда или в каких условиях?». Не лишним будет добавить и данные о тестовом окружении, под которым выявлен дефект. Формулируйте этот атрибут в виде связного предложения, так будет проще вникнуть в суть проблемы.
Давайте рассмотрим конкретный пример. Представьте, что вы тестируете площадку объявлений menyaemsya.com. Согласно требованиям, поле с описанием товара должно содержать максимум 350 символов. Но вы видите, что система пропускает описание, которое превышает данный лимит. Для этого дефекта вам нужно составить баг-репорт. Воспользуемся подсказкой «Что? Где? Когда?», чтобы составить заголовок. Получается:
«Ограничение на ввод символов в поле с описанием товара отсутствует на всех страницах».
При тестировании мобильных приложений важно внести и название платформы, iOS или Android.
Заголовок готов. Можем двигаться дальше.
Description (описание)
Содержание этого поля отличается в зависимости от баг-трекинговой системы. Например, JIRA или Redmine предполагают описание шагов воспроизведения ошибки. Пользователи Mantis тут могут более подробно описать суть проблемы, а для описания пути воспользоваться атрибутом «Steps to reproduce» (в пер. с англ. «действия по воспроизведению»). Выглядеть это описание может следующим образом:
- переход на сайт menyaemsya.com;
- вход или регистрация;
- нажатие кнопки «Добавить объявление»;
- ввод символов в поле «Описание».
Если же предстоит выполнить слишком большую последовательность действий, то вы можете начать с описания условий.
«Пользователь авторизован на сайте menyaemsya.com и перешёл в корзину».
Actual/expected result (фактический/ожидаемый результат)
Нам предстоит ещё раз указать на суть дефекта и добавить информацию о том, как элемент ПО должен работать корректно.
Пример заполнения данного раздела:
«При внесении информации в поле “Описание” количество вводимых пользователем знаков не лимитируется. Ожидается, что после внесения 350 символов система не будет выводить на экран знаки и предложит пользователю сократить текст».
Attachments (вложения)
Этот элемент репорта позволяет проиллюстрировать суть бага и поделиться дополнительными данными. Вы можете прикрепить скриншоты, фото, видеозапись или иные файлы. Это упростит понимание сути проблемы и поможет быстрее сориентироваться.
Priority (приоритет)
Это важное поле, которое содержит информацию о срочности исправления дефекта. Данные этого атрибута помогают менеджеру планировать работу на проекте, ведь чем выше приоритет, тем скорее необходимо внести изменения.
Системы определения важности могут отличаться, но скорее всего вы встретитесь с подобной градацией:
- P1 High (высокий приоритет);
- P2 Medium (средний приоритет);
- P3 Low (низкий приоритет);
Высокий приоритет имеют критические дефекты, которые необходимо исправить в кратчайшие сроки. Категория P3 включает те баги, которые не влияют на работу системы и могут быть устранены в последнюю очередь.
Severity (серьёзность)
Ошибки имеют и другую характеристику ― степень серьёзности влияния на систему.
- Blocker — это статус для проблем, которые прерывают работу приложения.
- Critical — такой баг значительно влияет на работоспособность, но не приводит к блокировке.
- Major — ошибка, которая не способствует фундаментальным изменениям, но может привести к незначительным искажениям отображения информации или выполнения некоторых функций.
- Minor — не влияет на работу системы. К этой категории можно отнести ошибки в текстовых блоках или визуальных решениях.
Status (статус)
В этом поле находится актуальная информация о том, в каком состоянии текущая задача. Содержание этого атрибута может варьироваться в зависимости от баг-трекинговой системы. Вы можете столкнуться со следующими обозначениями:
- New – новый баг;
- Feedback – требуется обратная связь;
- Acknowledged – с содержанием документа ознакомились;
- Accepted – ошибка воспроизвелась и была подтверждена;
- Assigned – исправление ошибки назначено;
- Resolved – изменения были внесены;
- Closed – дефект больше не воспроизводится.
Такими являются основные элементы баг-репорта, с которыми приходится встречаться чаще всего. Но в отчёте могут содержаться и дополнительные поля:
- Environment/platform – среда, платформа или операционная система;
- Fix version – этап разработки ПО на момент выявления бага;
- Assignee – пользователь, которому предстоит утвердить или исправить дефект;
- Lable – категория ошибки (текст, визуальные элементы и прочее).
Резюмируем
Написание баг-репорта ― важный элемент QA-процесса, который позволяет ускорить устранение дефекта и подготовить качественное ПО к выходу на рынок. До начала написания документа важно:
- убедиться в воспроизводимости ошибки;
- оценить поведение системы на разных платформах (при необходимости);
- проверить дефект на уникальность в баг-трекинговой системе.
Хороший отчёт об ошибке написан простым и понятным языком, содержит максимум полезной информации. Ключевыми атрибутами баг-репорта являются заголовок, описание, приоритет и статус ошибки. Стоит придерживаться порядка написания отчёта и заполнять все поля в зависимости от особенностей трекинговой платформы и требований проекта.
Умение составлять подобные репорты является важным для тестировщика навыком, который вы можете развить, ежедневно тренируясь. А освоить азы вам помогут наши замечательные преподаватели, сотрудники международной ИТ-компании, на курсе «Основы тестирования ПО». Присоединяйтесь!