Автоматизация без сбоев: как мы улучшили UI-тестирование
UI-автоматизация на проекте находилась в нестабильном состоянии:
-
архитектура фреймворка была построена с нарушением иерархии компонентов;
-
фреймворк Playwright использовался некорректно — применялись явные паузы вместо встроенных механизмов ожидания;
-
нестабильные способы взаимодействия с DOM.
Это порождало flaky-тесты (мигающие/нестабильные тесты) и регулярные ложные падения, подрывавшие доверие к автоматизации. Наш SDET-лид провёл архитектурный рефакторинг:
-
выстроил новую компонентную модель;
-
мигрировал существующие тесты без остановки процесса;
-
кратно ускорил написание новых автотестов.
Клиент
Энтерпрайз веб-портал — пользовательский веб-интерфейс для администраторов СУБД (высокая плотность таблиц, форм, модальных окон, минимум анимаций).
Задача
Бизнес-задачи
-
Повысить стабильность и предсказуемость UI-автотестов, чтобы команда могла полагаться на их результаты, а не перепроверять каждый упавший тест вручную.
-
Сократить время регрессионного прогона, высвободив ресурс команды автоматизации на наращивание покрытия.
Задача в контексте разработки
Устранить первопричины flaky-тестов (мигающих/нестабильных тестов):
-
явные паузы (time.sleep);
-
race conditions (состояние гонки);
-
зависимость от глобального состояния.
Перестроить архитектуру фреймворка с соблюдением иерархии компонентов и принципов разделения ответственности, чтобы обеспечить поддерживаемость при масштабировании.
Решение
Что планировали сделать
Полный архитектурный рефакторинг с параллельной миграцией существующих тестов — «замена двигателя в летящем самолёте», без остановки тестирования новых фич возможностей.
Гипотезы
Главная причина flaky-тестов — не сам инструмент Playwright, а его некорректное использование. Если внедрить семантические локаторы через программный интерфейс Locator API и заменить явные паузы на встроенные механизмы ожидания и assertions, детерминизм тестов вырастет до 95%+.
Почему решали именно так
Постепенное «подклеивание» старой архитектуры только увеличило бы технический долг. Требовалось создать новый «скелет» фреймворка (BaseComponent, инжекция Page через конструктор) и перевести на него тесты модулями, гарантируя стабильность через линтер-правила и шаблоны.
Этапы и числовые показатели
1. Аудит и дизайн новой архитектуры (1–2 недели):
-
анализ кодовой баз;
-
выявление антипаттернов;
-
проектирование BaseComponent и новой модели Page Object с включением нативного Page.
2. Создание «скелета» и пилотная миграция (2–3 недели):
-
реализация базовых компонентов;
-
перевод первых 10–15% тестов на новую архитектуру;
-
подтверждение гипотезы о детерминизме.
3. Масштабная миграция (4–6 недель):
-
поэтапный перевод всей базы тестов на новые паттерны;
-
параллельно — настройка Ruff (анализатор кода на ошибки и соответствие стандартам) и шаблонов компонентов, исключающих возврат к антипаттернам.
4. Интеграция отчётности и стабилизация (1–2 недели):
-
подключение инструмента для создания отчетов об автотестах и управления процессами тестирования Allure;
-
валидация прозрачности прогонов в облачной платформе Azure Pipelines;
-
финальная доводка.
Результат
- Время регрессионного прогона сокращено с 2 недель до 20 часов (экономия >70% времени).
- Достигнуто детерминированное поведение тестов: устранены ложные падения, вызванные race conditions (состоянием гонки) и явными паузами.
- Скорость разработки новых автотестов выросла до 3 автотестов в день.
- Автоматизировано 50% всех актуальных UI тест-кейсов (на момент завершения этапа миграции).
- Внедрены линтер-правила (Ruff) и шаблоны компонентов — риск возврата к антипаттернам сведён к минимуму.
Бизнес-эффект
-
Команда автоматизации получила стабильный и предсказуемый фреймворк: ложные падения больше не отвлекают инженеров от наращивания покрытия.
-
Время прогона сокращено на 70%, что позволяет запускать регресс чаще и быстрее получать обратную связь по качеству UI.
-
Заложен архитектурный фундамент для масштабирования: новая компонентная модель позволяет наращивать покрытие без экспоненциального роста затрат на поддержку.
-
Прямого влияния на релизный цикл на данном этапе нет (покрытие ещё не достигло целевого уровня, тесты запускает только команда автоматизации) — но созданы все условия для этого влияния в следующем цикле развития
Трудности
Миграция без остановки процесса
Стопор: нельзя было заморозить разработку новых тестов на время рефакторинга.
Решение:
-
чёткое разделение «старый код — новый код»;
-
приоритизация миграции критически нестабильных тестов в первую очередь.
Инерция команды
Стопор: инженеры привыкли к антипаттернам, и переход на новые паттерны требовал переучивания.
Решение:
-
применение линтер-правил, блокирующих старые подходы на уровне CI;
-
и демонстрация быстрых побед на пилотной группе тестов.
Технологии
Python, Pytest, Playwright, Ruff, Allure, Azure Pipelines.
