Нестабильные сквозные тесты: сортировать, ставить в карантин и исправлять

Почему нестабильные тесты возвращаются снова и снова

Нестабильный тест делает больше, чем просто красит одну сборку в красный. Он учит команду не доверять набору тестов. После достаточного количества случайных падений люди перестают спрашивать "что сломалось?" и начинают спрашивать "мне перезапустить?" Это кажется мелочью, но меняет то, как люди работают.

Первый счёт — время. Кто-то открывает логи, перезапускает задачу, ждёт ещё 10 минут и получает зелёный результат со второго раза. Сборка проходит, но никто почти ничего не узнаёт. Когда это повторяется несколько раз в неделю, команда теряет часы по чуть-чуть. Эти часы не появляются в роадмапе, но всё равно замедляют поставку.

Потом уходит терпение. QA подозревает приложение. Разработчики подозревают тест. Инфра подозревает браузер, сеть или раннер CI. Любой из них может быть прав, но команда всё равно застревает, потому что никто не сортирует сбои одинаково. Та же дискуссия возвращается снова, и тот же тест падает через три дня.

Урон выходит за рамки времени на перезапуск. Красный пайплайн всё ещё задерживает релиз, даже если все считают сбой случайным. Оповещения игнорируются, потому что слишком много из них никуда не ведут. Как только эта привычка закрепляется, настоящая ошибка может скрыться в шуме.

Вот почему такие тесты остаются. Они живут между линиями ответственности. Никто не чувствует себя полностью ответственным, поэтому команда воспринимает их как фоновую боль, а не как решаемую проблему.

Большинству команд не нужен гигантский проект по очистке, чтобы начать. Им нужен простой способ классифицировать сбои. Это баг продукта, баг теста, проблема с данными, тайминг или проблема окружения? Когда все используют одинаковые корзины, следующий шаг становится гораздо яснее.

Один сбой может потребовать исправления кода. Другому нужны более надёжные ожидания, стабильные данные или короткий карантин с владельцем и датой проверки. Так вы перестаёте превращать каждую красную сборку в спор и делаете её быстрым решением.

Сначала сортируйте по причине

Команды теряют время в тот момент, когда упавший тест превращается в спор об ответственности. Обычно это происходит слишком рано. Сначала отсортируйте сбой по причине. Владение становится проще, когда причина ясна.

Для сквозных тестов первый проход должен ответить на один вопрос: какого типа этот сбой? Держите метки простыми и фиксированными:

• app bug
• test bug
• data issue
• environment issue
• timing issue

Эти пять корзин покрывают большинство сбоев, не превращая триаж в детективное расследование. App bug означает, что продукт сломался. Test bug — скрипт, селектор, ассерт или логика установки неверны. Data issue — тестовые данные истекли, поменяли форму или просто не загрузились. Environment issue — служба, сеть, браузер или раннер CI вели себя плохо. Timing issue — приложение и тест разошлись по времени.

Используйте одни и те же метки каждую неделю, даже если в начале они кажутся грубыми. Последовательность важнее идеальной формулировки. Через месяц начнут проявляться паттерны. Может быть, половина ваших сбоев — из-за тайминга. Может быть, общий набор данных ломается каждая пятница. Вы не увидите этого, если каждый описывает сбои по‑разному.

Держите первую сортировку достаточно простой, чтобы любой в команде мог сделать её за минуту‑две. Им не нужно решать всю проблему сразу. Нужно лишь достаточно доказательств, чтобы поместить сбой в наиболее вероятную корзину.

Возьмём тест оформления заказа, который падает, потому что кнопка "Отправить" остаётся отключённой. Если в логах виден 500 от бэкенда — это app bug. Если страница изменилась, а тест всё ещё кликает старый селектор — test bug. Если аккаунт теста лишился прав за ночь — data issue. Один и тот же упавший тест — разные причины.

Такая простая сортировка меняет тон триажа. Люди перестают гадать. Перестают винить QA за баги продукта и разработчиков за сломанные фикстуры. Команда получает общую карту того, что упало, почему упало и кто должен сделать следующий шаг.

Найдите тесты, которые сильнее всего мешают доставке

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

