1. Создание базовой инфраструктуры 📦
🔸 Настройка нового фреймворка: Установите и настройте все необходимые инструменты и зависимости.
🔸 Написание базовых тестов: Создайте несколько простых тестов для проверки работоспособности нового фреймворка.
2. Идентификация тестовых наборов 🔍
🔸 Определите приоритеты: Нужно понять, какие тестовые наборы нужно перенести в первую очередь.
🔸 Решение о текущих тестах: Важно решить, что будет с текущими тестами. Будете ли вы их временно запускать и поддерживать? Или вообще их не переносить, законсервировать и использовать новый фреймворк только для новых тестов?
3. Тренинги и документация 📚
🔸 Проведение тренингов: Если нужно, проведите тренинги команды для эффективной работы с новым фреймворком.
🔸 Создание документации: Опишите документацию, гайдлайны по работе и типовые кейсы для команды.
4. Мониторинг и показатели 📊
🔸 Установите метрики: У вас должны быть показатели по срокам перехода и качеству тестов на новом фреймворке, которые нужно соблюдать.
5. Пошаговая миграция 🛠
🔸 Перенос общих утилит и хелперов: Начните с переноса утилит и вспомогательных классов, которые используются в ваших тестах.
🔸 Пошаговая миграция тестов: Переносите тесты поэтапно, начиная с наиболее простых. Тестируйте каждый этап миграции.
6. Подготовка инфраструктуры 🧑💻
🔸 Подготовьте фреймворк: До переноса тестов или в параллель нужно также подготовить фреймворк для полноценной работы, например, проверить интеграцию с CI/CD
✅ Валидация и тестирование
🔸 Сравнение результатов: Сравните результаты тестов на старом и новом фреймворке, убедитесь, что они совпадают. А новый фреймворк в чем то лучше, иначе зачем было его внедрять 🤔
🔸 Рефакторинг: После успешной миграции проведите рефакторинг, чтобы оптимизировать тесты и код.
🔄 Постоянное улучшение
🔸 Обратная связь: Собирайте отзывы от команды, выявляйте проблемы и решайте их.
🔸 Мониторинг и поддержка: Регулярно обновляйте фреймворк и следите за его развитием.
Мой личный кейс:
Мне нужно было перейти от старого фреймворка на Java 8/11 с BDD (JBehave) на что-то более новое и удобное. Заказчику было легко продать тот же BDD, а вот многие инженеры, наоборот, не любят BDD подход. Моим решением было создать базовый фреймворк на Rest Assured + BDD (Cucumber) сначала для API тестирования. Базовый фреймворк включал утилиты, хелперы и базовые шаги. Эту библиотеку можно было добавить как зависимость и переиспользовать базовые шаги как BDD методы, так и обычные JUnit/TestNG, что позволило решить проблему с противниками BDD подхода.
После этого я реализовал основные сценарии для одного из новых проектов, написал гайдлайны, собрал команду и обучил ее работе с фреймворком. В дальнейшем я практически не занимался самими автотестами, а больше работал как SDET, улучшая фреймворк, реализуя новые идеи, исправляя дефекты и внедряя фреймворк в других командах. В конечном итоге фреймворком пользовались порядка 10 инженеров из 5 команд.
✨ Пишите в комментариях про свой опыт по рефакторингу тестового фреймворка или по миграции с одного тестового фреймворка на другой.
❓ Или если у вас есть вопросы или сомнения по смене фреймворка - смело задавайте!