При создании программного обеспечения ошибки неизбежно будут возникать, поэтому нужно уметь грамотно их фиксировать. Баг-репорты помогут улучшить ваш ИТ-продукт, отобразив всю необходимую информацию о каждом дефекте.
В этой статье мы подробнее рассмотрим определение баг-репорта, его структуру и основные ошибки при составлении, а также коснёмся типов дефектов.
Что такое баг-репорт и дефект
Дефект — ошибка, которая приводит к тому, что программное обеспечение ведёт себя не так, как ожидает пользователь или задумал разработчик.
Баг-репорты в тестировании (отчёт об ошибке) — это структурированный отчёт, содержащий информацию об ошибке, возникающей при разработке и функционировании ПО. QA-специалисты находят дефекты, когда сталкиваются с неожиданным поведением программы или получают несоответствующие техническим требованиям результаты при использовании продукта, который они тестируют.
В отчёте об ошибке документируется проблема, чтобы разработчики могли выявить и устранить её. Сообщения об ошибках необходимы для поддержания качества программного обеспечения, улучшения пользовательского опыта и защиты от угроз. Так, неправильный учёт ошибок безопасности ПО может привести к атаке хакеров, которые получат доступ к данным ваших клиентов или информацию о секретном продукте.
Баг-репорт пример
Пример отчёта о сбое мобильного приложения:
Название: Приложение вылетает при открытии меню настроек.
Среда: iOS 15.0, iPhone 12 Pro.
Действия по воспроизведению:
- Запустите приложение.
- Нажмите на опцию «Настройки» в нижней панели навигации.
- Ожидаемый результат: меню настроек должно открыться без проблем.
- Фактический результат: приложение сразу же вылетает при нажатии опции «Настройки». При попытке перезагрузить телефон проблема не устраняется.
- Воспроизводимость: всегда
- Важность: высокая
- Срочность: обычная
- Дополнительная информация: приложение обновлено до последней версии, но проблема всё ещё возникает. Никакие другие части приложения, похоже, не затронуты; вылетает только если зайти в меню настроек.
Основные виды багов в программном обеспечении
Функциональные дефекты
В этом случае ПО функционирует не так, как было задумано разработчиками и владельцами бизнеса. Функциональные ошибки могут затрагивать небольшую часть продукта, такую как нажатие кнопок или ссылок, или более сложные операции, которые влияют на удобство использования программного обеспечения в целом.
Синтаксические дефекты
Это ошибки в исходном коде, лежащем в основе ПО. Необходимо внимательно изучить код, чтобы найти пропущенные символы или проблемы с форматированием, которые привели к возникновению проблемы.
Логические дефекты
Если программа выдаёт неправильный результат, наиболее вероятной причиной является логическая ошибка. Логическая ошибка может возникнуть в любой части кода и часто бывает вызвана неправильным пониманием требований, некорректным расчётом или неверной логикой разработчика.
Ошибки безопасности
Эти ошибки создают серьёзные уязвимости в программном обеспечении. Хакеры могут использовать его слабые места для получения доступа к устройствам и сетям. Тестирование ПО на наличие ошибок безопасности и их оперативное исправление — приоритетная задача тестировщиков и разработчиков.
Дублирование кода
Когда решение работает слишком медленно, частой причиной является дублирование части кода. Громоздкий и плохо написанный код ухудшает производительность ПО.
Структура баг-репорта
Для исправления дефектов отчёт об ошибке должен доносить всю необходимую информацию о проблеме в ПО до специалиста, который будет её исправлять. Только так этот отчёт станет эффективной частью обеспечения качества бизнес-продукта.
Отчёт об ошибке может включать в себя следующие разделы:
Он представляет собой уникальное значение, которое позволяет отличить один дефект от другого. Наличие идентификатора у дефекта повышает эффективность их исправления.
Оно содержит лаконичные ответы на вопросы «Что произошло?» «Где это произошло»? «При каких условиях это произошло?».
- Подробное описание проблемы
Оно предоставляет в развёрнутом виде необходимую информацию о дефекте, а также описание фактического и ожидаемого результата.
Это краткий набор инструкций по воспроизведению ошибки, с которой столкнулся QA-инженер. Эти шаги помогут IT-специалистам быстрее найти и исправить дефект.
Она показывает каждый ли раз удаётся вызвать дефект.
Он содержит любые полезные для понимания и исправления дефекта данные.
Сюда QA-специалисты могут прикрепить скрины, видео и т.д.
- Серьёзность и приоритетность
Эти два раздела мы рассмотрим ниже.
Степени серьёзности и приоритетности в баг-репортах
Для поиска и устранения дефектов обычно используются такие понятия как серьёзность и приоритетность ошибки. Однако часто их используют как взаимозаменяемые понятия, что неверно.
Серьёзность и приоритетность в тестировании программного обеспечения — это два важных понятия, используемых для классификации проблем, обнаруженных в ходе тестирования.
Серьёзность относится к влиянию дефекта на функциональность или опыт конечного пользователя. Она определяет, насколько серьёзной является проблема и насколько важно её устранить. Серьёзность дефекта можно разделить на такие уровни, как низкий, средний, высокий и критический.
Низкий: ошибка не приведёт к заметным сбоям в работе системы.
Средний: приводит к некоторому неожиданному или нежелательному поведению ПО, но не настолько, чтобы нарушить работу системы.
Высокий: ошибка может привести к разрушению больших частей системы.
Критический: ошибка, способная привести к масштабным последствиям, таким как раскрытие конфиденциальной информации или нарушение ключевой функциональности ПО.
Приоритетность относится к срочности, с которой дефект должен быть исправлен. Он определяет, насколько быстро необходимо решить проблему, исходя из влияния на бизнес или сроки проекта. Приоритет дефекта также можно разделить на различные уровни: низкий, обычный, высокий и наивысший.
Низкий: ошибка может быть исправлена позже. Другие, более серьезные ошибки имеют приоритет.
Обычный: ошибка может быть исправлена в ходе обычной разработки и тестирования.
Высокий: дефект следует исправить вне очереди, так как его существование или уже мешает работе, или скоро начнёт создавать проблемы.
Наивысший: ошибку следует исправить как можно быстрее.
Свойства качественных баг-репортов
Отчёт о дефекте может оказаться некачественным, что снизит вероятность исправления ошибки. Чтобы этого не произошло, следует соблюдать некоторые правила:
- Тщательно заполнять все поля точной и корректной информацией, которой должно быть достаточно для понимания сути проблемы.
- Использовать правильный технический язык. Это относится не только к отчётам о дефектах, но и к любой документации.
- Подробно описывать шаги воспроизведения бага. Нехватка деталей может привести к невозможности воспроизведения дефекта.
- Избегать дубликатов отчётов. Может возникнуть ситуация, при которой несколько специалистов напишут отчёты об одном и том же баге. Также тестировщик может забыть, что раньше уже описывал эту проблему.
- Описывать дефект так, чтобы получатель отчёта не сомневался в том, что это действительно ошибка, а не нормальное поведение ПО. Этого можно избежать за счёт подробного объяснения фактического и ожидаемого результата.
- Делать новые отдельные отчёты для каждого дефекта, чтобы избежать путаницы и быстрее исправить все ошибки.
- Придерживаться принятых шаблонов оформления и традиций. Шаблоны оформления отчётов о дефектах определены инструментом, который тестировщики используют для управления жизненным циклом дефекта. Однако традиции могут различаться даже в разных командах инженеров в рамках одной компании. Перед началом работы QA-специалистам будет полезно почитать готовые отчёты о дефектах, что в будущем поможет сэкономить силы и время.
- Не добавлять лишние шаги в раздел воспроизведения ошибки и делить на пункты то, что можно заменить одной фразой. Также не стоит в начале каждого отчёта о дефекте подробно описывать как запустить приложение и привести его в то или иное состояние. Можно описать нужное состояние приложения в первом шаге. Например: приложение запущено и проработало более 30 минут.
Жизненный цикл бага
Жизненный цикл бага — это определенный набор состояний, через которые проходит дефект.
Цель отслеживания жизненного цикла бага — легко координировать и передавать текущий статус дефекта другим специалистам и сделать процесс его исправления эффективным.
Жизненный цикл начинается с нового дефекта, обнаруженного тестировщиком во время проверки ПО. Он продолжается до тех пор, пока тестировщики не проверят исправленную программистами ошибку и не «закроют» баг.
Общий жизненный цикл бага включает в себя несколько этапов, которые позволяют тестировщикам отслеживать ошибки и улучшать качество программного обеспечения.
8 этапов жизненного цикла бага:
- Новый. Когда тестировщик обнаруживает ошибку при тестировании ПО, она попадает в категорию «Новая», а на следующих этапах жизненного цикла ошибка проверяется и тестируется.
- Назначен. Ошибка идентифицируется, утверждается руководителем тестирования, публикуется тестировщиком, а затем передаётся команде разработчиков для работы над ней. Наконец, руководитель группы тестирования или менеджер по контролю качества передаёт ошибку разработчику.
- Исправлен. После того как разработчик проанализирует ошибку и внесёт изменения в код для её исправления, он может пометить ошибку как исправленную и передать её команде тестирования для дальнейшей обработки.
- Проверен. Если тестировщик удостоверился, что дефект был устранён, он переводит баг в эту стадию. Обычно такую проверку выполняет тестировщик, который составлял отчёт о дефекте.
- Закрыт. После исправления ошибки тестировщик проводит повторное тестирование. QA-инженер «закрывает» баг, если считает, что ошибка была успешно устранена. Также дефект может перейти в этот статус, если программисты считают, что программа так и должна работать, данный дефект уже взят в работу, его невозможно воспроизвести или исправить.
- Открыт заново. В это состояние отчёт переводит тестировщик, удостоверившийся, что дефект по-прежнему воспроизводится, хотя он должен быть уже исправлен.
- Отклонён. Ошибка обычно отклоняется, если разработчик считает ее неточной.
- Отложен. Когда ошибка так помечена, она имеет более низкий приоритет и может быть исправлена в следующем релизе.
Типичные ошибки при составлении баг-репорта
1.Слишком расплывчатое описание ошибки.
Важно предоставить разработчикам как можно больше подробностей об ошибке, так как это поможет сэкономить время и предотвратить путаницу, что в конечном итоге приведёт к более быстрому и эффективному исправлению дефектов продукта.
2. Неправильная классификация срочности и важности ошибки.
Неверное указание этих параметров ошибки может привести к задержке в устранении проблемы или, что хуже, к её игнорированию. Это в свою очередь может повлиять на общую функциональность продукта и сделать его непригодным для использования.
3. Передача отчёта об ошибке не тому специалисту.
Важно убедиться, что отчёт об ошибке попадёт к человеку, который лучше всего подходит для устранения дефекта. В противном случае исправление ошибки может занять большее количество времени.
4. Отсутствие срока выполнения задачи по исправлению дефекта.
Благодаря установлению срока исполнения ошибка не затеряется в среди других задач и поможет назначенному сотруднику расставить приоритеты в своей работе. Так QA-инженеры помогают продвижению процесса и обеспечивают оперативное исправление дефекта.
5. Игнорирование важности регулярных обновлений о статусе ошибки.
Регулярно предоставляя обновления о статусе дефекта, тестировщики подтверждают, что дефект остаётся приоритетным и предпринимаются необходимые шаги для решения проблемы. Поддержание связи с разработчиками позволит сделать процесс исправления дефекта бизнес-продукта более эффективным.
6. Отсутствие подробной информации о дефекте.
QA-специалистам следует уделять время подробному описанию проблемы и включать в отчёт об ошибке любую необходимую информацию, такую как сообщения об ошибках или скриншоты. Чем больше деталей представлено, тем проще разработчикам воспроизвести ошибку и исправить её.
7. Неумение пользоваться инструментами управления отчётами об ошибке.
Это может привести к неполным или неточным отчётам об ошибке и общей путанице в процессе отслеживания ошибок. QA-специалистам следует потратить время на то, чтобы разобраться с инструментами управления отчётами об ошибке, чтобы обеспечить бесперебойный процесс отслеживания ошибок.
8. Откладывание написания отчёта о дефекте.
Некоторые тестировщики любят сразу найти большjе количество дефектов и только потом создавать отчёты. Это может привести к потере данных, которые важны для устранения ошибок. Следует описывать дефект сразу после его обнаружения, чтобы сделать работу по обеспечению качества более эффективной.
Основные моменты
- Баг-репорт (отчёт об ошибке) — полезный инструмент для выявления проблемы с программным обеспечением, который поможет вам отслеживать состояние ПО, а вашему продукту — соответствовать бизнес-требованиям, ожиданиям и потребностям пользователей.
- Баг-репорты необходимы для успешного проведения тестирования, однако без них можно обойтись, если баг исправляют сразу или тестировщики передают информацию о баге программистам устно/письменно через чат. Мы не рекомендуем так делать, т.к. дефекты могут затеряться.
- Отчёт об ошибке должен содержать чёткое и подробное описание ошибки, что поможет разработчикам эффективно её решить.
- При составлении отчёта об ошибке специалисты могут допустить множество ошибок, поэтому рекомендуем обращаться к опытным QA-инженерам.
- Существую различные типы дефектов, которые ведут к проблемам в использовании ПО.
Ищете QA-специалистов, которые используют все актуальные инструменты для улучшения качества ПО? На
бесплатной консультации наши QA-эксперты ответят на все интересующие вас вопросы.
