Отчёт о дефекте

Отчёт о дефекте (defect report) - запись о дефекте, найденном в продукте: что наблюдалось, в каких условиях, как это воспроизвести, насколько это серьёзно и на каком этапе обработки находится. Отчёт пишут, когда фактический результат теста отличается от ожидаемого и анализ показывает, что причина в продукте. В обиходе его называют баг-репортом (bug report).

Содержание отчёта о дефекте описано в силлабусе ISTQB Foundation Level (версия 4.0.1, раздел 5.5, управление дефектами). Международный стандарт документации тестирования ISO/IEC/IEEE 29119-3 (текущая редакция 2021 года) описывает ту же запись как отчёт об инциденте (test incident report), а его предшественник IEEE 829 - как отчёт об аномалии (anomaly report). IEEE 1044-2009 задаёт единый подход к классификации программных аномалий; с марта 2020 года у этого стандарта статус Inactive-Reserved.

Зачем нужен отчёт о дефекте

Силлабус ISTQB называет три цели отчётов о дефектах:

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

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

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

Ошибка, дефект и сбой

Глоссарий ISTQB разделяет три понятия, которые часто смешивают:

• ошибка (error) - действие человека, которое приводит к неверному результату, например неверное понимание требования;
• дефект (defect) - изъян или недостаток рабочего продукта, из-за которого он не соответствует своим требованиям или спецификациям, например неверное условие в коде;
• сбой (failure) - событие, при котором компонент или система не выполняет требуемую функцию в заданных пределах, например заказ создаётся с неверной суммой.

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

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

Состав отчёта о дефекте

Силлабус ISTQB перечисляет типичное содержание отчёта о дефекте для сбоя, найденного при динамическом тестировании:

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

Заголовок

Заголовок - строка, которую читают в списках, уведомлениях и отчётах. Он называет наблюдаемое поведение и условия, в которых оно возникает: «Оплата просроченной сохранённой картой создаёт заказ со статусом Paid». Заголовок вроде «Не работает оплата» не говорит ни что происходит, ни когда.

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

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

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

Ожидаемый результат ссылается на свой источник: требование, спецификацию, макет, тест-кейс. Фактический результат описывает наблюдаемое без толкований: «В списке заказов заказ 1042 со статусом Paid», а не «Система игнорирует проверку карты».

Окружение и вложения

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

Пример полного отчёта:

Серьёзность и приоритет

Серьёзность и приоритет - два разных атрибута, и их задают разные люди по разным причинам.

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

Приоритет (priority) - срочность исправления дефекта. Он зависит от серьёзности, но и от других факторов: сколько пользователей затронуто, есть ли обходной путь, когда следующий релиз, какие планы у бизнеса. Приоритет обычно задаёт тот, кто решает о порядке работ: владелец продукта, руководитель проекта, встреча по разбору дефектов.

Шкалы обоих атрибутов не стандартизированы, и каждая команда задаёт свои. Сочетания ниже показывают, почему их держат раздельно:

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

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

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

Распространённая последовательность состояний:

           +--> Rejected (not a defect: false positive, works as specified)
           +--> Duplicate (already reported)
           +--> Deferred (will not be fixed now)
           |
Open --> Analyzed --> Waiting to be fixed --> Awaiting confirmation testing --> Closed
                                ^                         |
                                |                         v
                                +-------------------- Re-opened

Стоит отметить два перехода. После исправления отчёт переходит в «ожидает подтверждающего тестирования», а не в «закрыт»: исправление подтверждают, снова выполняя тест на сборке, которая его содержит. Если подтверждающее тестирование не проходит, отчёт переоткрывают. Эти шаги описаны в статье Тестовый прогон.

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

Состояния и переходы задают команда и инструмент. Баг-трекер обычно закрепляет их как рабочий процесс (workflow): кто может перевести отчёт из какого состояния в какое.

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

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

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

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

Нестабильные сбои автотестов - отдельная тема: такой тест может сам быть ненадёжным, а не обнаруживать дефект. Нестабильные тесты описаны в статье Нестабильные тесты.

Связь дефекта с тест-кейсом и тестовым прогоном

Дефект, найденный при тестировании, связывают в обе стороны:

Requirement PAY-7
 |
 +-- Test case TC-13 "Pay with an expired card"
       |
       +-- Result in run "Release 2.4.0, Safari": failed --> BUG-310
       +-- Result in run "Retest BUG-310, 2.4.1": passed --> BUG-310 closed

Связи служат нескольким целям:

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

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

Отчёт о дефекте и смежные записи

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

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

Термины

Источники

• ISTQB Certified Tester Foundation Level Syllabus v4.0.1, ISTQB, 2024(откроется в новой вкладке) (на английском)
• Глоссарий ISTQB(откроется в новой вкладке) (на английском)
• ISO/IEC/IEEE 29119-3:2021, Software testing, Part 3: Test documentation(откроется в новой вкладке) (на английском)
• IEEE 1044-2009, Standard Classification for Software Anomalies(откроется в новой вкладке) (на английском)