QA Meetup от OneTwoTrip: развитие автоматизации UI в компании

11 июля в Санкт-Петербурге мы провели офлайн-митап для QA, на котором эксперты OneTwoTrip выступили с интересными докладами. В этой статье хотим подробно остановиться на выступлении Виктора Усачёва, который поделился историей развития автоматизации UI в OneTwoTrip за последние четыре с половиной года.

Видео выступления спикера можно посмотреть по ссылке.

Виктор Усачев — QA Lead в команде Extranet (это внутренний проект OneTwoTrip, который позволяет подключать к сервису владельцев объектов размещения). Виктор в тестировании больше 9 лет, почти половину из которых работает в OneTwoTrip, где занимается развитием качества Extranet.

Когда я только пришёл в команду OneTwoTrip, тесты в сервисе писали на Kotlin с использованием фреймворка Selenide, лишь в паре проектов использовали UI тесты Javascript + Puppeteer. Всего в компании было чуть больше 300 тестов, что довольно мало.

Команда QA проанализировала ситуацию, и мы выявили следующие проблемы:

Первым делом мы с командой решили попробовать перейти на более нативный язык для фронтовой разработки (JavaScript) и попробовать фреймворк WebdriverIO. В это же время начались первые пробы использования JavaScript + Playwright в проектах, где ранее был Puppeteer.

Результаты были неплохими: всего за год количество тестов увеличилось вдвое: до 600 по всей компании. Но к концу 2021-года большинство проблем остались — изменился только фреймворк и язык. Плюс появилась новая сложность, связанная с WebdriverIO: не было возможности перезапускать упавшие тесты.

Было решено переписать все тесты e2e с WebdriverIO на Playwright, который к тому времени начали использовать в компании. И за год обновили порядка 400 тестов. Кроме того, во все проекты фронтенда внедрили Playwright как стандарт для UI-тестов. Эти изменения коснулись примерно десятка проектов, или около 600 тестов.

В результате фронтенд-разработчики наконец-то начали активнее помогать с написанием тестов — к концу 2022 года в сервисе их было более 1 000. Также благодаря стандартизации работы с фреймворком снизился порог входа. А перезапускать упавшие тесты оказалось возможным благодаря раннеру самого Playwright.

Плюсы Playwright оказались существенными:

Количество тестов по сравнению с 2020 годом выросло в десять раз: теперь их было более 3 000. Однако команда продолжала анализировать ситуацию и выявлять сложности. На некоторых из них я в своём докладе останавливался подробнее.

Проблема 1: разные версии Node.js и Playwright в фронтовых и e2e-проектах. Если разработчик работал над автотестами в нескольких проектах, он мог писать их на одной версии Playwright, а дальше в Jenkins они запускались на другой.

Чтобы решить эту проблему, разработчики берут докер-образ Playwright (на 7:25 есть qr-код, где можно подробно ознакомиться с контейнером), добавляют в контейнер нужную версию Node.js, которая используется в конкретном проекте, и в результате тесты прогоняются на зафиксированных версиях Node.js и Playwright. Чтобы эти образы было легко обновлять, их сборку вынесли в Jenkins, где разработчик указывает актуальную версию и собирает подходящий под проект контейнер.

Проблема 2: смещение на один пиксель при снепшот тестах (на 9:20 можно увидеть, как это выглядит). Проблема появилась из-за того, что разработчики и QA, которые пишут автотесты, не пользуются одной операционной системой, в результате движки рендерятся немного по-разному. Чтобы решить эту проблему, ребята написали скрипт обновления снепшотов во фронт-проекте (схему его действия можно увидеть на 10:24).

Результаты работы моей команды очень впечатляют: в 2024 году тестовая модель быстро развивается и пополняется, и по всей компании уже более 6 500 тестов (напомню, было 300).

Тесты есть на разных уровнях фронта — фактически команда создала собственную пирамиду тестирования. Тесты гоняются в pipeline.

Также QA добавили в регламент разработки написание автотестов на UI-слое. Старый функционал дорабатывается или же создаётся новый — пишут простой тест, который обрабатывает этот функционал и проверяет базовый кейс. Далее QA при необходимости расширяет тестовую модель.

Общие компоненты для работы с тестами теперь вынесены в отдельные пакеты Playwright-toolkit, где собраны концепции по работе с проектами на Playwright. Это позволяет стандартизировать работу. Также появился пакет docker-pw, в который собраны снепшоты в докер-образе.

Их сравнительно немного, но они довольно масштабные. Вот, что мы планируем: