QA Meetup от OneTwoTrip: автоматизация API

Продолжаем делиться докладами с нашего митапа в Петербурге, который прошёл 11 июля. Встречайте Виталия Герко с его опытом автоматизации API и рассказом, как и зачем в OneTwoTrip перешли с устоявшегося Ruby-фреймворка на единый для всех QA стек Playwright + TypeScript.

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

О спикере

Виталий Герко — QA Lead в команде «Отели». В контроле качества Виталий работает 8 лет, из них в тестировании 3 года, почти 2 из которых — в OneTwoTrip. Он первым из всех QA компании полностью покрыл проект автотестами (да, все 100% методов). Кроме того, Виталий активно развивает автоматизацию во всех слоях (API, UI, e2e) проекта «Отели». А ещё проводит обучение API автотестам на внутренних курсах OneTwoTrip Практикум.

Зачем нужен был новый фреймворк

QA Meetup от OneTwoTrip: автоматизация API

В 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-подход. А ещё в планах начать более массово писать автотесты сразу при тестировании задачи и минимизировать ручное тестирование.

QA Meetup от OneTwoTrip: автоматизация API
11
Начать дискуссию