QA Meetup от OneTwoTrip: автоматизация тестирования чат-бота для техподдержки

11 июля в Санкт-Петербурге мы провели офлайн-митап для QA, на котором эксперты OneTwoTrip выступили с интересными докладами. В этой статье хотим подробно остановиться на выступлении Ивана Абрамова — он рассказал, как придумывал фреймворк для автоматизации чат-бота техподдержки сервиса. Интересный нюанс: это был его первый опыт, но настолько успешный, что им хочется делиться с профессиональным сообществом.

Иван Абрамов — Tech Lead QA Automation. В OneTwoTrip он работает 3 года и занимается настройкой тестирования (API, UI) в продуктовых командах на Playwright + Typescript, развитием автоматизации Jira и разработкой собственных утилит для тестирования.

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

Сегодня практически во всех крупных сервисах есть техподдержка, в которую ежедневно поступает огромное количество сообщений от пользователей. Чтобы немного разгрузить операторов, часть обращений можно перенаправлять на чат-ботов — их обучают давать ответы на регулярно возникающие у людей вопросы. А сотрудники службы поддержки концентрируются на решении более сложных запросов.

OneTwoTrip не исключение: в какой-то момент нам понадобился чат-бот. И он оказался очень эффективным — за полтора года удалось снизить процент заявок на специалистов поддержки примерно на 35%. Это довольно существенная доля, и количество сценариев, которые может решать чат-бот, продолжает расти. Проще говоря, он становится всё умнее. И в итоге потребовалось автоматизировать его тестирование, потому что на ручные тесты тратилось всё больше времени и сил.

Их оказалось несколько. Во-первых, в большинстве чат-ботов используется WebSocket. Это технология, которая предоставляет каналы для двусторонней передачи данных между клиентами и сервером в реальном времени. В отличие от классического протокола HTTP, который основан на запросах, WebSocket позволяет установить неразрывное соединение между клиентом и сервером.

Сложность в том, что с такой технологией команда прежде не сталкивалась. К тому же в OneTwoTrip используют PlayWright, в котором нет нативной поддержки работы с WebSocket. Коробочного решения под нужные задачи тоже не было. Так что нам пришлось самостоятельно придумывать универсальный «движок», то есть механизм для тестирования сценариев бота.

Вторая особенность заключалась в Socket.IO, на котором было основано API чат-бота. Это библиотека, обеспечивающая двустороннюю связь между клиентом и сервером, основанная на ивентах. Она построена поверх WebSocket. Почему же это проблема? Для консистентности с бэк-эндом нужно было использовать определённую версию, в которой не было типизации.

И наконец, у проекта чат-бота — botpress — имелся внутренний инструмент тестирования сценариев, но по непонятным причинам он не работал. Поэтому моя команда изобрела свой.

Она была довольно простой: в проекте с API-текстами и во фронтовом проекте, где лежит необходимый компонент, используется один язык — TypeScript. Поэтому я просто скопировал код с фронтэнд-репозитория, вставил его в нужный репозиторий, и всё заработало.

Шутка (не забываем, что моя фамилия — Абрамов, и я тоже в своём роде стендапер).

Но доля правды в ней есть: реализация действительно была по принципу Ctrl+C Ctrl+V. За основу мы взяли механизм взаимодействия фронтового компонента с сервером, но доработали его под нужды тестирования.

Для разработки решения потребовалось PlayWright (как тест-раннер), Npm-пакет Socket.IO и код из компонента фронтэнда.

В итоге мы придумали следующий флоу:

Команда создала сценарий, как пользователь будет идти по флоу (пример можно посмотреть на 6:41). На основании типов сообщений, которые передаются в сценарии, код понимает, какой флоу выполнять. Далее идёт проверка тела ответа бота по JSON-схеме и необходимых параметров (например, id клиента и тикета). Если схема или тип ответа не совпадает, заводится баг. Но в любом случае после каждого сценария (даже если он с багом) тикет закрывается, чтобы не копить тестовые сообщения в поддержке. Далее запускается следующий сценарий.

На данный момент моя команда уже написала необходимые сценарии для базового регресса при релизе новых версий бота и создала документацию по быстрому написанию сценариев в коде. Благодаря этому любой тестировщик или оператор службы поддержки при необходимости может зайти в репозиторий и самостоятельно написать сценарий решения какой-либо проблемы (конечно, по тестовой документации).

Сейчас проект передан команде поддержки, им занимается один из бэк-разработчиков и QA.

Главная задача на будущее — увеличить покрытие сценариев, чтобы чат-бот становился ещё более эффективным и мог решать всё больше запросов пользователей.

Также нужно поддерживать многопоточность. Сейчас чат-бот может обрабатывать сообщения только от нескольких пользователей одновременно, и мы, конечно, хотим увеличить его эффективность.

Наверняка в будущем появятся другие идеи, но пока ставка только на развитие тестовой модели.

И в конце выступления я делюсь с вами полезными советами (9:00). Вот они: