Делимся свои опытом: как мы обеспечили быструю и безопасную миграцию с одной технологии на другую с использованием ИИ.
Технический долг в автотестах достиг точки, когда требовалось принимать решение. Прогоны сотен сценариев занимали больше 10 часов. Из-за этого 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 часов (включая настройку окружения и обучение).
Последующие тесты: ~1 час на тест по мере накопления опыта.
Общее время миграции: Уложились в запланированные сроки без срыва релизов.
Безопасность: Ни один тест не покинул периметр компании.
Главные технические итоги:
Время прогона упало с 10+ до 3 часов за счет оптимизаций Playwright и параллельного запуска.
Появилась поддержка Safari и мобильных устройств — покрытие стало полноценным.
Архитектура стала чище — разделение слоев (клиент → сервисы → тесты) повысило поддерживаемость.
Заключение
Миграция автотестов — это стратегический проект, требующий:
Четкой архитектуры на старте.
Постепенного подхода без остановки работы.
Правильных инструментов (в нашем случае — локальный ИИ как ассистент).
Инвестиций в обучение команды.
Playwright повысил скорость, покрытие и поддерживаемость наших автотестов. А локальный ИИ доказал, что может быть эффективным помощником в рутинных задачах без угрозы безопасности.
А вы сталкивались с миграцией автотестов? Какой подход использовали — полный рерайт, постепенный переход, конвертацию? Доверяете ли ИИ в таких задач