Начните с обычной рабочей доставки за последние 2–4 недели. Посмотрите проверки PR, прогоны на main, пайплайны релизов и хотфиксов. Игнорируйте разовые эксперименты. Вам нужны тесты, которые прерывают реальную работу, а не странные сбои из необычных прогонов.

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

Последний пункт важен. Шумный тест может падать десять раз и при этом причинять меньше вреда, чем тест, который реже падает, но каждый раз останавливает релиз на 45 минут. Не чините тесты в порядке раздражения. Чините их в порядке потерь времени.

Разница быстро становится очевидной. Представьте тест, который падает 12 раз в месяц, но на перезапуске проходит за две минуты и никогда не останавливает работу. А другой падает всего 3 раза, но каждый раз подключает двоих инженеров и съедает 45 минут, пока релиз ждёт. Второй тест должен быть вверху списка.

Вам не нужна сложная модель оценки. Простая таблица подойдёт. Отметьте каждый тест как шумный или блокирующий, затем редкий или частый. После этого сортируйте по влиянию на доставку, а затем по числу провалов.

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

Простой рутинный триаж, которому команда может следовать

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

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

1. Начните с последнего упавшего прогона и ищите повторения. Если пять тестов падают на одном и том же шаге логина — считайте это одним кластером.
2. Проверьте доказательства до перезапуска. Скриншоты, логи и сетевые ошибки часто говорят, сломалось ли приложение, опередил ли тест интерфейс или сервисы таймаутнулись.
3. Воспроизведите главный блокер один раз в стабильном окружении. Используйте фиксированные тестовые данные, ту же версию браузера и низкую нагрузку CI.
4. Откройте одну задачу на каждую причину, а не на каждый упавший прогон. Дублирующие тикеты делают мелкую проблему крупнее, чем она есть.
5. Назначьте одного владельца и короткий срок для первого исправления. Часто двух дней достаточно, чтобы запатчить тест, починить баг или решить вопрос с карантином.

Эта рутина не даёт флейкам превращаться в гору дублирующих задач. Она также останавливает ранние споры о том, виновато приложение или тест.

Допустим, тесты оформления заказа, сохранённой корзины и истории заказов все падают после логина с одинаковым 401. Это одна проблема аутентификации, а не три отдельных проблемы тестов. Один владелец может проследить поток обновления токена, исправить это и закрыть несколько провалов сразу.

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

Когда помещать тест в карантин, а когда нет

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

Не помещайте тест в карантин только потому, что он шумный. Если сбой указывает на реальный риск для пользователя, держите его в основном сигнале и исправляйте быстро. Сломанный путь оформления заказа, неработающая регистрация или восстановление пароля должны оставаться видимыми, даже если сам тест требует починки.

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

Когда вы помещаете тест в карантин, запишите четыре вещи в одном общем месте: имя теста, причину, владельца и дату проверки. Это может быть доска задач, таблица или небольшая таблица в отчёте по тестам. Формат важнее привычки. Если причина не записана, тест будет лежать месяцы, и доверие к набору протестов упадёт ещё сильнее.

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

Держите критичные для дохода и безопасности пути видимыми, даже если они нестабильны. Если тест платежей падает дважды в неделю из‑за хрупких селекторов, при необходимости уберите его из ворот релиза, но всё равно показывайте в дашборде команды и обсуждайте на обзоре релиза. Полное скрытие — путь к тому, что мелкие тестовые проблемы превратятся в пропущенные баги.

Команды часто спорят, хорош ли карантин или плох. Он ни тот, ни другой. Это временная метка. Используемый как парковочное место с датой возврата — полезен. Используемый как склад — тихо ломает набор тестов.

Реалистичный пример недели релиза

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

Первый сбой реальный. Приложение отправляет платеж, но ответ шлюза не доходит до финального шага. Заказ остаётся "pending", и пользователь столкнулся бы с неработающим оформлением. Команда помечает это как блокер релиза и чинит прежде всего.

В среду тест падает снова. На этот раз платеж проходит, но скрипт нажимает "Подтвердить", пока на кнопке ещё висит загрузочный оверлей. В четверг снова та же причина. Логи показывают нормальный платеж. Видео показывает, что UI стабилизируется на доли секунды позже, чем ожидает тест.

