Сколько примерно было флейки-тестов?

Я как QA Engineer с большим стажем могу сказать, что вопрос о флейки-тестах (flaky tests) — один из самых острых и практических в автоматизации. Прямого числового ответа "сколько было" дать невозможно, так как это глубоко контекстуально, но я подробно объясню, откуда они берутся, как их оценивать и бороться с ними.

📊 Оценка количества флейки-тестов: реалистичные метрики

В успешных проектах с зрелыми процессами доля флейков обычно составляет 1-5% от общего числа автотестов. Однако в новых или быстро растущих проектах эта цифра может достигать 10-20% и даже выше. Давайте разберем факторы:

• Проектная зрелость: В legacy-системах с тестами, написанными годами назад без единых стандартов, флейков может быть >15%. В проектах с сильной DevOps-культурой и "зелеными" пайплайнами — ближе к 1-2%.
• Тип тестов: Наибольший процент флейков обычно в UI-тестах (Selenium, Cypress) из-за асинхронности, динамического контента и зависимостей от внешних сервисов. API-тесты значительно стабильнее, но тоже могут флейкать из-за таймаутов или состояний данных.
• Дисциплина работы с данными и зависимостями: Если тесты не изолированы и используют общую базу/среду, флейков становится на порядок больше.

🔍 Типичные причины флейков и их "цифровое" выражение

В моей практике распределение причин примерно такое:

1. Проблемы с синхронизацией и таймингами (~40% случаев)

Это самая частая причина в UI. Пример — попытка найти элемент до его появления в DOM.

// ❌ ПЛОХО: Флейкийный тест
await page.click('#submitButton');
const result = await page.textContent('#result'); // Элемент может ещё не отобразиться

// ✅ ХОРОШО: Явное ожидание
await page.click('#submitButton');
await page.waitForSelector('#result', { state: 'visible', timeout: 10000 });
const result = await page.textContent('#result');

2. Зависимость от внешних данных и состояний (~30%)

Тесты, которые полагаются на конкретные записи в БД или ответы сторонних API.

# ❌ ПЛОХО: Тест зависит от существующих в БД данных
def test_user_balance():
    user = get_user_from_db(email="test@example.com")  # А если пользователь удалён?
    assert user.balance > 0

# ✅ ХОРОШО: Тест сам создаёт и чистит данные
def test_user_balance():
    test_user = create_test_user(balance=100)  # Фикстура или фабрика
    assert test_user.balance == 100
    cleanup_user(test_user.id)

3. Параллельное выполнение и race conditions (~15%)

Когда тесты влияют друг на друга, особенно при параллельном запуске.

4. Нестабильная инфраструктура и окружение (~10%)

Медленные среды, проблемы с сетью, перегруженные CI-агенты.

5. Сложная бизнес-логика с вероятностным поведением (~5%)

Например, тесты систем рекомендаций или A/B-тестирования.

🛠️ Как мы отслеживали и снижали количество флейков

В одном из проектов мы внедрили систему мониторинга, которая автоматически помечала тест как "подозрительный", если он:

• Падал, а при повторном запуске (ретрае) проходил.
• Имел сильно "прыгающее" время выполнения.
• Падал только на определенных агентах CI.

Конкретные меры по борьбе:

1. Внедрение "умных" ожиданий вместо sleep().
2. Строгая изоляция тестовых данных с помощью транзакций или отдельных БД на каждый тестовый поток.
3. Retry-стратегия в CI/CD: Автоматический повтор падающего теста 1-2 раза перед финальным вердиктом (но это паллиатив, а не решение!).
4. Регулярные "дни борьбы с флейками" в команде, когда мы анализировали топ нестабильных тестов и рефакторили их.
5. "Карантин" для хронических флейков: Их выносили в отдельную суиту, чтобы не блокировать основной пайплайн, но продолжали периодически исследовать.

📈 Ключевой вывод для бизнеса

Количество флейков — не просто технический долг, а прямой индикатор зрелости процессов разработки и автоматизации. Высокий процент флейков:

• Подрывает доверие к автотестам: команда начинает игнорировать падения CI.
• Замедляет delivery: Много времени тратится на ручные ретраи и разбор ложных падений.
• Маскирует реальные баги: Настоящая проблема может потеряться среди шума.

Поэтому в моей работе я всегда настаиваю на проактивном подходе: лучше потратить время на написание стабильного теста с правильной архитектурой, чем потом тратить в 10 раз больше сил на поддержку и дебаг флейков. Идеальный показатель — стремиться к 0%, но реалистичная и здоровая цель — удерживать их в пределах 2-3% с четким планом по каждому случаю.