Как задокументируешь плавающий баг

Документирование плавающего (нестабильного) бага

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

Специфика заголовка и описания

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

• Плохо: При нажатии кнопки "Отправить" форма не отправляется.
• Хорошо: [Плавающий] В ~15% случаев нажатие кнопки "Отправить" не приводит к отправке формы.

В описании я четко указываю:

1. Что происходит: Фактический, наблюдаемый некорректный результат.
2. Ожидаемый результат: Как система должна вести себя согласно требованиям.
3. Ключевой контекст: Я специально отмечаю, что баг не воспроизводится постоянно.

Пример описания:

Ожидаемый результат: При каждом нажатии кнопки "Отправить" данные формы валидируются и отправляются на сервер, пользователь видит уведомление "Успешно!".

Фактический результат: Примерно в 15% случаев (по данным 100 тестовых прогонов) после нажатия кнопки "Отправить" интерфейс "зависает" — кнопка остается в нажатом состоянии, спиннер загрузки не отображается, ответ от сервера не приходит. Через 2-3 минуты может появиться таймаут-ошибка 504, либо форма неожиданно "разблокируется" без отправки данных.

Важно: Дефект проявляется нерегулярно. Не удается найти однозначной последовательности действий для 100% воспроизведения.

Детали для воспроизведения: Шаги, Среда, Частота

Это самая критическая часть. Я создаю максимально точный "слепок" условий.

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

  1. Открыть главную страницу https://example.com в браузере Google Chrome версия 123.0.6312.105.
  2. Авторизоваться под пользователем test_user_1 (логин: user1@test.com, пароль: QwErTy123!).
  3. Перейти в раздел "Заказы" -> "Создать новый".
  4. Заполнить все обязательные поля валидными данными (например, "Название": "Тестовый заказ АБВ", "Количество": 5).
  5. **Не** делать пауз между заполнением полей. Нажать кнопку "Отправить" в течение 1-2 секунд после ввода последнего значения.
  6. Наблюдать за поведением кнопки и появлением уведомления.
  

• Актуальность окружения: Указываю не только ОС и браузер, но и версии, разрешение экрана, если есть вероятность влияния.

    *   **ОС:** Windows 11 Pro 23H2 / macOS Sonoma 14.4
    *   **Браузер:** Google Chrome 123.0.6312.105, Firefox 115.8.0esr
    *   **Сеть:** Стабильный Wi-Fi (50 Мбит/с), также проявляется при использовании LTE (мобильная точка доступа).
    *   **Версия приложения:** Frontend v2.5.1, API v1.18.3.

• Оценка частоты: Использую данные, а не предположения. Примерно 1 из 7 запусков (14%), Проявляется в 10-20% случаев при высокой нагрузке на сеть.

Логи, скриншоты/видео и гипотезы

Для плавающих багов визуальное доказательство и логи бесценны.

• Логи: Прикрепляю логи браузера (Console, Network), серверные логи (если есть доступ), логи мобильного приложения или базы данных. В отчете выделяю ключевые моменты.

  # Пример выдержки из лога, где видна проблема
  [2024-04-10 15:33:22] INFO: Form submission started. Request ID: abc123.
  [2024-04-10 15:35:55] ERROR: Request timeout (180s). Request ID: abc123. # Длинный таймаут
  

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

• Гипотезы и паттерны: Это не требования к разработчику, а помощь. Я делюсь наблюдениями:

    *   Баг чаще проявляется **при медленном или нестабильном интернет-соединении**.
    *   Кажется, связан с **конкурентным запросом** — если быстро переключать вкладки во время отправки, вероятность выше.
    *   Не проявляется, если **предварительно очистить кеш браузера** (гипотеза о проблеме с закешированным старым скриптом).

Серьезность, приоритет и дополнительный контекст

• Severity/Серьезность: Часто ставлю S3 (Minor) или S2 (Major), но не Critical, так как баг не блокирует основной поток постоянно.
• Priority/Приоритет: Может быть P2 (High) или P3 (Medium) в зависимости от частоты и бизнес-риска. Плавающий баг в платежной системе — это P1, в редкой настройке профиля — P3.
• Дополнительно: Указываю ID тест-кейса, если баг найден в ходе автотеста. Ссылаюсь на похожие, уже известные проблемы в баг-трекере. Добавляю теги: flaky, intermittent, race-condition, network-related.

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