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

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

07.08.2019

15106

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

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

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

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

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

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

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

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

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

   

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

   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 слов или меньше. Убедитесь, что составленное резюме отражает проблему и место, где она находится.

   Описание:

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

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

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

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

   

   

   

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

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

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

   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

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

   

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

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

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

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

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

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

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

   Хороший пример выглядит так: “Ошибка “Сервер недоступен” в корзине при нажатии кнопки “Оплата через 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, что особенно актуально для начинающих тестировщиков и позволит им не пропустить важные разделы в баг репорте.

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

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

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

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

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

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

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

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

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

   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 ₽

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

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

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

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

   Виды багов

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

   

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

   

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

   

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

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

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

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

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

   Похожие публикации:

   1. Как перенести базу данных postgresql на другой компьютер
   2. Как удалить teamviewer
   3. Яндекс авто что такое
   4. A9a9a9 какой цвет