Как сообщить команде о баге
Перейти к содержимому

Как сообщить команде о баге

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

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

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

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

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

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

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

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

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

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

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

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

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

Описание

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

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

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

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

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

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

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

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

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

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

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

По версии международной комиссии по сертификации тестирования программного обеспечения (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, что особенно актуально для начинающих тестировщиков и позволит им не пропустить важные разделы в баг репорте.

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

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

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

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

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

Основы тестирования. Как правильно составить баг-репорты

armen-mailyan

07.08.2019

15524

Рейтинг: 5 . Проголосовало: 4
Вы проголосовали:
Для голосования нужно авторизироваться

advertisement advertisement

  1. Зачем нужен хороший баг-репорт?
  2. Каковы качества хорошего баг-репорта в разработке программного обеспечения?
  3. Характеристики и методы для сообщения о баге
  4. Эффективный баг-репортинг
  5. Простой шаблон баг-репорта
  6. Важные фичи в отчете об ошибках
    1. Номер ошибки/идентификатор
    2. Наименование ошибки
    3. Приоритет
    4. Платформа/среда
    5. Описание
    6. Шаги для воспроизведения ошибки
    7. Ожидаемый и фактический результат
    8. Скриншот

    Зачем нужен хороший баг-репорт?

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

    «Смысл написания отчета о проблемах (баг-репорта) состоит в том, чтобы исправить эти проблемы» — Cem Kaner. Если тестировщик не сообщает об ошибке правильно, программист, скорее всего, отклонит эту ошибку, заявив, что она невоспроизводима.

    Это может повредить рабочему настрою тестировщиков, затронуть их профессиональную гордость, их эго.

    Каковы качества хорошего баг-репорта в разработке программного обеспечения?

    Любой может составить пример баг репорта. Но не каждый может написать эффективный баг-репорт.

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

    advertisement advertisement

    Характеристики и методы включают в себя:

    1) Наличие четко определенного номера ошибки:

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

    2) Воспроизводимость:

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

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

    3) Будьте конкретны:

    Не пишите очерк о проблеме.

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

    Эффективный баг-репортинг

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

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

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

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

    Тема связана со специальностями:

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

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

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

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

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

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

    Как сообщить об ошибке?

    Используйте следующий простой баг репорт шаблон:

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

    Составитель отчета: Ваше имя и адрес электронной почты.

    Продукт: В каком продукте вы нашли эту ошибку.

    Версия: Версия продукта с ошибкой, если таковая имеется.

    Компонент: Основные подмодули продукта.

    Платформа:

    Укажите аппаратную платформу, на которой вы обнаружили эту ошибку. Различные платформы, такие как «ПК», «MAC», «HP», «Sun» и т. д.

    Операционная система:

    Укажите все операционные системы, в которых вы обнаружили ошибку. Операционные системы, такие как Windows, Linux, Unix, SunOS, Mac OS. Упомяните разные версии ОС, такие как Windows NT, Windows 2000, Windows XP и т. д., если это применимо.

    Приоритет:

    Когда следует исправлять ошибку? Приоритет обычно устанавливается от P1 до P5. P1 следует понимать, как «исправить ошибку с наивысшим приоритетом» и P5 — «исправить, если позволяет время».

    Серьезность ошибки:

    Описывает влияние ошибки.

    Типы Серьезности ошибки:

    • Блокировщик (Blocker): дальнейшая работа по тестированию невозможна.
    • Критическая (Critical): сбой приложения, потеря данных.
    • Major: серьезная потеря функциональности.
    • Minor: незначительная потеря функциональности.
    • Незначительная (Trivial): некоторые улучшения пользовательского интерфейса.
    • Улучшение (Enhancement): запрос новой функции или некоторого улучшения существующей.

    Статус ошибки:

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

    Позднее ошибка проходит через различные этапы, такие как «Исправлено», «Проверено», «Повторно открыто», «Не исправлено» и т. д.

    Назначить разработчику:

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

    URL:

    URL страницы, на которой произошла ошибка.

    Краткое резюме:

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

    Описание:

    Подробное описание ошибки.

    Используйте следующие поля для поля описания:

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

    Видео курсы по схожей тематике:

    Тестирование безопасности веб-приложений

    Тестирование безопасности веб-приложений

    SQL Базовый

    TDD - Разработка через тестирование

    TDD — Разработка через тестирование

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

    Типы отчетов включают в себя:

    1) Ошибка в коде
    2) Ошибка проектирования
    3) Новое предложение
    4) Проблема с документацией
    5) Аппаратная проблема

    Важные фичи в вашем отчете об ошибках

    Рассмотрим несколько составляющих отчета о найденном баге

    Ниже приведены важные элементы баг-репорта:

    1) Номер ошибки/идентификатор:

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

    2) Наименование ошибки:

    Заголовок ошибки читается чаще, чем любая другая часть баг-репорта. Стоит указать в нем всё о том, что входит в баг.

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

    3) Приоритет:

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

    4) Платформа / Среда:

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

    5) Описание:

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

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

    6) Шаги для воспроизведения ошибки:

    Хороший отчет об ошибке должен четко указывать шаги для воспроизведения. Шаги должны включать действия, которые вызывают ошибку. Не делайте общих заявлений. Будьте конкретны в следующих шагах.

    Хороший пример правильно написанной пошаговой процедуры приведен ниже:

    Последовательность шагов:

    • Выберите продукт wer05.
    • Нажмите на «Добавить в корзину».
    • Нажмите «Удалить», чтобы удалить продукт из корзины.

    7) Ожидаемый и фактический результат:

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

    8) Скриншот:

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

    Некоторые дополнительные советы для написания хорошего баг-репорта

    Ниже приведены некоторые дополнительные советы, чтобы написать хороший отчет об ошибке:

    1) Немедленно сообщите о проблеме:

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

    2) Воспроизведите ошибку три раза перед написанием баг-репорта:

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

    3) Протестируйте эту же ошибку на других похожих модулях:

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

    4) Составьте хорошее резюме ошибки:

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

    5) Прочитайте несколько раз отчет об ошибке, прежде чем нажать кнопку «Отправить»:

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

    Бесплатные вебинары по схожей тематике:

    Кто есть кто в IT компании. Структуры и роли

    Кто есть кто в IT компании. Структуры и роли

    Сложность алгоритмов и методы оптимизации программ

    Сложность алгоритмов и методы оптимизации программ

    Программист или тестировщик? Какую профессию лучше выбрать

    Программист или тестировщик? Какую профессию лучше выбрать

    6) Не используйте оскорбительные выражения:

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

    Заключение

    Что такое баги? Это несовершенства ПО, с которыми необходимо бороться, и один из главных помощников в этом – репорты об ошибках.

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

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

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

    С нашей стороны для качественной подготовки тестировщиков, предлагаем вам ознакомиться с курсом подготовки специалиста-тестировщика на ITVDN — Quality Assurance

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

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

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

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

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

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

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

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

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

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

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

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

    Заключение

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

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

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *