Как составить хороший отчет об ошибке

Что такое ошибка

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

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

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

Виды ошибок

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

Визуальный, относится к интерфейсу приложения. Кнопка «Записать» уехала за пределы экрана.
Функциональный. Не сохраняются данные: пользователь нажимает кнопку «Записать», но ничего не происходит.
Дефект UX, влияет на удобство. Чтобы просмотреть актуальное содержимое документа пользователю приходится закрыть и повторно открыть документ.
Проблема с нагрузкой. МИС должна выдерживать нагрузку с сотнями и тысячами конкурентными пользователями. Для выявления таких проблем часто проводят нагрузочное тестирование. Например, искусственно создают ситуацию, когда в один раздел одновременно зашло несколько тысяч пользователей. Если приложение зависает — это проблема с нагрузкой.
Проблема производительности. Приложение занимает в памяти слишком много места, реагирует на действия пользователя слишком долго.
Ошибка требований, или логическая ошибка. До начала разработки приложения или отдельной «фичи» в требованиях что-то не учли. Программист запрограммировал так, как было в требованиях (или как он их понял). В итоге, приложение работает, как описано в требованиях, но не так, как нужно бизнесу.

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

Приоритеты и жизненный цикл ошибки

Срочность исправления

Серьёзность ошибки	Как влияет на систему
Немедленная	Пользователь сообщает о частичной или полной неработоспособности продукта. Проблемы с продуктом не позволяют использовать конкретный функционал, при этом других вариантов решения проблемы не существует, либо они неприменимы в силу высоких затрат по времени и/или деньгам. Возможности перехода на более ранние или поздние версии продукта нет. Ошибка модуля – частый признак немедленной ошибки. К немедленным ошибкам относятся регрессии – то есть потеря функционала относительно предыдущих релизов.
Желательно быстрее	Поддерживаемое ПО в целом работает, однако у одного или незначительного числа пользователей наблюдаются проблемы. Работа с Поддерживаемым ПО может продолжаться в штатном режиме. Пользователь задает вопрос по конкретному функционалу продукта, либо не согласен с тем, как работает определенный функционал. Пользователь также может отмечать ухудшение производительности всего или определенного функционала продукта, при условии, что данное ухудшение не вынуждает заказчика выделять существенно большее (в два и более раз) время для выполнения стандартных задач сверх того, что тратилось раньше.
В плановом порядке	Работа с продуктом продолжается в штатном режиме. Пользователь обращается с предложением о добавлении новой функции или о доработке существующего функционала. Требуется разъяснение ошибок ПО и/или документации.

Жизненный цикл ошибки

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

В результате локализации может быть два вывода:

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

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

Пример пути ошибки в 1С:СППР:

Тестировщик описал, в чём проблема, и присвоил ошибке статус — Зарегистрирована и передал разработчику.

Для регрессий в наименовании ошибки надо в начале строки написать – РЕГРЕССИЯ.

Разработчик задает вопросы тестировщику, если хочет что-то уточнить, а если нет, то ставит статус Признана и берет задачу в работу или статус «Не признана». По завершению работ ставит статус Исправлена и переводит ошибку на ее инициатора.
Для публикуемых в 1С:СППР ошибок Тестировщик обязан проверить исправление ошибки — проверяет, исправили ошибку или нет. Если проблему решили, он ставит статус Проверена, если нет — возвращает задачу разработчику. Она снова получит статус Признана.

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

Что такое отчет от ошибке

В тестировании отчет об ошибке — это отчёт об ошибке, который заводится в 1С:СППР или 1С:УСП (в т.ч. через отправку email на med@1c.ru).

Шаблон отчета об ошибке

* - обязательные сведения.

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

Как правильно оформить отчет об ошибке

Хороший отчет об ошибке приходит с опытом. Вот на что нужно обратить внимание джуну:

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

Как не стоит писать баг-репорты

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

Вот как могли бы оформить эту ошибку более опытные джуны и продвинутые тестировщики.

Отчет об ошибке от опытного джуна или ленивого мидла

Наименование: [Инвентаризация] В начатой задаче при попытке сканирования товаров визуально ничего не происходит
Предусловия: Приложение Инвентаризация запущено и активно, открыта невыполненная задача для инвентаризации
Порядок воспроизведения:
1. Нажать кнопку «Начать».
2. Сканировать товар, присутствующий в задаче и еще не отсканированный.

Фактический результат: при попытке сканирования товара визуально ничего не происходит. В логах ошибка <Error…> (приложен лог с ошибкой).

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

Обнаружена: версия приложения 1.2.21.3.
Срочность: немедленно.

Отчет об ошибке от мидла или сеньора

Наименование: [Инвентаризация] В начатой задаче сканирование товара не записывается в задачу, в логах ошибка <Error…>.

Предусловия: Приложение Инвентаризация запущено и активно, открыта невыполненная задача для инвентаризации.

Порядок воспроизведения:

1. Нажать кнопку «Начать».
2. Сканировать любой товар из задачи.

Фактический результат: при попытке сканирования товара сканер пищит (как и должен), но в задачу сканирование не записывается. В системных логах приложения ошибка <Error…> (приложен кусок лога с ошибкой). В серверных логах ошибка <Error…> (приложен кусок лога с ошибкой).

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

Доп.информация: если отправить запрос о сканировании не с устройства, а через эмулятор, то ошибок не возникает, возвращается корректный ответ (приложены запрос и ответ и логи с эмулятора).
Воспроизводится на тестовом стенде INTG
Обнаружена: версия приложения 1.2.21.3.

Срочность: немедленно.

Все примеры описаны корректно, но видно, как можно подойти к задаче в зависимости от опыта.

Совет

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

На основании https://practicum.yandex.ru/blog/chto-takoe-bug-report-kak-ego-sostavit/