Ответ.

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

Проблема:

Главная проблема с intermittent-багами — невозможность чёткого сценария воспроизведения. Часто причиной могут быть нестабильные окружения, время отклика, ошибки синхронизации данных или коллизии при работе нескольких пользователей. Разработчику сложно устранить то, что нельзя стабильно поймать. Если тестировщик не документирует сопутствующие условия, баги уходят нерешёнными.

Решение:

Использование расширенной формы отчёта: фиксация времени, окружения, шагов до бага, логов, видео/скриншотов.
Анализ тенденций: при каких условиях проявлялся баг? (Например, "при массовой нагрузке днём" или только при определённых последовательностях действий.)
Близкое взаимодействие с разработчиками для актуализации окружения и уточнения технических деталей.
Повторные попытки воспроизведения на разных устройствах и ОС.

Ключевые особенности:

Всегда фиксировать даже малейшие отличия между успешными и неуспешными попытками.
Указать частоту появления и попытки воспроизвести.
Прикладывать медиа-материалы (скриншоты, видео).

Вопросы с подвохом.

Можно ли закрыть баг как "небагованный", если не удалось воспроизвести инженеру поддержки?

Нет. Если возникло подозрение на баг, лучше оставить тикет открытым с пометкой "reproducibility: low" и обновлять его при получении новых данных.

Всегда ли проблема в коде, если баг intermittently появляется?

Нет. Возможны ошибки в сети, конфиге окружения, устаревшем кэше браузера, специфике работы сторонних сервисов или периферии.

Стоит ли занижать приоритет intermittent-багов, если невозможно воспроизвести их каждый раз?

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

Типовые ошибки и анти-паттерны

Фиксация багов без сопутствующей информации о времени, окружении, версии.
Попытка формального "закрытия" сложности как non-reproducible.
Игнорирование интермиттирующих багов, если не воспроизвелись вне тестовой среды.

Пример из жизни

Негативный кейс

Тестировщик обнаружил баг разблокировки профиля, но баг появлялся не более чем в 1 из 10 попыток. Документация ограничилась скриншотом ошибки — баг закрыли, поскольку разработчик не смог воспроизвести.

Плюсы:

Быстрое закрытие задачи.

Минусы:

Баг всплыл на проде у реальных пользователей, и пришлось устранять его в авральном режиме, рискуя корпоративной репутацией.

Позитивный кейс

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