Отчеты об ошибках являются неотъемлемой частью тестирования программного обеспечения, поскольку они помогают выявлять и документировать любые проблемы, возникающие в процессе работы. Используя отчет об ошибках, тестировщики могут отслеживать ход выполнения своей работы и сравнивать результаты с течением времени. Это позволяет им при необходимости вносить изменения в планы и стратегии тестирования.
Конечной целью любого тестирования является поиск как можно большего количества ошибок – как при ручном тестировании, так и при автоматизированном. К тому же, отчеты об ошибках предоставляют разработчикам подробную информацию о том, как воспроизвести ту или иную проблему, что помогает им быстро найти и устранить ее. Более того, систематическое документирование всех ошибок позволяет командам легко отслеживать ход выполнения проектов и выявлять области, в которые необходимо внести улучшения.
В этом пособии мы рассмотрим все моменты, связанные с составлением отчета об ошибке, а также то, как можно сделать его максимально эффективным.
БЕСПЛАТНО СКАЧАТЬ КНИГИ в телеграм канале "Библиотека тестировщика"
Содержание:
- Что такое отчет об ошибках/дефектах?
- Преимущества хорошего отчета об ошибках
- Как сообщить об ошибке?
- Как написать отчет об ошибке?
- Предоставьте всю необходимую информацию
- Сообщайте о воспроизводимых ошибках
- Будьте краткими и четкими
- Сообщайте об ошибках на ранней стадии
- Избегайте орфографических и языковых ошибок
- Документирование плавающих багов
- Избегайте дублирования ошибок
- Создавайте отдельные отчеты для несвязанных проблем
- Не используйте авторитарный тон
- Основные характеристики отчета об ошибке
- Заключение
- Часто задаваемые вопросы
Что такое отчет об ошибке/дефекте?
Отчет об ошибке (баг-репорт) – это документ, содержащий информацию о сбое или неисправности программного или аппаратного обеспечения. Как правило, он содержит такие сведения, как шаги, необходимые для воспроизведения проблемы, ожидаемое и фактическое поведение программы. Основная цель отчета об ошибке – предоставить команде разработчиков точное описание проблемы, чтобы облегчить ее решение. Баг-репорты должны быть четкими, краткими и корректными, чтобы помочь разработчикам понять проблему и быстро ее устранить. Все ошибки должны быть задокументированы в специальных баг-трекинговых системах для их своевременного выявления, определения приоритетов и устранения. В противном случае разработчик может не понять или проигнорировать проблему, а руководство не осознать ее серьезность и оставить ее в производстве до тех пор, пока клиенты не сообщат им о ней.
Преимущества хорошего отчета об ошибках
Хороший отчет об ошибке должен содержать четкую и подробную информацию о проблеме, позволяющую команде разработчиков понять и воспроизвести ее. В нем должны содержаться такие сведения, как краткое описание проблемы, шаги, предпринятые для ее воспроизведения, ожидаемое и фактические поведение ПО, скриншоты или видеозаписи, подтверждающие наличие проблемы, конфигурация устройства и другие необходимые данные. Такая информация позволяет более эффективно решить проблему.
- Отчет помогает точно определить причину ошибки и найти оптимальный способ ее устранения.
- Экономит время и деньги, помогая выявить ошибку до того, как она станет еще серьезнее.
- Не дает ошибкам попасть в конечный продукт и испортить пользовательский опыт.
- Помогает избежать повторного появления той же ошибки в будущих версиях.
- Все участники процесса будут проинформированы об ошибке и смогут что-то предпринять.
Как сообщить об ошибке?
Эффективное сообщение об ошибке необходимо команде разработчиков для оперативного и точного решения проблемы. Хорошо составленный отчет должен быть кратким, информативным и понятным. Для отправки сообщения об ошибке можно выполнить следующие действия:
- Попытаться последовательно и систематически воспроизвести ошибку.
- Собрать данные о среде, такие как тип браузера, операционная система, версии используемого программного обеспечения.
- Составить четкие инструкции по воспроизведению ошибки (шаги).
- Приложить скриншоты или видеоролики, которые могут помочь продемонстрировать проблему разработчикам.
- Сформулировать, какой результат ожидался, и чем он отличается от того, что произошло в действительности.
- Указать степень серьезности и приоритет устранения ошибки. Описать, как ошибка влияет на функциональность программного обеспечения, и определить степень срочности ее исправления.
- Проверить наличие дубликатов: изучить баг-трекинговую систему, чтобы выяснить, не сообщалось ли уже об этой ошибке ранее.
- Назначить ошибку соответствующему разработчику или команде и проследить за ее устранением.
- Отслеживать ход работы над ошибкой, чтобы убедиться в том, что она устраняется, и предоставлять любую дополнительную информацию, которая может потребоваться.
Как написать отчет об ошибке?
Как уже говорилось ранее, хороший отчет об ошибке должен помочь разработчику и руководству понять суть проблемы. Для его составления необходимо учитывать следующие рекомендации:
1. Предоставьте всю необходимую информацию
Для описания ошибки следует использовать простые, лаконичные предложения. Эксперты-тестировщики считают составление отчетов об ошибках не чем иным, как навыком. Надеемся, что данное руководство поможет вам лучше овладеть им.
2. Сообщайте о воспроизводимых ошибках
Сообщая об ошибке, тестировщик должен убедиться, что она воспроизводима. Обязательно нужно указать подробные шаги по воспроизведению ошибки. К баг-репорту следует добавить все предпосылки для выполнения шагов и все тестовые данные в деталях.
3. Будьте краткими и четкими
Постарайтесь изложить суть вопроса в нескольких словах, кратко, но исчерпывающе. Избегайте длинных запутанных текстов.
Описывайте ошибку указателями и избегайте абзацев. Важно предоставить всю необходимую информацию, это поможет разработчикам разобраться в проблеме без каких-либо дополнительных сведений. Разработчик должен четко понимать ее суть, лежащей в основе сообщения об ошибке.
4. Сообщайте об ошибках на ранней стадии
Важно сообщать об ошибках, как только вы их обнаружите. Заблаговременное сообщение об ошибке поможет команде исправить ее на раннем этапе и и выпустить продукт раньше срока.
5. Избегайте орфографических и языковых ошибок
Тщательно проверьте все предложения в отчете на наличие орфографических и грамматических ошибок.
При необходимости можно использовать сторонние онлайн-инструменты. Это поможет разработчику понять ошибку без двусмысленностей и искажений.
6. Документируйте плавающие баги
Иногда не все ошибки воспроизводятся. Например, иногда мобильное приложение выходит из строя, и необходимо перезапустить его, чтобы продолжить работу. Такие ошибок не воспроизводятся каждый раз.
Тестировщики в таких сценариях должны попытаться снять видеозапись ошибки и приложить ее к отчету. Зачастую видеоролик оказывается более полезным, чем снимок экрана, поскольку он содержит подробную информацию о шагах, которые сложно документировать.
7. Избегайте дублирования ошибок
Отправляя баг-репорт, необходимо убедиться, что он не дублирует уже выявленную ранее ошибку. Кроме того, перед тем как приступить к составлению отчета, проверьте список известных и открытых на данный момент проблем. Дублирующие сообщения об ошибках могут стоить дублирования усилий разработчиков, что негативно скажется на жизненном цикле тестирования в целом.
8. Создавайте отдельные отчеты для несвязанных проблем
Если в одном отчете сообщается о нескольких ошибках, он не может быть закрыт до тех пор, пока не будут решены все проблемы. Поэтому, если проблемы не связаны друг с другом, следует создавать отдельные отчеты.
Допустим, тестировщик столкнулся с двумя проблемами в приложении в разных модулях. Одна связана с функцией создания электронного письма, когда пользователь не может составить письмо, а другая – с невозможностью распечатать письмо. Эти ошибки должны быть рассмотрены отдельно, поскольку они не зависят друг от друга.
9. Не используйте авторитетный тон
Документируя ошибку, избегайте командного тона, резких слов и насмешек над разработчиком.
Цель хорошего отчета об ошибке – помочь разработчику и руководству понять ошибку и ее влияние на систему. Чем точнее и подробнее будет составлен отчет об ошибке, тем быстрее и эффективнее она будет устранена.
Основные характеристики отчета об ошибках
На рынке доступны различные инструменты для создания баг-репортов, такие как Jira, Bugzilla, TFS и Asana. На их выбор обычно влияет стоимость проекта.
Для небольших проектов можно также использовать Excel или Word. Независимо от того, какие инструменты используются, тестировщик должен зафиксировать определенные детали в отчете об ошибке.
Рассмотрим их подробнее.
1. Идентификатор ошибки:
Каждой ошибке должен быть присвоен уникальный идентификационный номер. Баг-трекинговые автоматически присваивают уникальный номер всем новым ошибкам. Это поле помогает легко идентифицировать баги.
(Пример ошибки)
2. Заголовок:
Здесь необходимо дать четкое описание проблемы. Заголовок (тайтл) должен представлять собой краткое изложение, помогающее выявить проблему. Названия ошибок должны быть понятными, что поможет быстро найти проблему среди остальных. Качественно написанный тайтл помогает менеджерам быстро проанализировать ошибки во время совещаний по их рассмотрению.
3. Описание:
Описание должно быть составлено простым языком, понятным разработчику. Необходимо указать все подробности о среде и предварительных условиях для выполнения тестовых шагов, такие как конфигурация или тестовые данные. Рассмотрим пример: мобильное приложение падает при переключении на модуль, к которому пользователь не имеет доступа. В таких сценариях в предварительном условии должны быть указаны уровни доступа пользователя, а также URL-адрес страницы администратора для изменения пользовательских прав.
4. Тестовые шаги:
Тестовые шаги представляют собой подробное описание точных действий, предпринятых для воспроизведения проблемы, и должны быть обязательно включены в баг-репорт. Они предоставляют разработчикам необходимую информацию для выявления и отладки ошибки. Этот пункт должен быть написан четко и лаконично и включать подробное описание каждого шага, чтобы при воспроизведении проблемы не возникло никаких трудностей.
5. Фактические результаты:
Необходимо указать фактический результат выполнения тестовых шагов. Независимо от того, совпадает ли он с ожидаемым, документирование того, что произошло, поможет улучшить будущие сценарии.
6. Ожидаемые результаты:
Также важно указать ожидаемые результаты от выполнения теста. Это поможет разработчику узнать, какое именно поведение следует ожидать после исправлении ошибки. Данная информация также будет полезна при повторном тестировании ошибки.
7. Докладчик:
Необходимо указать имя и e-mail автора баг-репорта. В баг-трекинговых системах они автоматически извлекаются из профиля пользователя. Это поможет разработчику или рецензенту быстро определить, кто обнаружил ошибку и составил отчет о ней. Разработчики всегда смогут связаться с автором отчета, если необходимо провести какое-либо обсуждение ошибки.
8. Дата:
Необходимо указать дату, когда была обнаружена ошибка. Это поможет определить релиз, в котором она возникла.
9. Назначение:
Ошибка должна быть назначена владельцу продукта или разработчику. Они могут рассмотреть ошибку и спланировать ее исправление в соответствии с возможностями членов команды и их опытом работы с модулями. В некоторых случаях ошибку можно не назначать и добавить в очередь, из которой разработчики смогут выбрать ее в соответствии с приоритетом устранения.
10. Серьезность:
Тестировщик определяет уровень серьезности ошибок в зависимости от того, как они влияют на приложение. Степень тяжести может быть следующей:
- Blocker: препятствует разработке и/или тестированию и/или реальному использованию системы/продукта (например, падение при запуске приложения).
- Critical: Значительная потеря функциональности, не имеющая обходного пути, при этом другие части продукта/системы продолжают работать.
- Major: Нормальная потеря работоспособности или другая проблема, для которой существует сложный способ решения.
- Minor: Незначительная потеря работоспособности или другая проблема, для которой существует обходной путь.
11. Приоритет:
Определяется тестировщиком/владельцем продукта с учетом серьезности, вероятности, потребностей бизнеса, времени и имеющихся ресурсов.
- High: Ошибки, связанные с основной функциональностью приложения и требующие срочного исправления в течение спринта.
- Medium: Ошибки, не влияющие на критическую функциональность пользователя и имеющие обходные пути. Они могут быть исправлены в следующем спринте.
- Low: Ошибки, не влияющие на основную функциональность, являются просто раздражающими факторами, которые могут быть как исправлены, так и отложены на потом.
12. Компонент:
Иногда приложение разделяется на несколько модулей, которые затем упоминаются в этом поле при составлении баг-репорта. Таким образом, становится проще проанализировать, в каком именно модуле возникли проблемы. Если при назначении ошибок указываются соответствующие компоненты, это упрощает назначение устранения проблем соответствующим членам команды, исходя из их компетенции.
13. Затронутая версия:
Это версия приложения, в которой обнаружена ошибка. Знание точной версии может также дать ценную информацию о том, насколько широко распространена ошибка и с чем могут столкнуться другие пользователи. Наличие такой информации позволяет сэкономить время и ресурсы при устранении возможных проблем с приложением.
14. Версия исправления:
Это версия приложения, в которой была исправлена ошибка. Когда тестировщик выявляет баг, он может обновить версию приложения, чтобы его исправить. Для этого необходимо тщательно изучить код и возможные изменения, которые могут потребоваться. После исправления ошибки тестировщик проводит повторное тестирование приложения, чтобы убедиться, что все работает так, как ожидалось. Если есть какие-либо проблемы, они могут быть устранены до выпуска новой версии программы.
15. Дата закрытия:
Это дата закрытия ошибки командой тестирования. Закрытие ошибки является неотъемлемой частью процесса тестирования программного обеспечения. Дата закрытия записывается в баг-трекинговую систему, также туда вносятся все примечания, касающиеся способа устранения ошибки и ответственного за ее устранение. Эта информация может быть использована в качестве справочного материала при дальнейшем поиске и устранении неисправностей, а также в качестве отчета о прогрессе в повышении качества программного обеспечения.
16. Целевая версия:
Это версия приложения, в которой планируется исправить ошибку. Когда разработчики работают над фиксом ошибки, они обычно ориентируются на конкретную версию ПО. Это позволяет сосредоточиться на устранении проблемы в конкретной версии, не вызывая изменений в других. Ориентируясь на нужную версию приложения, разработчики могут гарантировать, что все пользователи, работающие с ней, получат исправное ПО и высокое качество работы с ним.
17. Состояние:
Программная ошибка проходит определенный цикл. В зависимости от того, на каком этапе цикла она находится, ей присваивается статус. Например, когда заводится новая ошибка, ей присваивается статус “Открытая”. В дальнейшем она проходит различные стадии, такие как “В работе”, “Исправлена”, “Не будет исправлена”, “Принята”, “Повторно открыта”, “Проверена” и т.д. Эти стадии варьируются в зависимости от инструментария для работы с ошибками.
18. Приложения:
К неудачным шагам следует приложить скриншоты, видео и логи. Скриншоты должны четко отображать суть проблемы, что поможет разработчику быстро ее визуализировать. Видео и логи помогут воспроизвести проблему с помощью необходимых шагов.
Лучше всего, если сюда будут включены предложения по устранению проблемы, если они известны.
Заключение
Для практического анализа и устранения ошибок тестировщики должны составлять полные баг-репорты. Тестировщики должны включать в них всю необходимую информацию, чтобы обеспечить высокое качество отчетов, и продуктивно общаться с разработчиками и менеджерами. Для повышения качества отчетов следует оттчаивать навыки по их составлению. В конечном итоге грамотно составленные отчеты об ошибках способствуют позитивному сотрудничеству между командами и снижению затрат на исправление недочетов.
Часто задаваемые вопросы
Что должно быть в баг-репорте?
Отчет об ошибке должен содержать подробное описание проблемы, шаги, предпринятые для ее воспроизведения, ожидаемый и фактический результат. В нем также должны быть приведены соответствующие скриншоты, видео или другие подтверждающие данные, которые помогут проиллюстрировать происходящее. Кроме того, в сообщении должна содержаться информация о типе устройства, версии операционной системы и браузера, использовавшихся в момент возникновения проблемы.
Как написать отчет об ошибке?
Отчет об ошибке – это документ, в котором описывается проблема в программном или аппаратном обеспечении и приводится информация, помогающая разработчикам устранить ее. Отчет об ошибке должен содержать следующие пункты:
- Тайтл -описательный заголовок, кратко описывающий проблему.
- Подробное описание проблемы, включая шаги по ее воспроизведению.
- Ожидаемое и фактическое поведение ПО.
- Тип устройства или системы, с которой возникла проблема.
- Версия затронутого программного или аппаратного обеспечения.
- Скриншоты, видео или логи, отображающие присутствие ошибки.
- Контактная информация тестировщика на случай, если у разработчиков возникнут вопросы по отчету.
Перевод статьи «How to Write a Bug Report? Some Effective Tips».
Пингбэк: Что такое баг-репорт?