Что должно входить в баг-репорт для плавающего (непостоянного) дефекта?

Баг-репорт для плавающего (flakey, intermittent) бага требует особой детализации, чтобы помочь разработчику воспроизвести и локализовать проблему. Обязательные пункты:

1. Краткий и информативный заголовок

   • Пример: [Intermittent] Кнопка 'Submit' иногда не отвечает после быстрых последовательных кликов.

2. Детальное описание шагов воспроизведения

   • Максимально конкретные действия. Укажите, если есть зависимость от порядка, времени или предыдущих операций.

3. Фактический и ожидаемый результат

   • Чётко, что происходит при баге и что должно происходить в норме.

4. Ключевая метрика: Частота возникновения (Reproduction Rate)

   • Укажите в процентах или как соотношение: "Проявляется примерно в 3 из 10 попыток (~30%)".

5. Контекст и условия возникновения (Environment & Conditions)

   • Окружение: ОС, версия браузера/приложения, устройство.
   • Условия: Нагрузка на систему, скорость сети, состояние кеша, конкретные данные.
   • Пример: "Чаще возникает при скорости сети < 3G и когда в форме уже введено более 1000 символов".

6. Артефакты (Logs, Screenshots, Videos)

   • Логи: Фрагменты логов приложения, консоли браузера (F12) или сетевых запросов в момент ошибки.
   • Скриншоты/Видео: Особенно полезны для UI-багов.

7. Дополнительные наблюдения (Observations)

   • Любые закономерности: "Ошибка всегда происходит при первом запросе после часа простоя", "Исчезает после очистки кеша браузера".

Пример структурированного описания для API-бага:

**Частота:** ~25% запросов к эндпоинту `/api/v1/process`.
**Условия:** Payload размером > 1MB, содержащий спецсимволы `&` и `<`.
**Лог ошибки:**
```json
{
  "timestamp": "2025-01-27T10:05:32Z",
  "level": "ERROR",
  "message": "NullPointerException in ProcessorService line 142",
  "requestId": "req_abc123"
}

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