Всем привет! Меня зовут Ира Карачакова, я тестировщик в сервисе бронирования отелей Отелло. В этой статье рассказываю, как у нас в команде выстроился процесс работы с нестабильными фронтовыми e2e-тестами: от простых перезапусков в CI до системы алертов, карантина и отслеживания стабильности.
Это не инструкция и не универсальный рецепт. Скорее история эволюции процессов в живом продукте: с какими проблемами мы сталкивались, какие решения пробовали и какие выводы сделали.
Возможно, статья подкинет вам идеи и ориентиры: какие сигналы о flaky-тестах важно отслеживать, как не терять нестабильные тесты из виду и как со временем превратить борьбу с ними в управляемый процесс.
Шаг 0. С какими тестами и условиями мы стартовали
Сначала немного вводных.
Мы работаем с фронтовыми e2e-тестами, количество тестов около 2000. Это пользовательские сценарии, которые прогоняются в браузере и проверяют ключевые флоу сервиса бронирования.
Тесты запускаются в CI: на мастер-ветке, на фиче-ветках, в релизных пайплайнах. Тесты прогоняются на каждый пуш. Релизимся мы каждый день, а то и несколько раз в день.
Для тестирования используются отдельные окружения с моками и тестовыми данными, но несмотря на это тесты могут флаковать. Причины обычно связаны с асинхронностью фронта, состоянием приложения, анимациями, плавным появлением и исчезновением элементов, которые могут мешать клику.
Результаты e2e-тестов влияют на пайплайны, падения блокируют дальнейшие шаги как в ветках, так и при релизе. Нестабильные тесты становятся заметными и мешают команде.
Шаг 1. Просто перезапускали тесты
Начиналось всё довольно банально. Часть e2e-тестов время от времени падала без особой причины. Когда это происходило на master-ветке, падение блокировало пайплайн. И из-за фейла тестов нельзя было порелизить.
Самое простое решение — перезапустить тест в джобе, чтобы сэкономить время и не перезапускать весь пайплайн.
Как правило, после перезапуска теста он проходил, и пайплайн становился зелёным. Так мы закрывали самую острую проблему: тест упал→ перезапустили тест → перезапуск помог, пайплайн не стопорится → можно двигаться дальше.
Но у этого подхода был побочный эффект: перезапуски происходили «в тишине» — симптом устранялся, но полной картины мы не видели.
Отдельная боль — метрики качества автотестов. Лишние перезапуски заметно искажают картину, при перезапусках результаты прогонов в Allure TestOps частично перезатираются, и реальная история падений становится менее прозрачной.
Шаг 2. Уведомления о перезапусках
Следующая мысль была простой: если тест упал и прошёл после перезапуска, хочется об этом знать. Так появились алерты о перезапусках тестов.
Каждый раз, когда тест на master-ветке падал и запускался повторно, мы отправляли уведомление в отдельный чат в рабочем мессенджере. Для этого используем кастомный плагин Vedro: он отслеживает нужные условия во время выполнения тестов и через Mattermost incoming webhook отправляет сообщение напрямую в канал.
Идея была не в том, чтобы срочно чинить всё сразу, а в том, чтобы собрать сигналы о потенциальных flaky-тестах и вернуться к ним позже.
Если причина понятна сразу — никто не мешает выкатить фикс. Эффект оказался заметным: мы начали видеть, какие тесты «шумят» чаще других.
Шаг 3. Медленные тесты тоже проблема
Параллельно мы заметили ещё одну боль. Некоторые тесты не падали, но выполнялись подозрительно долго. Отследить это вручную сложно: нужно заходить в прогоны и сравнивать время выполнения тестов.
Мы решили, что медленные тесты — это тоже сигнал, и начали слать алерты о замедлении в тот же чат. Тест считается медленным, если он выполняется дольше 30 секунд — это часто используемый таймаут ожидания разных событий. Тест, который завершился со статусом passed, но выполнялся дольше этого лимита, почти всегда содержал внутри проблему, которую мы не обработали как ошибку.
Так у нас появилось два типа алертов:
о перезапусках,
о медленных тестах.
Шаг 4. Изоляция flaky-тестов и появление карантина
Со временем стало понятно, что одних перезапусков и алертов недостаточно. Флаки-тесты продолжали жить в одном основном прогоне рядом со стабильными, формально пайплайн был зелёным, но по факту:
часть тестов регулярно проходила только со второго раза;
в отчётах они выглядели так же, как и надёжные проверки;
сложно было понять, какие тесты действительно стабильны, а какие — просто «дожили до зелёного статуса».
Перезапуски решали проблему блокировок, но не давали ответа на главный вопрос: каким тестам мы на самом деле можем доверять?
В этот момент нам понадобилось явное разделение: стабильные тесты — отдельно, flaky — отдельно. Так появился карантин.
Мы сделали отдельную джобу, куда переносим flaky-тесты. Эта джоба:
не блокирует пайплайн,
содержит только нестабильные проверки,
снимает с команды разработки ответственность за анализ их результатов.
При этом тесты не исчезают из поля зрения — для карантинной джобы тоже приходят алерты. Таким образом мы всегда знаем, какие тесты нестабильны и как часто они падают.
Шаг 5. Карантин без критериев выхода
Через некоторое время обнаружилась неожиданная проблема. Тесты в карантине могли лежать месяцами без изменений, хотя реальная причина нестабильности уже исчезла: что-то пофиксили во фронте, обновилось окружение.
Мы поняли: карантину не хватает обратной связи. Со временем нам стало важно не только изолировать flaky-тесты, но и понимать, сколько времени они проводят в карантине.
Карантин — это не только изоляция flaky-тестов, но и инструмент управления процессом фикса. Даже если тест стал стабильным сам по себе, важно понимать, как долго он «болел» в карантине — это наша внутренняя метрика скорости фикса.
Шаг 6. Алерты о стабильности тестов
Теперь, если тест в карантине успешно проходит N прогонов подряд (учитываем только master-ветку), приходит уведомление о том, что тест снова выглядит стабильным.
Это позволяет:
не забывать про карантинные тесты,
вовремя возвращать «выздоровевшие» проверки в основной прогон,
держать карантин живым, а не бесконечным хранилищем flaky-кода.
На первый взгляд может показаться, что невозвращение тестов из карантина — не проблема: основной прогон стабилен, пайплайн зелёный.
Но на практике такой подход постепенно снижает реальный скоуп e2e-проверок. Тесты формально существуют, но перестают защищать ключевые пользовательские сценарии. Поэтому для нас было важно, чтобы карантин оставался временным состоянием, а у каждого теста был понятный путь обратно в основной прогон.
Шаг 7. Как мы не утонули в алертах?
Когда алерты о перезапусках, замедлениях и падениях из карантина, стабильности тестов стали приходить регулярно, стало понятно: если их не обрабатывать системно, чат быстро превратится в шум.
Решением стали дежурства QA по алертам. Каждую неделю один из инженеров QA становится ответственным за чат с алертами. Все алерты обраба��ываются в течение рабочего дня. Простые правила делают процесс прозрачным:
дежурный взял алерт в работу;
работа по алерту завершена;
в треде остаётся краткий итог: что произошло и какое решение принято.
Дежурство не значит «сразу всё чинить». Задача дежурного — зафиксировать проблему и выбрать путь: взять фикс, завести тикет или изолировать тест.
Так алерты перестали быть просто потоком уведомлений и стали инструментом, который реально помогает поддерживать качество тестов.
Что получилось в итоге?
За счёт поэтапного развития процессов у нас сформировалась система, где:
перезапуск теста — это сигнал о проблеме, а не просто способ «починить CI»,
медленные тесты видны так же явно, как и падающие,
flaky-тесты изолируются, но не теряются из поля зрения,
стабильность тестов измеряется и используется как критерий для возврата из карантина.
Мы не победили flaky-тесты навсегда, но перестали бороться с ними хаотично и научились держать ситуацию под контролем.
Если вы хотите перестать бороться с flaky-тестами хаотично, начните с трёх вещей:
Сделайте нестабильность видимой.
Отделите flaky-тесты от стабильных.
Введите понятные правила реакции.
Остальное со временем достроится само.
Что дальше?
Система алертов и карантина уже хорошо работает под наши задачи, но мы продолжаем её развивать. Мы решили первую важную техническую проблему — flaky-тесты больше не блокируют релизы.
Дальше хотим сделать алерты более содержательными, чтобы на их обработку тратилась меньше времени, и автоматизировать сбор и учёт нестабильностей.
