Что такое баг и как оформить баг-репорт в тестировании ПО

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

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

Что такое баг: определение и примеры

Историки технологий говорят, что "багами" называли сбои радаров во время Второй мировой войны. А в 1946 году инженеры Гарварда столкнулись с проблемами в работе новой вычислительной машины Mark II. Как выяснилось, причиной проблем стала бабочка, застрявшая в реле. Инженеры вытащили насекомое из машины и приклеили его к отчету скотчем с подписью “First actual case of bug being found”. 

Так в профессиональных кругах закрепился термин "баг" – это ошибка или неисправность в программном обеспечении, которая приводит к неправильному или неожиданному функционированию системы. Примеры багов в тестировании могут быть очень разнообразными. Типичный сценарий: кнопка “Купить” не реагирует на нажатие, приложение вылетает при входе в аккаунт или калькулятор показывает неправильный результат.

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

• Функциональные баги. Продукт работает не так, как ожидалось. Его кнопки не срабатывают. 

• Баги пользовательского интерфейса (UI/UX). Проблемы с визуалом и удобством использования. К примеру, элементы накладываются друг на друга, шрифты выводятся неправильно, адаптивность ломается.

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

• Баги безопасности. Уязвимости, которые могут привести к несанкционированному доступу или утечке данных. Например, SQL-инъекции, проблемы с авторизацией и т.д.

• Баги совместимости. Программа некорректно работает в различных средах. Например, в разных браузерах, операционных системах или на разных устройствах.

• Баги бизнес-логики. Ошибки в самой логике или алгоритмах программы. К примеру, нескончаемые циклы, неверный порядок операций и т.д.

Важно уметь отличать баг от фичи. Если система ведет себя "странно", но это задокументированное поведение, – это, вероятно, фича (особенность дизайна или логики), а не баг. Фичи бывают очень странными и неинтуитивными. К примеру, при авторизации в приложении пользователь не видит сообщения об успешном входе, а сразу оказывается на главном экране или в личном кабинете. Это может быть как багом, так и замыслом UX-дизайна. Чтобы не ошибиться, тестировщики всегда сверяются с технической документацией и требованиями.

Что такое баг-репорт

Предположим, тестировщик находит в коде ошибку. Что происходит дальше? Нет, он не исправляет ее здесь и сейчас: каждый баг должен быть задокументирован для дальнейшего изучения и оптимального исправления. Именно для этого и создается баг-репорт – это документ, подробно описывающий выявленную проблему в программном обеспечении. 

Написанием баг-репортов занимаются тестировщики и разработчики, а иногда и сами пользователи (например, через специальную форму в приложении). Главная цель такой отчетности – доходчиво и однозначно сообщить разработчику о проблеме, чтобы он мог ее воспроизвести, понять причину и успешно устранить. Качественно написанный баг репорт экономит время разработчиков, уменьшает количество вопросов и ускоряет процесс устранения дефектов.

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

• New (Новый). Баг-репорт только что создан тестировщиком и ожидает рассмотрения.

• Open/Assigned (Открытый/Назначенный). Менеджер или тимлид просматривает баг-репорт и назначает его конкретному разработчику.

• In Progress (В работе). Разработчик работает над исправлением бага.

• Fixed (Исправлено). Разработчик завершил исправление и передал его на повторное тестирование.

• To Verify (На проверку). Тестировщик должен проверить, действительно ли баг исправлен.

• Closed (Закрыто): Если тестировщик подтвердил исправление, баг-репорт закрывается.

• Reopened (Переоткрыт). Если тестировщик обнаружил, что баг вернулся, баг-репорт возвращается в статус "Open" или "In Progress".

• Rejected/Declined (Отклонен): Баг-репорт может быть отклонен, если он не является багом (например, это фича), его невозможно воспроизвести или он дублирует другой отчет.

• Deferred (Отложенный): Исправление бага отложено на более позднюю версию продукта, обычно из-за низкого приоритета или нехватки ресурсов.

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

Структура баг-репорта: из чего состоит отчет

Зачем формировать отдельный репорт по каждому багу в продукте? Такая отчетность должна давать разработчику исчерпывающее представление о предмете ошибки (конкретное несоответствие требованиям) и предоставлять возможность исправить ее без дополнительного копания в документации. Для этого баг-репорт должен содержать определенные обязательные элементы. Давайте посмотрим, как в целом выглядит элементарная базовая структура баг репорта:

1. Название и/или уникальный ID репорта для инструментов трекинга
2. Summary. Краткое описание сути проблемы. Оно должно быть информативным и однозначным  (например: "Не работает кнопка “Сохранить” при заполнении формы”).
3. Impact. Оценка влияния дефекта на работу системы или опыт пользователя. Нужно дать разработчику контекст: блокирует ли баг ключевую функциональность, насколько он критичен и приоритетен.
4. Defect Description/Steps to Reproduce. Развернутое описание ошибки: в каких условиях возникает, что именно идет не так, как ее воспроизвести. Содержит шаги, среду возникновения, фактический и ожидаемый результат.
5. Additions. Дополнительные сведения: скриншоты, видео, логи, данные сеанса или другая техническая информация, которая поможет в воспроизведении и исправлении бага.

В зависимости от потребностей проекта структура документа может отличаться. На практике у каждой команды формируются собственные привычки относительно того, как оформить баг репорт. Например, документ часто может содержать поля "Серьезности" (Severity) и "приоритетности" (Priority) бага, предоставлять подробную информацию о среде выполнения (операционная система, браузер и его версия, версия программы, разрешение экрана и т.д.). 

Дополнительными элементами могут выступать поля для вложений (Attachments), ссылок (Links), обозначения автора репорта и т.д. Качественный баг-репорт – это не просто фиксация ошибки, а мост между тестированием и разработкой.

Пример баг репорта

Выше мы обсуждали теорию, но как выглядит баг репорт на практике? Создать отчет можно даже в электронных таблицах Excel или Google, хотя тестировщики используют более продвинутые специализированные инструменты и платформы: Quality Center, Jira, Mantis, TestRail и т.д. Ниже мы рассмотрим простой пример баг-репорта в электронных таблицах, созданный по базовому шаблону. 

В данном кейсе мы видим условный пример баг репорта в Excel (если быть точными, то это таблица Google). Отчет посвящен мелкому дефекту на сайте онлайн-магазина. Проблема возникает при валидации поля email на форме обратной связи страницы "Контакты", когда пользователь вводит email с кириллическими символами. 

Этот пример баг-репорта ценен тем, что демонстрирует базовую форму отчетности – с полями ID и Summary и т.д. Несмотря на всю простоту, тут подробно описаны среда и условия возникновения бага, задокументировано отклонение продукта от требований и разница между фактическим и ожидаемым результатом. Более того, в поле вложений предоставлены скриншоты, демонстрирующие проблему наглядно. Подобный шаблон отчета об ошибке позволяет разработчику устранить проблему с минимальными усилиями.

Как правильно писать баг-репорт: шаг за шагом

Предположим, вы знаете, как найти баг в программе, и вам нужно впервые создать баг-репорт. С чего начать? Знание нескольких базовых практик поможет задокументировать дефект правильно.

Для начала сосредоточьтесь на обязательных полях. Представьте, что вы объясняете проблему человеку, не видящему ваш экран. Ему обязательно следует предоставить весь необходимый контекст для реакции на проблему.

1. Найдите баг и убедитесь, что он воспроизводится. Попытайтесь вызвать его несколько раз.
2. Определите среду. Где вы его нашли? (К примеру, Chrome на Windows 10).
3. Составьте точный заголовок для Summary. Он должен быть кратким, но максимально информативным: "Что" не работает, "Где" не работает, "Когда" не работает (например: "Кнопка 'Добавить в корзину' не активна после обновления страницы в Chrome").
4. Опишите шаги воспроизведения. Это перечень действий, гарантированно приводящих к багам. Будьте максимально подробными, но лаконичными.
5. Укажите фактический и ожидаемый результат. Что вы увидели (факт) и что должны увидеть (ожидание).
6. Определите серьезность и приоритет. Оцените, насколько баг критичен и как быстро его необходимо исправить.

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

Баг-репорт в JIRA: как создать и оформить

Сегодня одной из самых популярных платформ для IT-менеджмента стала JIRA. Этот продукт предоставляет командам разработчиков множество возможностей для коммуникации и таск-трекинга, в частности – в части контроля качества. Так что сегодня буквально каждый специалист должен знать, как создать баг репорт в Jira. К счастью, это не сложно, достаточно нескольких шагов в дашборде. 

1. Нажмите кнопку "Create" (Создать). Обычно она расположена в верхней части панели навигации Jira.
2. Выберите "Project" (Проект). Укажите проект, к которому относится баг.
3. Выберите "Issue Type" (Тип запроса). Выберите "Bug" (Баг) из списка доступных типов.
4. Заполните поля. Перед вами появятся поля, соответствующие структуре баг-репорта.

В целом баг-репорт шаблон Jira похож на формат отчета, который мы разбирали выше. В нем есть базовые поля Summary и Description. Пользователь может также отписать в поле Description шаги для воспроизведения бага (Steps to reproduce), описание ожидаемых и фактических результатов, описание среды и т.д. Интерфейс предлагает отдельное поле Attachments для удобного закрепления изображений, файлов и медиа. 

Более того, платформа предоставляет диджилизацию таск-менеджмента, поэтому создание баг репорта в Jira разрешает сразу же указать автора отчета (Reporter) и ответственного (Assignee) – это упрощает процесс исправления бага и закрытия задачи как таковой. 

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

Распространенные ошибки при составлении баг-репортов

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

• Нечеткие заголовки и Summary. Общие названия типа "Ошибка на сайте" или "Лид-форма сломалась" не дают разработчику четкого понимания проблемы. Их нужно лаколично детализировать. 

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

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

• Описание нескольких багов в одном репорте. Во время баг-репортинга очень важно уметь отделять одну проблему от другой и соблюдать принцип “один баг – один репорт”. 

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

По своему опыту мы можем сказать, что создание качественных баг-репортов – навык, который нужно нарабатывать в коммуникации с разработчиками. Приведем пару примеров:

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

Автоматизация процесса создания баг репортов

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

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

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

Помимо интеграции с фреймворками существуют отдельные инструменты и плагины, которые помогают автоматизировать сбор материалов для баг-репортов: логов, скриншотов, видео и т.д.:

• Allure, TestRail, ReportPortal - для визуализации и хранения результатов автоматизированных тестов;

• Sentry, Bugsnag, Firebase Crashlytics - для автоматического логирования ошибок в продакшне;

• Loom, Monosnap, Lightshot – для записи видео или быстрых скриншотов, которые легко можно добавить в репорт.

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

Роль баг-репортов в команде разработки

Баг-репорты – это не просто отчеты об ошибках. На сегодня они стали ключевым инструментом коммуникации между QA и разработчиками, который влияет на скорость и качество устранения дефектов. Хорошо написанный репорт позволяет девелоперу быстро воспроизвести ошибку, понять ее контекст и найти оптимальное решение с минимальными усилиями.

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

Качественный баг-репортинг оказывает непосредственное влияние на скорость устранения ошибок (bug fixing time), с соответствующими последствиями для всего проекта. Как показал опрос Cambridge University Judge Business School, 41% разработчиков назвал сложности с воспроизведением дефекта наибольшим препятствием для быстрого устранения багов. В итоге баги, которые не могут быть ликвидированы оперативно, откладываются "на потом". И, как известно, стоимость исправления дефекта в коде растет экспоненциально: устранение проблемы на этапе тестирования стоит в разы дешевле, чем ликвидация бага уже в продакшене 

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

Баг-репорт в контексте Agile и Scrum

В практиках Agile-разработки баги документируются сразу, как только они обнаружены. В этом очень помогает баг трекинг система (например, Jira). Проблемы также могут фиксироваться непосредственно в беклоге продукта. В идеале дефект фиксируется еще при разработке или тестировании в пределах текущего спринта: это позволяет не терять контекст и реагировать быстро.

В методологии Scrum баги обычно документируются как отдельные элементы бэклога продукта (Product Backlog Items) или как подзадачи (sub-tasks) к существующим пользовательским историям (User Stories).

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

• Где? Если баг связан с функциональностью, над которой команда работает сейчас (т.е. в текущем спринте), она может быть добавлена как подзадача к соответствующей User Story. Это позволяет команде видеть весь обьем работ, связанных с конкретной функциональностью. Если же баг найден в уже выпущенной функциональности, или в старой части системы, он может быть добавлен к общему беклогу продукта как отдельный элемент.

Приоритизация дефектов в Scrum осуществляется во время встреч по планированию спринта (Sprint Planning) и во время постоянных обсуждений бэклога продукта (Backlog Refinement).

За приоритизацию отвечает Product Owner (владелец продукта), который оценивает влияние выявленных дефектов на бизнес, учитывая серьезность (Severity), определенный специалистами приоритет (Priority) и тому подобное. 

Таким образом, в Scrum баг-репорты интегрированы в общий поток работы, а их исправление является частью постоянного процесса доставки ценности пользователю. На практике некоторые команды все же выделяют отдельный спринт для багов (bug sprint), особенно если дефектов много. Но это исключение, а не правило.

Как писать полезные баг-репорты? 

Мы не отважимся называть создание баг-репортов искусством, ведь оно не дает автору пространства для самовыражения. Но для создания по-настоящему полезного отчета нужно овладеть умением увидеть суть проблемы и разложить ее “на атомы” – чтобы понять ее мог любой. Если вы стремитесь стать мастером баг-репортов, попробуйте практиковать следующее: 

1. Всегда проверяйте воспроизводимость. Попытайтесь воспроизвести баг несколько раз самостоятельно, меняя среду и последовательность шагов;
2. Читайте репорты глазами разработчика. Посмотрите на свой баг-репорт в “джира” чужими глазами. Вы бы смогли сами понять, в чем проблема?
3. Изучайте "плохие" и "хорошие" отчеты: Каждый пример баг репорта чем-то полезен. Даже неудачные отчеты дают вам ценный опыт того, как писать не нужно;
4. Ищите фидбек. Попросите разработчиков или опытных тестировщиков оценить ваши отчеты.
5. Будьте лаконичны, но содержательны. Ваш отчет должен быть сжатым, но при этом информативным и самодостаточным.
6. Автоматизируйте сбор доказательств. Широко используйте плагины и инструменты для скриншотов, видео и логов.

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