Сообщить о баге что это

Как правильно оформить баг-репорт

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

• воспроизвести проблему;
• понять, в чем проблема, и какова ее важность.

Что такое баг, типы багов

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

Критичность и приоритет бага. Атрибуты баг-репорта

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

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

По критичности баги делят на:

S1. Блокирующий (Blocker). Всё тестируемое ПО не может работать без устранения бага. Например, приёмник начинает перезагружаться сразу после включения, мы не сможем больше ничего протестировать из-за этого бага.

S2. Критический (Critical). Большая часть ПО не может корректно работать. Например, приёмник не может открывать закодированные каналы. До устранения этого дефекта можно протестировать UI, а также функционал, не связанный с расшифровыванием каналов.

S3. Значительный (Major). Блокирует работу одной из основных логических цепочек ПО. Например, неправильное сообщение об ошибке при отсутствии подписки на пакет оператора.

S4. Незначительный (Minor). Не нарушает основные логические цепочки приложения, с ним можно продолжать работать почти без потери качества. Здесь можно привести неточный перевод с русского на английский в меню приёмника.

S5. Тривиальный (Trivial). Эта степень присваивается, когда баг вообще не влияет на общее качество работы ПО. Например, незначительное пересечение элементов в меню.

Приоритет бага — это то, в каком порядке нужно решать проблемы. Существует три степени приоритетности:

P1. Высокий приоритет (High). Нужно исправить немедленно, потому что баг является крайне важным для всего релиза. Например, старое сообщение об отсутствии подписки на пакет, хотя обновление текстов являлось целью этого релиза.

P2. Средний приоритет (Medium). Точно нужно будет исправить, баг достаточно важен, но не требует немедленного решения. Например, некорректный перевод в меню приёмника.

P3. Низкий приоритет (Low). Нужно будет исправить, но баг не очень важный и не требует немедленного решения. Например, это могут быть баги в функционале, который уже не используется оператором, но ещё не был удалён из кода.

Что такое баг репорт, его типичная структура

Глоссарий ISTQB говорит, что баг репорт — это документ, содержащий отчет о любом недостатке в компоненте или системе, который может привести компонент или систему к невозможности выполнить требуемую функцию.

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

Состав баг репорта приведен в таблице:

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

Название тестируемого проекта

Компонент приложения (Component)

Название части или функции тестируемого продукта

Номер версии (Version)

Версия, на которой была найдена ошибка

Наиболее распространена пятиуровневая система критичности:

S1 Блокирующий (Blocker)

S2 Критический (Critical)

S3 Значительный (Major)

S4 Незначительный (Minor)

S5 Тривиальный (Trivial)

P1 Высокий (High)

P2 Средний (Medium)

Статус бага. Зависит от используемой процедуры и жизненного цикла бага. Например:

Назначен на (Assigned To)

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

Информация об окружении, на котором был найден баг: операционная система, сервис пак, имя и версия браузера, версия ПО чипа, версия библиотеки и т.д.

Шаги, по которым можно легко воспроизвести ситуацию, приведшую к ошибке.

Прикрепленный файл (Attachment)

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

Как правильно оформить баг-репорт

1. Для начала нужно убедиться, что найденный баг ещё не был оформлен. Следует провести поиск его в соответствующем проекте по всем подходящим ключевым словам и\или полям. Если баг уже есть, следует обновить его описание.
2. Если баг не найден — нажимаем на кнопку создания бага. Не стоит забывать важное правило: один дефект — один баг в трекере.
3. Далее нужно постараться кратко описать, что не работает — это и будет заголовок баг-репорта.
4. После этого перейти к подробному описанию бага: указать шаги к воспроизведению.
5. Указать ожидаемый результат. Можно добавить ссылку на спецификацию.
6. Указать полученный результат.
7. Указать версию ПО, также указать версию окружения.
8. Если необходимо, приложить соответствующие артефакты: логи, скриншоты, дампы и т.д.

Ошибки при создании баг-репорта

Здесь перечислим проблемы, которые чаще всего встречаются при написании баг репорта.

Заголовок не понятен. Есть риск, что ни разработчик, ни коллеги не обратят внимания на довольно критичную проблему.

