Flaky tests и стабильность

Flaky-тест иногда проходит, иногда падает без изменения продукта. Это разрушает доверие к автоматизации: команда перестаёт реагировать на красный pipeline. Flaky нужно не терпеть, а диагностировать как дефект тестовой системы.

Что важно понять

• Нестабильные ожидания, race conditions, async события, fixed sleeps.
• Данные, которые меняются между запусками или конфликтуют в параллели.
• Окружение: медленная сеть, нестабильный стенд, device farm, сторонние сервисы.
• Порядок тестов, shared state и недостаточный cleanup.

Рабочий порядок

1. Соберите историю падений: частота, окружение, шаг, error signature.
2. Воспроизведите тест несколько раз локально и в CI.
3. Изолируйте причину: test bug, product bug, environment issue.
4. Исправьте ожидания, данные или инфраструктуру; только затем добавляйте retry.

Что отдавать команде

• Flaky report с категорией причины.
• Список quarantined tests с владельцами.
• Метрика flaky rate по suite.

Частые провалы

• Считать retry полноценным исправлением.
• Оставлять flaky в release gate.
• Обвинять продукт без анализа тестовых данных и ожиданий.

Практика

Возьмите один нестабильный тест и классифицируйте падения за десять запусков: timing, data, environment, product. Только после этого меняйте код.