Так выглядит нормальная неделя с флейками. Имя теста одно, а причины разные. Если команда воспринимает все три падения как одну проблему, она теряет время и принимает плохие решения о релизе.

Они принимают три отдельных решения. Реальный баг платежа остаётся в ряду блокеров до тех пор, пока оформление не заработает в прогоне, похожем на продакшен. Тайминговый сбой помещают в карантин на семь дней с заметкой о гонке состояний и с назначенным владельцем. Затем исправляют логику ожидания, чтобы тест ждал исчезновения оверлея и загрузки страницы с чеком.

Пятница проходит гораздо спокойнее. Команда не спрятала баг платежа под туманной меткой "known flake". И при этом не остановила релиз из‑за таймингового сбоя, который уже в карантине, у него есть владелец и простое исправление.

Релиз идёт вперёд, потому что реальный риск исправлен. Шумный сбой остаётся видимым, но больше не блокирует доставку, пока команда ремонтирует тест.

Шаблоны исправлений, которые убирают большинство флейков

Большинство нестабильных тестов происходят из нескольких скучных причин, а не из мистических багов. Команды часто тратят часы, виня фреймворк, когда реальная проблема — слабые селекторы, грязные данные или оставшееся состояние от предыдущего прогона.

Начните с селекторов и ожиданий

Тест должен кликать и читать то, что видит пользователь. Если он зависит от глубокого CSS‑пути, случайного имени класса или третьей кнопки в ряду, небольшая правка в UI может его сломать. Предпочитайте селекторы, привязанные к меткам, ролям, тексту кнопки и другим стабильным элементам страницы.

Жёсткие паузы причиняют ту же боль. Фиксированная пауза в пять секунд слишком коротка на медленном раннере и слишком длинна на быстром. Ждите явный сигнал приложения: кнопка становится активной, появляется уведомление, запрос завершился или в таблице показалась новая запись.

Изолируйте каждый прогон теста

Общее состояние отравляет наборы тестов больше, чем большинство признаёт. Один тест создаёт клиента, другой правит этого клиента, а третий падает, потому что имя уже изменилось. Каждый тест нуждается в собственных данных, собственной настройке и правиле очистки, которому команда действительно доверяет.

Несколько привычек убирают много шума. Создавайте новые записи для каждого прогона вместо повторного использования старых. Используйте уникальные ID или метки времени, чтобы тесты не пересекались. Сбрасывайте куки, localStorage и feature flags между тестами. Сидируйте известные данные, когда приложению нужно конкретное начальное состояние. Не запускайте параллельные тесты на одном и том же общем аккаунте.

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

Если оформление заказа ломается каждую пятницу, не держите один гигантский тест, который строит корзину, редактирует адрес, добавляет купон и подтверждает оплату. Держите короткий тест оформления для блокинга релиза, а логику купона и редактирования адресов вынесите в отдельные проверки.

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

Ошибки, которые делают наборы тестов хуже

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

Первая плохая привычка — помещать в карантин каждый раздражающий тест. Карантин имеет своё место, но это не план очистки. Если команда скрывает все шумные тесты, набор перестаёт говорить правду. Вскоре у вас будет "проходящая" конвейерная линия и ноль доверия к ней.

Другая распространённая ошибка — перезапускать падения до тех пор, пока один прогон не станет зелёным. Это снимает напряжение в моменте, но уничтожает улики. Если первый прогон упал из‑за гонки состояний, медленной настройки данных или нестабильной зависимости, повторные перезапуски лишь зарывают паттерн.

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

Некоторые привычки выглядят продуктивно, но создают больше шума. Команды меняют несколько тестов одновременно, когда один блокирует релиз. Они принимают нестабильные окружения как норму. Они повышают таймауты везде вместо поиска реального условия ожидания. Они закрывают работу по флейкам после одного временного прогона.

Лучше работают маленькие целевые правки. Если один тест логина падает каждый понедельник после деплоя, сначала почините этот тест и окружение вокруг него. Не переписывайте весь модуль аутентификации потому, что один кейс мешает релизу.

