QA Meetup от OneTwoTrip: автоматизация API
Продолжаем делиться докладами с нашего митапа в Петербурге, который прошёл 11 июля. Встречайте Виталия Герко с его опытом автоматизации API и рассказом, как и зачем в OneTwoTrip перешли с устоявшегося Ruby-фреймворка на единый для всех QA стек Playwright + TypeScript.
Видео выступления спикера можно посмотреть по ссылке.
О спикере
Виталий Герко — QA Lead в команде «Отели». В контроле качества Виталий работает 8 лет, из них в тестировании 3 года, почти 2 из которых — в OneTwoTrip. Он первым из всех QA компании полностью покрыл проект автотестами (да, все 100% методов). Кроме того, Виталий активно развивает автоматизацию во всех слоях (API, UI, e2e) проекта «Отели». А ещё проводит обучение API автотестам на внутренних курсах OneTwoTrip Практикум.
Зачем нужен был новый фреймворк
В OneTwoTrip уделяют большое внимание API автотестам. Думаю, все читатели этой статьи понимают, что такое пирамида тестирования. Пирамиду здорового и нездорового тестировщика вы можете посмотреть на 1:35. Команда OneTwoTrip придерживается именно классической версии пирамиды, где на втором месте после UNIT-автотестов находятся именно API автотесты.
Когда я только пришёл в компанию, очень хотел заниматься именно автотестами — это было логично в продуктовой компании, ведь автоматизация в долгосрочном периоде всегда выигрышна. Но два года назад API-автотесты были на Ruby, и это было не слишком удобно. Почему?
- Изолированность Ruby стека — он был только в автотестах API. И в целом стоит отметить специфичность этого языка программирования.
- Сложный вход для новичков, которым приходилось изучать два языка программирования, поскольку фронт-автотесты к тому времени уже были на JS/TS.
- Отсутствие большой экспертизы: разработчики и тестировщики, которые хорошо разбирались в Ruby, постепенно ушли из компании, опыт передан не был, и по сути все наработки были потеряны.
- Развитие проекта замедлилось, потому что новых автотестов писали не так много, в основном поддерживали имеющееся.
- В написанных автотестах скопилось легаси.
Решить все эти сложности можно было переходом на новый фреймворк.
Почему был выбран PlayWright + TypeScript
- Успешный опыт использования. К тому моменту, когда мы начали выбирать фреймворк, именно PlayWright + Typescript применяли во фронтовых автотестах. Мы попробовали эту связку в API-автотестах, и результат всех устроил.
- Это популярный фреймворк, который активно развивает компания Microsoft. У него хорошая понятная документация.
- Переход на единый язык написания автотестов для всех QA, чтобы облегчить вход новичкам.
- Единый фреймворк, конечно, с некоторыми особенностями для API и фронтовых автотестов.
- Единый стек с разработчиками, возможность подключать их к разработке API-автотестов и код-ревью.
Сложности при внедрении
Конечно, без проблем не обошлось. Во-первых, у команды отсутствовал опыт создания фреймворков с нуля, поэтому мы на старте приняли несколько не очень удачных архитектурных решений, так что пришлось что-то неоднократно переписывать. Кстати, на 9:07 можно посмотреть мем про многократный рефакторинг.
Во-вторых, новый фреймворк требовал обучения людей, но эту проблему решил OneTwoTrip Практикум, который веду в том числе и я. Там сотрудников знакомят со спецификой работы именно с фреймворком, используемым внутри компании.
Третьей сложностью стало большое количество рутинных действий при переписывании автотестов. Очень много методов и тестов было написано на Ruby, и всё это нужно было переписать — тут уж ничего не поделаешь.
Кроме того, не было единых стандартов — PR и code style. Но это тоже технический момент, с которым мы справились.
Ну и довольно стандартная проблема — сложность с выделением времени на автоматизацию.
Как фреймворк выглядит сейчас
К лету 2024-го с внедрения нового фреймворка прошло чуть больше года, и преимущества уже очевидны.
Его используют уже в 20 проектах, написано примерно 7 000 автотестов, есть удобный логгер и allure-отчёты о результатах прогонов. Появилась возможность запуска как по джобе с Jenkins, так и из Allure TestOps.
На максимум используется TypeScript, появился скрипт, который умеет автотипизировать модель ответа, то есть переводить JSON-схему ответа в интерфейс и затем использовать это, когда нужно обратиться к какому-либо параметру.
Мы научились автоматизировать веб-сокеты, причём как чат-бот, так и методы, используемые в поисках. А ещё интегрировали принцип снепшот автотестов из UI для тестирования корректности генерации маршрутных квитанций.
Но главное, что проект стал живым: он активно развивается, каждый день пишут новые тесты. И это показатель его правильной работы.
Автотестами на данный момент проверяем следующее:
- e2e-сценарии;
- валидацию входных параметров (query, тело запроса);
- валидацию схем ответов.
Кроме того, команда не боится писать множество негативных сценариев, так как в случае с API автотестами их прохождение практически мгновенное.
А если вам интересно посмотреть флоу написания автотестов команды OneTwoTrip, переходите на 15:49.
Планы на будущее
На данный момент развитие проекта Ruby приостановлено, но не все проекты до конца перешли на PlayWright. Нам необходимо ещё какое-то время, чтобы полностью перейти на новый фреймворк.
Кроме того, мы с командой планируем расширять и углублять покрытие: массово привлекать к написанию и ревью автотестов разработчиков и активнее развивать e2e-подход. А ещё в планах начать более массово писать автотесты сразу при тестировании задачи и минимизировать ручное тестирование.