Отсутствуют шаги для воспроизведения. Есть риск, что разработчик, не поняв как повторить проблему, вернёт баг со статусом «Не воспроизводится».

Неправильно назначен баг. Возможно, баг по ошибке был назначен не на того разработчика или вообще остался в статусе «не назначен». Есть риск, что багу долгое время не будет уделено внимание.

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

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

Жизненный цикл бага

Итак, баг найден, репорт составлен, что дальше? Дальше ведётся работа над багом в соответствии с жизненным циклом, который может быть настроен в системе багтрекинга. На практике это зависит от процессов в компании.

Если кратко, то после создания баг-репорта статус бага может выглядеть следующим образом:

• Новый (New). Тестировщик нашел баг, дефект успешно занесен в «Bug-tracking» систему.
• Открыт (Opened). После того, как тестировщик отправил ошибку, она либо автоматически, либо вручную назначается на человека, который должен её проанализировать. В зависимости от решения, баг может быть:
• Отложен (Postponed). Исправление бага отложено, т.к. он не является критичным на данном этапе разработки или по другим причинам.
• Отклонен (Rejected). По разным причинам дефект может и не считаться таковым, что вынуждает отклонить его. Не баг, а фича.
• Дубликат (Duplicate). Если описанная ошибка уже ранее была внесена в «Bug-tracking» систему.
• Назначен (Assigned). Если ошибка актуальна и должна быть исправлена в следующей сборке (build), происходит назначение на разработчика, который должен исправить ошибку.
• Исправлено (Fixed). Ответственный за исправление бага разработчик заявляет, что устранил дефект.
• Проверен (Verified). Тестировщик проверяет, действительно ли ответственный разработчик исправил дефект. Если бага больше нет, он получает данный статус.
• Повторно открыт (Reopened). Если опасения тестировщика оправданы, и баг в новом билде не исправлен — он все так же потребует исправления, поэтому вновь открывается.
• Закрытый (Closed). В результате определенного количества перепроверок баг все-таки окончательно устранен и больше не потребует внимания команды — он объявляется закрытым.

Более наглядно жизненный цикл бага можно посмотреть на диаграмме:

При использовании системы тест менеджмента TestIT существует возможность интеграции с системами баг-трекинга. В нашей компании это JIRA. Достаточно нажать «save and create bug» и мы получаем почти готовый баг репорт в JIRA.

Нужно только добавить несколько полей связанных с текущим проектом.

В разделе Description уже есть разделы steps, actual result and expected result, что особенно актуально для начинающих тестировщиков и позволит им не пропустить важные разделы в баг репорте.

Вместо заключения

Если ваш баг-репорт составлен правильно, то шансы на быстрое исправление этих багов выше. Таким образом, исправление ошибки зависит от того, насколько качественно вы о ней сообщите. Смысл написания баг-репорта состоит в том, чтобы устранять проблемы. Составление правильных баг-репортов — не что иное, как навык, и его необходимо сформировать.

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

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

Была ли статья полезной?

Как правильно сообщать о багах

Давайте поговорим о том, как тестировщику правильно сообщить о баге. Или, как еще говорят — репортить баги.

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

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

Заголовок бага

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

В первую очередь стоит руководствоваться простой мнемоникой “что, где, когда”. Сначала надо написать «что» сломалось, а уже потом «в каком месте» и «при каких условиях».

Например, название “сломалась оплата” — плохое. Не ясно где именно произошла ошибка и насколько она критична. Разработчику потребуется дополнительное время, чтобы зайти в задачу и выяснить это.

Хороший пример выглядит так: “Ошибка “Сервер недоступен” в корзине при нажатии кнопки “Оплата через Paypal”.

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

Плохо: “Некорректно работает форма логина”

Хорошо: “Ошибка “Пользователь не найден” при вводе email в качестве логина”.

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

Описание

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

Опционально можно добавить дополнительные файлы (логи и скриншоты), версию продукта, окружение (версию ОС, браузеров, конкретные девайсы).

Выглядит хорошее описание примерно вот так:

Платформа: Pixel 3 XL, Android 9.0
Версия приложения: 1.5.1
Шаги:
— Открыть приложение
— Авторизоваться
— Открыть вкладку “профиль”
— Ввести в поле “имя” значение “Олег”
— Нажать на кнопку сохранить
Фактический результат: выдается сообщение “такое имя уже есть”
Ожидаемый результат: имя сохраняется