Проблемы окружения заслуживают такого же внимания, как код тестов. Если общие данные ресетятся с опозданием, очереди лагают или staging‑служба перезапускается случайно, набор тестов сообщает вам о реальной проблеме. Отмахивание как от "staging как staging" — путь к постоянным флейкам.

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

Короткий чеклист для каждого упавшего теста

Когда тест падает, команде нужны несколько ясных ответов, прежде чем кто‑то начнёт обвинять код, тест или окружение. Если вы получите эти ответы за десять минут, сбои перестанут превращаться в длинные обсуждения в Slack.

Используйте короткий чеклист:

• Опишите причину в одном простом предложении. Например: "Тест оформления упал, потому что мок налога вернул пустой ответ." Если никто не может просто объяснить сбой, расследование всё ещё слишком расплывчато.
• Решите, насколько это больно сейчас. Поставьте в приоритет сбои, которые блокируют доход, регистрации или релиз.
• Проверьте, появлялась ли та же ошибка в нескольких прогонах. Одиночный таймаут может быть шумом. Повторяющаяся ошибка дважды — обычно признак реального изменения.
• Попросите одного человека воспроизвести это в нормальной настройке. Если нужен специальный набор данных, кастомная ветка или «удачный» CI‑воркер, возможно, это дрейф в настройке тестов.
• Назначьте одного владельца и дату проверки. Без этого карантинные тесты сидят неделями, а потом снова всех удивляют.

Это простой триаж, но он меняет разговор. Люди перестают спорить на общие темы и начинают говорить о конкретном провале, уровне воздействия и следующем шаге.

Например, в signup‑потоке тест падает во вторник. Команда видит тот же сетевой сбой в трёх прогонах, один инженер воспроизводит локально, и путь блокирует новые аккаунты. Такой тест идёт прямо в приоритет. В тот же день тест экспорта отчёта падает один раз, никто не воспроизводит проблему, и релиз от него не зависит. Он может подождать нового прогона.

Если упавший тест не имеет ясной причины, повторяемости и владельца, он ещё не готов для реальной починки. Это просто шум со скриншотом.

Что делать дальше

Если нестабильные тесты еженедельно тормозят релизы, начните меньше, чем думаете. Не пытайтесь привести в порядок весь набор тестов сразу. Возьмите последний месяц провалов и найдите пять тестов, которые блокировали слияния, задерживали релиз или требовали повторных перезапусков. Этот короткий список обычно говорит больше, чем сто шумных сбоев.

Потом выберите один метод сортировки и придерживайтесь его каждую неделю. Держите метки простыми: product bug, test bug, test data, environment и timing. Точные названия важнее последовательности. Если команда меняет метки каждые пару дней, никто не увидит паттернов, и те же споры вернутся.

Еженедельная рутина лучше большого спринта по очистке. Обновляйте топ‑пять блокеров, просматривайте список карантина в один и тот же день каждую неделю, выводите тесты из карантина только после доказанной стабильности и удаляйте тесты, которые больше ничего важного не защищают.

Сделайте текущее состояние легко обозримым. Небольшой дашборд — достаточно. Показывайте количество провалов, какие тесты в карантине, как часто они падают и повлияли ли они на релиз. Один экран, который все читают, сокращает обвинения, потому что команда работает с одной картинкой.

Держите дашборд простым. Подойдёт таблица. Подойдёт панель в уже используемом инструменте. Суть не в полировке, а в том, чтобы никто не догадывался, какие сбои важны.

Если одни и те же пары провалов возвращаются, причина часто вне самого теста. Это могут быть плохие тестовые данные, медленные окружения, слабая очистка между прогонами или процесс релиза, который прячет поломки до позднего этапа. Внешний аудит может помочь. Oleg Sotnikov at oleg.is работает как Fractional CTO и консультант стартапов, и такие проблемы с релизами, CI/CD и очисткой инфраструктуры — как раз то, с чем он помогает командам.

Начните на этой неделе. Выберите пять блокеров, утвердите метки, назначьте фиксированный день просмотра карантина и опубликуйте один дашборд, который команда будет проверять перед следующим релизом.