Как мы оформляли баги нагрузочного тестирования, чтобы разработчик не переспрашивал

Обычный баг-репорт с функционального тестирования разработчик читает и идёт чинить. Баг с нагрузочного тестирования он открывает, видит "latency p99 выросла до 12 секунд", и у него сразу десять вопросов: под какой нагрузкой, на какой конфигурации, сколько держали, что в этот момент происходило с зависимостями. Если ответов нет, баг уходит в "воспроизведите ещё раз", а вы теряете часы на повторный прогон.

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

Заголовок Краткое описание проблемы с максимальной точностью. Не "сервис тормозит", а "p95 latency /api/sms выросла с 200ms до 12s при нагрузке 200% БТ на одном кластере".

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

Шаги воспроизведения: Здесь описываем оркестрирование приложения, а не клики по интерфейсу: "поднимаешь целевую нагрузку согласно предусловию - 200% БТ на одном кластере", "затем выключаешь одну реплику egress/ingress", "смотришь график latency и видишь скачок p99 до 12s". К шагам можно приложить маленький скриншот, как должно выглядеть падение, либо сослаться на вложения с эталонным графиком.

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

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

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

Что вы всегда вкладываете в баги НТ помимо стандартных логов и скриншотов?

#loadtesting #bugreport #performancetesting #qa #sre #nonfunctionaltesting #defectmanagement #jira #testdocumentation #latency #incidentmanagement #engineeringcommunication