Лог приложения: bug_login.txt
Скриншот: screen.jpg

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

А если хотите узнать больше о том, как искать баги, оформлять их и многое другое из практик тестировщика, приходите на наш курс Тестировщик: первая ступень. Он будет интересен как тем, кто только думает попробовать себя в качестве тестировщика, так и тем, кто уже какое-то время работает в профессии и хочет систематизировать свои знания.

Что такое баг репорт: основы и назначение

Баг репорт — неотъемлемая часть тестирования, помогающая устранять ошибки и улучшать продукт.

Алексей Кодов
Автор статьи
27 сентября 2023 в 8:38

Баг репорт (bug report) — ключевой элемент в процессе тестирования, который помогает команде программистов устранить ошибки и улучшить качество продукта. Это документ, который содержит всю информацию о найденной ошибке: от ее описания до шагов для воспроизведения. Более подробно о том, как создать такой документ, вы можете прочитать в статье Как создать баг-репорт. Но сначала давайте разберемся, что такое баг репорт и для чего он нужен.

Назначение баг-репорта ��

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

Основные элементы баг-репорта ��

Баг-репорт состоит из нескольких ключевых элементов:

1. Идентификатор бага (ID)
2. Название бага
3. Описание бага
4. Шаги для воспроизведения
5. Ожидаемый результат
6. Фактический результат
7. Приоритет и серьезность бага

В более подробном обзоре этих элементов можно ознакомиться в статье Как составить и оформить баг-репорт.

Создание баг-репорта ��️

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

Заключение

Баг-репорт — это неотъемлемый инструмент в работе тестировщика. Понимание его сути и назначения поможет вам стать более профессиональным и востребованным специалистом. Если вам интересно узнать больше и практиковаться в создании баг-репортов, рекомендуем пройти курс по «Тестирование» в онлайн-университете Skypro. Подробности можно найти здесь.

И помните, что понимание баг-репорта идет в связке с пониманием основ программирования. Например, важно знать о таком понятии как парадигмы программирования.

Что такое баг-репорт и как его составить

О чем речь? Баг-репорт – отчет об ошибках. Составляется в основном для документирования промахов разработчиков. Отчет нужен для выявления виновных и исправления багов. Если сообщать об ошибке лично, то разработчик может либо забыть, либо понадеяться на своих коллег, которые ничего не исправят.

Как? У баг-репорта нет установленной структуры, поэтому каждый вправе разрабатывать документ по своему усмотрению. Однако некоторые разделы в нем должны быть обязательны. Также важно помнить, что это технический отчет, а значит, в нем не место художественному тексту.

В статье рассказывается:

1. Что такое баг-репорт
2. Откуда берутся баги
3. Виды багов
4. Степени серьезности и приоритетов в баг-репортах
5. Шаблон баг-репорта
6. Как оформить баг-репорт
7. Типичные ошибки в баг-репорте
8. Советы по заполнению баг-репорта
9. Часто задаваемые вопросы о баг-репорте

Пройди тест и узнай, какая сфера тебе подходит:
айти, дизайн или маркетинг.
Бесплатно от Geekbrains

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

Баг-репорт (bug report) представляет собой технический документ, в котором указывается информация об ошибке в работе программного обеспечения. Его заполнением занимается тестировщик. Затем документ отправляется разработчикам, чтобы они исправили имеющиеся недочеты.

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

Откуда берутся баги

Баг – это некорректная работа ПО. Причиной является ошибка в коде, которую допустил разработчик в процессе его написания.

Узнай, какие ИТ — профессии
входят в ТОП-30 с доходом
от 210 000 ₽/мес
Павел Симонов
Исполнительный директор Geekbrains

Команда GeekBrains совместно с международными специалистами по развитию карьеры подготовили материалы, которые помогут вам начать путь к профессии мечты.

Подборка содержит только самые востребованные и высокооплачиваемые специальности и направления в IT-сфере. 86% наших учеников с помощью данных материалов определились с карьерной целью на ближайшее будущее!

Скачивайте и используйте уже сегодня:

Павел Симонов
Исполнительный директор Geekbrains

Топ-30 самых востребованных и высокооплачиваемых профессий 2023

