Всем привет! Меня зовут Антон Лосев, и я QA Lead в компании AXENIX.

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

Инструменты

Для начала давайте поговорим про инструменты. Тут я хотел бы обсудить достаточно типичный набор, который используют большинство тестировщиков, у которых на проекте REST, очереди сообщений и базы данных, а именно: Postman, Offset Explorer, DBeaver. Я расскажу, каким функционалом этих приложений я стал активно пользоваться для регресса, и какая альтернатива для данного набора инструментов есть..

Задача, стоящая перед нами в рамках регресса

Давайте представим, что перед нами стоит задача в рамках регресса провести тестирование интеграции десятка сервисов между собой. Триггером для взаимодействия будет выступать REST, а сервисы между собой будут взаимодействовать посредством очередей сообщений; результаты работы будут записаны в БД.

Выслушав легенду, вы, наверное, увидели схематичное описание вашего проекта. Как в данной ситуации регресс проводит большинство мануальных тестировщиков? Прокидывают сообщение через Postman, идут в Offset Explorer и ищут публикацию по каким-то условиям, переходят в DBeaver и выполняют самый простой SELECT с условием на выдачу ожидаемого результата.

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

Что я сделал, оказавшись в данной ситуации

Для начала в Postman я стал активно использовать скрипты и переменные. Тут вы можете сразу меня остановить и сказать, что в заголовке к этой статье написано, что кода я не знаю. Так оно и есть: для написания скриптов я использовал типовые скрипты Postman — snippets, а также крайне широко применял встроенный ИИ.

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

В данной ситуации я доработал SELECT дополнительной логикой. В результате выполнения скрипта я стал выводить не просто данные или количество, а именно осознанный «лог», который не надо было обдумывать. Он прямо говорит, что кейс пройден или провален, и какой это именно шаг.

Муки и принятие факта, что нет предела совершенства

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

Я попробовал решить проблему переключения банальным увеличением количества мониторов. Это, конечно, удобно, да и выглядит немного футуристично, но супруга сказала, что со стороны обывателя выглядит, как будто я охранник торгового центра.

Пришло понимание, что надо сделать шаг вперёд и ещё как-то упростить прохождение кейсов. Для себя я выделил две оставшиеся проблемы: первая — это необходимость перехода между инструментами, вторая — это постоянная необходимость что-то копировать и вставлять. К сожалению, к этому моменту знаний кода у меня не прибавилось, и я начал искать альтернативные пути решения проблемы.

Чтобы максимально быстро познакомить вас с BrOK, давайте я коротко расскажу о нём.

После установки и запуска приложения мы увидим пять разделов. В первую очередь нас будет интересовать раздел "Сценарии", однако и другие мы не можем обойти стороной. Так, название вкладки "Рабочий стол" полностью отражает содержание экранной формы. Здесь содержатся ваши избранные очереди, шаблоны и сценарии.

Вкладка "REST" содержит в себе функционал взаимодействия через стандартные протоколы, такие как HTTP, и имеет крайне развитый функционал с возможностью переноса данных из Postman и загрузкой коллекций OpenAPI.

Название вкладки "Брокеры" также отражает суть функционала. Экранная форма содержит в себе все инструменты по взаимодействию с брокерами сообщений, такими как Kafka, Artemis, Rabbit, Redis, NATS. У вкладки "Управление" основной задачей является администрирование всех поддерживаемых брокеров сообщений и их компонентов.

Далее необходимо подготовить BrOK к работе в нашей среде разработки. Не вдаваясь в подробности, скажу, что во вкладке "Управление" необходимо создать подключение к брокеру сообщений. Далее во вкладке "Брокеры" нужно добавить топики, с которыми в дальнейшем планируется работать, в избранное и добавить шаблоны тестовых публикаций. Аналогично со вкладкой "REST": необходимо создать запросы, которые в дальнейшем планируется использовать при тестировании. Во вкладке "Сценарии" на текущем этапе нас будет интересовать раздел "Соединения"; тут мы укажем креды нашего SQL-соединения.

 Тут может возникнуть вопрос: как о таком важном этапе, как настройка окружения, можно сказать так вскользь? Ответ крайне простой: BrOK имеет знакомую архитектуру, и поэтому работать с ним не составляет труда, особенно если аналогичные операции выполнялись ранее в DBeaver, Postman, Offset Explorer.

 Наконец-то мы добрались до вкладки "Сценарии". Тут мы воспользуемся LowCode-конструктором для создания воркфлоу процесса, разработанного на основе ручного тест-кейса. Здесь мы будем отправлять или читать сообщения брокера, выполнять SQL-запросы, отправлять HTTP-запросы или выполнять Groovy-скрипты. И повторюсь, что для этого нам не понадобится установка дополнительных плагинов. Именно тут BrOK объединяет релевантные возможности DBeaver, Postman, Offset Explorer, RedisDesktopManager, ActiveMQ Artemis Console, NATS Tools.

 Перед "автоматизацией" наших ТК нам необходимо создать в BrOK коллекцию запросов, которые будут так или иначе использоваться при проведении тестирования и выставления результатов тестов. Для создания своей коллекции и её наполнения необходимо перейти во вкладку "REST". Думаю, тут объяснения излишни, так как функционал максимально понятен и аналогичен процессам в Postman или Insomnia.

 Далее нам необходимо перейти во вкладку "Сценарии" и в ней перейти в подраздел "Соединения". Тут мы создадим наше будущее соединение к базе данных, используемой при тестировании. Мы ранее точно настраивали DBeaver или DataGrip; в BrOK все аналогично.

