Тест, который проходит только со второй попытки, ещё нельзя считать исправным. Сохраните ошибку первого запуска, момент действия и состояние приложения, затем сравните их с успешным повтором. Часто полезнее выяснить, чего первый запуск не дождался, чем увеличить число повторов.
Проводите разбор на тестовом окружении с искусственными данными. Не воспроизводите покупку, отправку письма или другую внешнюю операцию в production ради статистики. Перед повтором выясните, успела ли первая попытка создать объект: неопределённый результат может превратить повторный тест в дубль заказа.
Что изменилось между попытками
- Появилась ли запись, которую создала первая попытка?
- Успела ли загрузиться форма или завершиться запрос?
- Прогрелся ли сервис, справочник или кэш?
- Сменился ли процесс тестирования и его локальное состояние?
Сравнивайте один и тот же сценарий на одной версии приложения, сохранив идентификаторы запуска. Успех после повторного входа и успех после повторной проверки текста — разные события. Случайный порядок ответов, анимация и задержка фоновой работы дают похожий симптом, но требуют разных исправлений. Отметьте первое расхождение, не только последнюю ошибку ожидания.
Два разных повтора
| Механизм | Что повторяется | Чем рискуем |
|---|---|---|
| Повтор проверки состояния | Наблюдение результата | Слишком слабым условием успеха |
| Повтор всего сценария | Подготовка и действия | Повторными побочными эффектами |
| Ручной перезапуск CI | Весь запуск | Потерей свидетельств первой ошибки |
В Playwright тест, упавший сначала и прошедший при повторе, отмечается как flaky. При сбое рабочий процесс и браузер отбрасываются; следующий запуск может получить новое окружение. Это описано в документации Retries, проверенной 11 октября 2026 года. Поэтому второй успех не доказывает, что состояние первой попытки стало корректным.
Ждать нужно признак готовности
Условное правило ожидания:
плохо: подождать фиксированную паузу и нажать
лучше: дождаться разрешённой кнопки
затем: выполнить действие один раз
после: проверить сохранённый результатПризнак должен соответствовать цели. Исчезнувший индикатор загрузки не всегда означает завершение сохранения; наличие строки в таблице не доказывает нужное значение. Для изменения записи проверяйте подтверждённое состояние этой записи, а не любой успешный ответ страницы. Ограничьте ожидание понятным сроком и выводите, какого условия не удалось дождаться.
Если тест зависит от общего справочника, подготавливайте его явно. Если гонка возникает между двумя запросами приложения, исправляйте порядок обработки или отбрасывание устаревшего ответа в приложении: дополнительная пауза теста только скроет дефект. Для анимации используйте проверку готовности элемента, не случайный запас секунд.
Как проверить найденную причину
- Воспроизвести исходное расхождение с сохранёнными артефактами.
- Изменить одно условие, которое объясняет ошибку.
- Запустить серию независимых проверок без маскирующего перезапуска.
- Вернуть обычный параллелизм и проверить отсутствие общей записи.
- Зафиксировать результат и остаточные нестабильные случаи.
Количество запусков выберите под частоту исходного сбоя и стоимость теста; несколько успехов не дают гарантии отсутствия редкой гонки. В отчёте показывайте первую неудачу даже при итоговом успехе. Временный повтор допустим как согласованная мера, но у него должны быть владелец, причина и срок пересмотра.
Для команды оставьте короткое объяснение: какое состояние отсутствовало, почему повтор помогал и какое наблюдаемое условие теперь заменяет случайное ожидание. Такая запись полезнее строки «увеличили тайм-аут»: при следующем изменении интерфейса будет понятно, что именно тест обязан подтверждать.