Поможет разобраться в актуальной ситуации на рынке труда

Подборка 50+ бесплатных нейросетей для упрощения работы и увеличения заработка

Только проверенные нейросети с доступом из России и свободным использованием

ТОП-100 площадок для поиска работы от GeekBrains

Список проверенных ресурсов реальных вакансий с доходом от 210 000 ₽

Получить подборку бесплатно
Уже скачали 25510

Это может произойти из-за:

• попыток уложиться в сжатые сроки;
• стресса;
• усталости;
• недомогания;
• проблем с коммуникациями внутри команды;
• непонимания техзадания;
• отсутствия необходимых знаний у специалиста;
• проблем, связанных с концентрацией внимания;
• недостатка документации или иной информации о проекте;
• высокой сложности программы;

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

Виды багов

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

• Визуальные. Они относятся к интерфейсу ПО. К примеру, кнопка «Оформить заказ» отображается за пределами экрана.
• Функциональные. К примеру, человек жмет на кнопку «Оформить заказ», но приложение никак на это не реагирует. Еще одна частая проблема – пользователи применяют одноразовые купоны на скидку по несколько раз.
• Дефект UX. Такая ошибка делает работу с ПО менее удобной. К примеру, для подтверждения номера телефона человеку нужно несколько раз закрыть и открыть приложение.
• Баг нагрузки. В интернет-магазин будет заходить множество пользователей. Особенно это касается праздничных дней и других примечательных дат. Например, так называемая Черная пятница. Во избежание проблем необходимо провести нагрузочное тестирование. Можно смоделировать ситуацию, при которой один раздел одновременно открывают несколько тысяч пользователей. Если ПО начнёт тормозить, то тестировщик должен сообщить о баге нагрузки.
• Баг производительности. К примеру, приложение занимает слишком много места в памяти мобильного устройства, медленно функционирует или быстро расходует заряд батареи.
• Баг требований, или логический баг. Как правило, такие ошибки возникают в том случае, если до начала разработки ПО или отдельной «фичи» в требованиях было что-то упущено. К примеру, не добавили всплывающее оповещение, что при включенном VPN ПО может работать с ошибками. Разработчик написал код так, как было указано в требованиях. В результате программа функционирует согласно ТЗ, но не так, как хочется заказчику.

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

Степени серьезности и приоритетов в баг-репортах

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

Есть пять базовых степеней серьезности:

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

Для вас подарок! В свободном доступе до 14.01 —>
Скачайте ТОП-10
бесплатных нейросетей
для программирования
Помогут писать код быстрее на 25%
Чтобы получить подарок, заполните информацию в открывшемся окне

Существует также показатель степени приоритета. От него зависит порядок решения проблем с ПО. Перечислим их:

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

Стоит учесть, что степень серьезности бага определяет степень его приоритета.

Шаблон баг-репорта

Рассмотрим важнейшие атрибуты баг-репорта:

Название поля	Что содержит
Заголовок	В краткой форме рассматривается суть проблемы. При этом заголовок должен быть понятным.
Описание	Как правило, повторяет заголовок баг-репорта, так что это поле иногда пропускают.
Шаги воспроизведения	Перечисление действий, которые необходимо выполнить, чтобы произошел баг.
Фактический результат	Что происходит во время бага.
Ожидаемый результат	Что должно было произойти вместо бага.
Окружение	Где находится баг. К примеру, ОС, браузер или тестовая среда.
Вложения	Логи, скриншоты
Дополнительная информация	В этом поле могут быть указаны пояснения от тестировщика (что он еще делал для воспроизведения бага, и каковы были результаты).

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

Как оформить баг-репорт

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

Как же составить баг-репорт? Рассмотрим несколько важных нюансов, которые необходимо учесть начинающему тестировщику:

• Размер заголовка. Эта часть баг-репорта помогает разработчику быстро понять суть проблемы. Заголовок не должен быть слишком длинным или коротким.
• Локализация. Тестировщик должен не просто найти баг, но еще и правильно его описать. В противном случае разработчики будут решать проблему, которая не имеет никакого отношения к их обязанностям.
• Вложения. Если баг визуальный или UX (к примеру, нашлась некорректная вёрстка или не функционирует кнопка), то для наглядности необходимо сделать скриншоты. Так разработчик поймет, что видит пользователь при возникновении ошибки.
• Шаги воспроизведения. Не стоит начинать с этапа«Включить компьютер». При этом шаги должны быть описаны максимально точно, без размытых формулировок. К примеру, «нажать кнопку “Начать”, сканировать любой товар из задачи».
• Взгляд на проблему. Специалист должен поставить себя на место заказчика. К примеру, если текст не помещается в поле, то такая ошибка мешает бизнесу? Это необходимо, чтобы правильно оценить серьезность и приоритет дефекта.
• Фактический и ожидаемый результаты. Если тестировщик опишет проблему непонятно, то разработчику придется задать ему уточняющие вопросы. К примеру, фактически результат— кнопка не работает, а ожидаемый результат — кнопка работает. Такое описание не дает разработчику никакого понимания сути проблемы.

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

Обычно после того как баг был обнаружен, он попадает на стадию «Новый». Когда все работы по исправлению будут завершены, он получит статус «Закрытый».

Однако между этими стадиями есть еще четыре промежуточных этапа, к которым может быть отнесен баг:

• Отклонен. Эта стадия нужна для багов, которые не получилось воспроизвести из-за неточностей в «Шагах воспроизведения» или повторном попадании дефекта в категорию «Новый». Кроме того, баг может быть отклонен в том случае, если его исправление разрешается перенести на более позднюю дату.
• Открыт. Если баг требуется исправить в кратчайшие сроки.
• Исправлен. Сюда относят уже исправленные ошибки.
• Переоткрыт. Если ранее баг был отсрочен или отклонен, но потом решение поменялось.

Дарим скидку от 60%
на курсы от GeekBrains до 14 января
Уже через 9 месяцев сможете устроиться на работу с доходом от 150 000 рублей

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

Типичные ошибки в баг-репорте

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

• Неправильно составлен заголовок. Он должен отвечать на вопросы «Что? Где? Когда?».
• В заголовке есть лишние сведения (версии, окружения, учетные данные пользователей и т. п.).
• Слишком подробно описаны шаги для воспроизведения.
• Нет фактического и / или ожидаемого результата.
• Нет ссылки на требование, которое проверялось (при наличии).
• Нет скриншота / видеозаписи для UI/UX багов. Либо на скриншоте не выделен дефект.
• Допущены грамматические ошибки.
• Техническая безграмотность.
• Использование «жаргона».

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

Советы по заполнению баг-репорта

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

• Следует выявлять причину возникновения ошибки. К примеру, если на веб-сайте не удается восстановить пароль, то проблема может иметь разные корни: бэкенд или фронтенд. Тестировщику необходимо выявить истинную причину бага, чтобы команда разработчиков четко понимала, кто должен заниматься исправлением.
• Лучше выполнять тестирование на разных устройствах. Если баг был обнаружен в десктоп-версии, то он может возникнуть и на смартфонах.
• Необходимо выполнять тестирование в разных версиях ПО. При составлении баг-репорта нужно учитывать, что ошибка может не обнаруживаться на старой версии ПО, однако в обновлении она все же есть.
• Нужно описать несоответствия между ожидаемым результатом и фактическим. Для этого необходимо ознакомиться с технической документацией и техзаданием.

Часто задаваемые вопросы о баг-репорте

Как правильно описать баг?

Начинающий специалист должен задаваться главным вопросом «Что, если?». Чем больше гипотез формирует и проверяет тестировщик, тем лучше.

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

Что делать тестировщику, если он нашел слишком много ошибок?

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

Перечислим примеры метрик:

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

Только до 11.01
Скачай подборку материалов, чтобы гарантированно найти работу в IT за 14 дней
Список документов:

ТОП-100 площадок для поиска работы от GeekBrains

20 профессий 2023 года, с доходом от 150 000 рублей

Чек-лист «Как успешно пройти собеседование»

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

Почему баг-репорты составляют не во всех компаниях?

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

Баг-репорт сайта или ПО представляет собой очень важный документ, который позволяет разработчикам понять, что и где нужно исправить. За его составление отвечает тестировщик. Этот специалист должен иметь определенные знания и навыки в данной сфере, чтобы выявлять все недочеты ПО и правильно оформлять их в репорте.