Для "автоматизации" кейса нам необходимо создать сценарий, в рамках которого BrOK не только за нас выполнит все шаги, но и проставит отметку об успешном прохождении кейса в TMS. Данный функционал, как я и говорил, сильно напоминает функционал потоков в Postman, но у BrOK он более широкий, без необходимости самостоятельных апгрейдов и зависимостей от стороннего функционала.

Переходим в подраздел "Список сценариев" и добавляем сценарий.

После создания самого сценария нам необходимо в него войти и наполнить. Наполнение происходит путем перетаскивания тасок из панели в рабочую область. Нам необходимо перетащить таски REST, SQL, слушателя и исключающего шлюза.

Далее выстраиваем таски в цепочку: REST -> слушатель -> SQL -> шлюз -> выходы на две таски REST.

Первая таска "REST" содержит в себе наше сообщение-триггер, в результате получения которого будет запущена логика процесса.

Таска "Слушатель" выполняет функцию мониторинга очереди сообщений, в ней мы зададим условие поиска публикации по заголовкам.

Таска "SQL" выполнит SELECT, в рамках которого мы запустим поиск тестовой записи по условию, а также в данной таске зададим маппинг получаемых переменных.

В шлюзе мы будем проверять, правильные ли атрибуты были добавлены в БД. Для этого нам необходимо написать скрипт на языке expression language.  

НО мы же не знаем код. Тут нас спасет ИИ. Вот пример промта: "Мне нужно выражение на языке Expression Language (EL) в Java, которое сравнивает переменную user_id со значением 13."

Нажимаем кнопку «Сохранить» и после выхода из окна редактирования нажимаем кнопку запуска сценария. Ну и на этом, собственно, всё. То, что ранее мы относительно долго, но точно мучительно делали руками, теперь за нас сделает машина.

Функционал BrOK в части сценариев имеет, конечно, больший потенциал и возможность покрытия куда более сложных сценариев, но для себя я выполнил самую главную задачу: больше я не буду заниматься рутиной, теперь за меня это сделает BrOK.

Краткие результаты

Что же могу сказать в итоге. BrOK значительно ускорил прохождение регресса, так как теперь я могу просто запустить несколько не «пересекающихся» тестов и, по сути, проверять смежный функционал параллельно. Ранее такое было недоступно, так как я не Гай Юлий Цезарь. Также BrOK повысил качество, исключив человеческий фактор. Если перевести это всё в метрики, то можно сказать, что при параллельном тестировании сервисов затраченное время уменьшилось в разы. Нажав несколько кнопок, кейсы будут выполнены автоматически за считанные секунды, в отличие от ручного прохождения, измеряемого в минутах, часах и слезах. В ситуации с последовательным запуском кейсов ускорение также значительно, но к сожалению, не такое громадное, так как я заметил, что от момента запуска до фактического выполнения сценария проходит время, и иногда до пяти секунд. В разрезе сотен кейсов это складывается в значительную цифру. Postman, DBeaver, Offset Explorer — это инструменты, проверенные временем, но нет универсальных инструментов под все ситуации, поэтому BrOK может оказаться верным помощником при регрессионном тестировании и значительно ускорить вашу работу.

P.S. Всех буду рад видеть на нашем онлайн-митапе QA Day 20 ноября. Там будем обсуждать возможность и необходимость применения альтернативных инструментов в тестировании. Чтобы принять участие, зарегистрируйтесь по ссылке https://t.me/axenixqaday.