Работа с техническим долгом с использованием ИИ: миграция автотестов с Cypress на Playwright

Технический долг в автоматических тестах достиг точки, когда требовалось принимать решение. Прогоны сотен сценариев занимали свыше 10 часов. Чтобы команда могла работать в нормальном ритме, требовалось сократить это время хотя бы до 3 часов - иначе мы теряем по 2–3 дня в каждом спринте.

Параллельно изменился пользовательский трафик: заметно выросла доля Safari на планшетах. Однако текущие автотесты написаны на Cypress, который технически не позволяет полноценно проверять работу в Safari на разных устройствах.

Все свелось к трем задачам:

• сохранить накопленные наработки, 
• сократить время выполнения тестов, 
• добавить поддержку планшетов и браузера Safari. 

Под эти требования лучше всего подошел Playwright: он остается в экосистеме TypeScript и имеет похожую структуру тестов. При этом важно было организовать «мягкую» миграцию - переносить тесты постепенно, не останавливая разработку.

Почему не руками?

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

Подход к миграции

1) Выстраиваем архитектуру будущих тестов

Первым шагом стала разработка архитектуры будущих API-тестов. Мы решили сохранить подход, к которому команда привыкла в Cypress -структуру в стиле Page Object Model.

• На верхнем уровне появился универсальный ApiClient.ts с базовыми запросами и параметрами.

 Пример:

• Для каждого бизнес-модуля создан отдельный файл (например, AddressBookMS.ts) с методами работы с сервисом и входными данными. 

Пример:

• Сценарии остались в привычных спецификациях (например, widgetContacts.spec.ts), которые покрывают регрессию.

Пример:

Структура четко разделяет тесты и объекты тестирования, позволяя быстро корректировать любой из элементов.

Если оставить «все в одном месте», как часто бывает при работе с новым инструментом, проект быстро становится неуправляемым. Такое разделение распределяет зоны ответственности: изменения в API вносятся в одном файле, а тесты при этом не ломаются. Это снизило риски при миграции и сделало код понятным даже новым участникам команды.

2) Планируем структуру сценариев

В Cypress используются глобальные функции describe и it, которые делают структуру тестов понятной и привычной. В Playwright аналогичная структура достигается с помощью test.describe и test, которые эмулируют это поведение. Асинхронность запросов, привычная в Cypress, компенсировалась дополнительными параметрами Playwright без потерь в скорости.

Пример

Для команды это означало минимальный «когнитивный барьер»: структура выглядела знакомо, и старые Cypress-тесты, и новые Playwright-сценарии имели единый стиль.

3) Используем ИИ для переноса атомарных тестов

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

Для пробы мы запустили небольшую модель на локальных машинах инженеров. Однако мощности не хватало, и для полноценной работы мы развернули на сервере более производительную модель Qwen3-32B.

Важно: ИИ не может «сам переписать тесты» - без понимания бизнес-контекста и участия инженеров он генерировал код, который не работал или не соответствовал задачам. Зато как ассистент он снимал рутину и ускорял работу QA инженера благодаря вспомогательным функциям:

• помогал адаптировать отдельные конструкции из Cypress в Playwright, 
• подсказывал варианты импорта или структуру тестов, 
• ускорял работу над повторяющимися задачами. 

Параллельно команда определяла подход и адаптировала сценарии под особенности продукта.

Результаты

• Первый модуль тестов переписали примерно за 7 часов: в это время шла и настройка окружения, и обучение использования Playwright. 
• Далее процесс ускорился- по мере того как инженеры набирали опыт, на переписывание каждого теста уходило около 1 часа. 
• Качество улучшалось по мере движения: найденные ошибки обсуждались в команде и фиксировались в тестах, а ИИ использовался для ускоренной доработки. 
• Безопасность была сохранена: локальное развертывание ИИ позволило использовать код и документацию без риска утечки. 

В итоге мы переписали весь пул в сжатые сроки, но главный итог - это даже не скорость миграции, а то, что команда сумела освоить новый инструмент без отрыва от работы.

Выводы

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

Именно сочетание этих факторов позволило нам успешно перейти с Cypress на Playwright и вывести продукт на новый технологический уровень.