Лекция 18. Баг-репорты в тестировании.

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

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

Для решения этой задачи используются специальные документы, называемые баг-репортами (Bug Report). Они позволяют стандартизировать процесс передачи информации об обнаруженных ошибках и обеспечить эффективное взаимодействие между тестировщиками, разработчиками и руководителями проекта.

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

Помимо оформления баг-репортов важную роль играет правильная оценка обнаруженного дефекта. Не все ошибки одинаково влияют на работу программы. Одни делают использование приложения полностью невозможным, другие представляют собой лишь небольшие косметические недостатки. Кроме того, разные ошибки могут иметь различный приоритет исправления. Для оценки дефектов используются понятия Severity (серьезность) и Priority (приоритет), которые будут подробно рассмотрены далее.

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

1. Что такое баг-репорт и зачем он нужен

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

Баг (Bug) представляет собой ошибку в программном обеспечении, из-за которой программа работает не так, как предусмотрено требованиями или ожиданиями пользователя.

После обнаружения дефекта тестировщик должен зафиксировать всю необходимую информацию о нем. Для этого создается баг-репорт.

Баг-репорт (Bug Report) — это документ, содержащий подробное описание обнаруженного дефекта, условий его возникновения и информации, необходимой разработчику для воспроизведения и устранения ошибки.

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

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

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

Рассмотрим простой пример.

Предположим, тестировщик сообщает разработчику:

«Кнопка оформления заказа не работает.»

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

Гораздо полезнее будет следующее описание:

«При оформлении заказа в браузере Google Chrome после добавления товара в корзину и нажатия кнопки "Оформить заказ" страница остается без изменений, а запрос на сервер не отправляется.»

Во втором случае разработчик получает значительно больше информации и может быстрее воспроизвести обнаруженную проблему.

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

2. Структура качественного баг-репорта

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

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

2.1. Заголовок

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

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

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

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

2.2. Описание проблемы

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

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

2.3. Шаги воспроизведения

Одним из важнейших элементов баг-репорта являются шаги воспроизведения (Steps to Reproduce). Они представляют собой последовательность действий, выполнив которые другой специалист сможет самостоятельно получить тот же результат и убедиться в существовании дефекта.

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

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

Например, вместо записи:

«Открыть программу и проверить заказ.»

лучше использовать более подробное описание:

Запустить приложение.
Выполнить вход под учетной записью пользователя.
Перейти в раздел «Корзина».
Добавить товар в корзину.
Нажать кнопку «Оформить заказ».

Такой вариант позволяет любому участнику проекта без труда повторить последовательность действий.

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

2.4. Фактический результат

После описания последовательности действий необходимо указать фактический результат (Actual Result). В этом разделе фиксируется реальное поведение программы после выполнения всех описанных действий.

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

Например, корректной записью будет:

После нажатия кнопки «Оформить заказ» страница обновляется, однако заказ не создается и сообщение об ошибке не отображается.

Или:

После ввода неверного пароля приложение завершается с сообщением об ошибке.

Такие формулировки позволяют разработчику увидеть проблему именно такой, какой ее обнаружил тестировщик.

2.5. Ожидаемый результат

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

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

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

Для предыдущего примера ожидаемый результат можно сформулировать следующим образом:

После нажатия кнопки «Оформить заказ» заказ должен быть успешно создан, а пользователю должно быть отображено сообщение о подтверждении оформления.

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

2.6. Окружение

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

Под окружением понимают совокупность условий, в которых проводилось тестирование и был обнаружен дефект.

В зависимости от типа программного обеспечения в окружение могут входить:

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

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

Параметр	Значение
Операционная система	Windows 11
Браузер	Google Chrome 138
Версия приложения	2.4.1
Тип устройства	Ноутбук

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

2.7. Вложения

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

К наиболее распространенным видам вложений относятся:

скриншоты;
видеозаписи процесса воспроизведения ошибки;
журналы работы программы (логи);
дампы памяти;
файлы конфигурации;
тестовые данные.

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

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

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

Ниже приведен пример упрощенного баг-репорта.

Пример баг-репорта

Поле	Содержание
Заголовок	Не создается заказ после нажатия кнопки «Оформить заказ»
Описание	После заполнения всех обязательных полей оформление заказа не выполняется.
Шаги воспроизведения	1. Запустить приложение.2. Выполнить вход под учетной записью.3. Перейти в раздел «Корзина».4. Добавить товар в корзину.5. Нажать кнопку «Оформить заказ».
Фактический результат	Страница обновляется, заказ не создается.
Ожидаемый результат	Заказ успешно создается, отображается сообщение о подтверждении оформления.
Окружение	Windows 11, Google Chrome 138, версия приложения 2.4.1
Вложения	Скриншот страницы после возникновения ошибки.

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

3. Severity и Priority

После обнаружения и регистрации дефекта необходимо определить, насколько серьезной является найденная ошибка и как быстро она должна быть исправлена. Для этого в тестировании используются два важных понятия: Severity (серьезность) и Priority (приоритет).

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

3.1. Severity (серьезность)

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

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

На практике чаще всего используются следующие уровни серьезности.

Рассмотрим каждый из них отдельно:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Trivial (незаметный)

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

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

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

3.2. Priority (приоритет)

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

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

Обычно выделяют три уровня приоритета.

High (высокий)

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

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

Medium (средний)

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

Большинство найденных дефектов относятся именно к этой категории.

Low (низкий)

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

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

3.3. Различие между Severity и Priority

Несмотря на внешнее сходство, Severity и Priority характеризуют разные свойства дефекта.

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

Основные различия представлены в таблице.

Severity	Priority
Характеризует влияние дефекта на работу программы	Определяет срочность исправления дефекта
Связана с техническими последствиями ошибки	Связана с организацией процесса разработки
Обычно определяется тестировщиком	Чаще назначается руководителем проекта или менеджером

Рассмотрим несколько примеров.

Низкая Severity + Высокий Priority: предположим, в интернет-магазине на главной странице размещен рекламный баннер с орфографической ошибкой. Такая ошибка практически не влияет на работу программы, поэтому ее серьезность будет низкой. Однако если баннер размещен на главной странице, которую ежедневно видят тысячи пользователей, руководство проекта может принять решение исправить ошибку как можно быстрее. В этом случае дефект будет иметь низкую Severity, но высокий Priority.

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

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

4. Жизненный цикл дефекта

После регистрации баг-репорта работа с ним только начинается. Каждый обнаруженный дефект проходит несколько последовательных этапов обработки: от момента обнаружения до окончательного подтверждения исправления. Эта последовательность называется жизненным циклом дефекта (Bug Life Cycle).

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

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

Open

Статус Open присваивается сразу после регистрации нового баг-репорта. Это означает, что дефект обнаружен, описан и ожидает начала работы со стороны разработчиков.

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

In Progress

После принятия задачи разработчиком статус изменяется на In Progress. Это означает, что ведется поиск причины возникновения ошибки и разрабатывается способ ее устранения.

Продолжительность этого этапа зависит от сложности дефекта и особенностей программного продукта.

Fixed

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

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

Closed

Если после повторной проверки тестировщик убеждается, что ошибка действительно устранена и больше не воспроизводится, дефект получает статус Closed.

На этом жизненный цикл считается завершенным.

Reopen

Иногда после исправления выясняется, что ошибка сохраняется или проявляется повторно. В этом случае тестировщик изменяет статус дефекта на Reopen.

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

Такая последовательность позволяет отслеживать состояние каждого дефекта на протяжении всего процесса разработки и обеспечивает эффективное взаимодействие между тестировщиками и разработчиками.

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

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

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

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

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

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

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

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

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

Информатика