Как стать автором
Обновить
inDriver
Международный сервис P2P-перевозок

Как мы создали собственный оркестратор запусков тестов и облегчили жизнь коллегам

Блог компании inDriver Тестирование IT-систем *Тестирование мобильных приложений *

Привет. Я Роман, Senior QA Automation Engineer в inDriver. Примерно год назад у нашей команды возникла идея разгрузить ручных тестировщиков и автоматизировать процесс коммуникации между ними, когда они хотят прогнать тесты. Результатом стало создание сервиса Porter по автоматизации очередей тестирования, о котором я расскажу в этой статье.

Содержание

Проблема ограниченности сред

Статью важно начать с пролога о том, как мы запускали тесты до оркестратора. Раньше ручные тестировщики занимали среды для тестирования в нужное для них время. Проблема в том, что сред было мало, а людей — много: 40 разработчиков, 20 тестировщиков, несколько девопсов иногда тестировали новые пайплайны. Плюс количество разработчиков только росло (их уже больше 100), мощностей не хватало и было непонятно, когда новые среды появятся.

А тесты хотели все. И мы жили в неопределенности сроков: 2 среды, десятки людей. Приходилось долго коммуницировать между собой по вопросам того, кто и когда будет что-то тестировать.

Расскажу типичный сценарий для тестировщика тех времен: сначала он заходил в проект в Teamcity и смотрел, какую ветку надо собрать для каждого сервиса. Потом шел в Jira и изучал задачу, которую прислал разработчик. Видел репозиторий, в который был сделан коммит, и собирал соответствующую ветку.

После тестировщик запускал master и ждал, когда посыпятся логи. Читал, что пошло не так или, наоборот, что все хорошо. Результаты отмечал в Jira. Это первый сценарий.

Второй сценарий проще — тесты прогонялись в отдельной ветке. Тестировщик собирал каждое приложение для определенной среды, потом запускал тесты на ветке и смотрел результат. Итоги снова переносил в Jira.

Подготовка стенда для тестирования приложения
Подготовка стенда для тестирования приложения

Мы решили автоматизировать процесс. Чтобы никто друг другу не мешал, пользователь мог бы просто зайти в интерфейс, запланировать задания для сборки приложений на определенных ветках и забыть о проблемах. Пришел, нажал и ушел. Позже вернулся, чтобы проверить результаты. И все.

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

Место не занимать

Сборкой приложений у нас занимается CI/CD-сервер. Тестировщик идет в задачу и смотрит, какие сервисы затронул разработчик. Далее идет в билд одного сервиса, собирает и запускает на нужной ветке, потом в билд другого сервиса и так далее. В конце запускает тесты на среде, на которой работают недавно собранные приложения. Понятно, что это долго и неудобно.

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

Я поставил тесты выполняться и ушел на рабочую встречу. Мой коллега спросил в чате, какая среда занята и открыл ту, на которой формально ничего не выполнялось. В итоге по возвращении я лишился логов и сборки для актуальной задачи. Нужно начинать все заново.

Реализовать нельзя подумать

Наше приложение основано на сервисной архитектуре, поэтому подготовка стенда намного сложнее, чем в монолите. Количество сервисов растет с каждым днем — сегодня 2, завтра — 4, представьте, сколько будет через 2 недели? Или может быть создано 4 ветки одной задачи для одного сервиса и CI не понимает, какую брать для сборки.

Все эти проблемы можно было решить такими способами:

1. Использовать существующие инструменты (например, Jenkins) 

От этого варианта мы отказались, поскольку у нас существует ограничение на CI/CD-сервер — требование использовать только TeamCity.

2. Интегрировать в Slack ботов, которые будут рулить процессом

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

3. Написать сервис по автоматизации очередей тестирования

Именно этот вариант мы и выбрали в итоге. В чем состоял план? Мы вырабатываем квалити-гейты: событие, которое срабатывает, когда разработчики пушат ветку и переводят задачи в другой статус, и генерирует в нашем сервисе сборку приложения и запуск тестов. Задача в том, чтобы быстрее дать фидбэк разработчику. В то же время мы оставляем ручникам возможность запускать сборки и тесты с нужными параметрами.

Работа над сервисом, который мы назвали Porter, началась чуть больше года назад и продолжается до сих пор. Стек слегка нестандартный — Kotlin на бэке и Vue.js на фронте. Одна из основных болей — интеграция с Teamcity. У них хороший API, который позволяет много сделать, но он не всегда понятен.

Главная страница со списком заданий
Главная страница со списком заданий

Положительный фидбэк и первые проблемы 

Главная задача сервиса реализована — Porter помогает полностью собрать инфраструктуру и запустить тесты. Это инструмент, заточенный на подготовку сервисной инфраструктуры и запуск тестов: Unit-тестов, API-тестов, UI-тестов и так далее. Решение не требует технических скиллов от пользователя — практически каждый новичок может прийти и накликать себе задания. Porter генерирует в себе отдельные шаги и распределяет их в виде заданий, которыми рулит.

Если упрощать, сервис прогоняет тесты и оставляет комментарии в Jira с их результатами. В ближайших планах реализовать возможность автоматически возвращать статус In Development.

Вот один из примеров работы:

Разработчик переводит готовую задачу в Ready for Testing, и с того момента она в руках тестировщика. Он делает все, что угодно: запускает ручные тесты, пишет тест-кейсы, прогоняет автоматизированные тесты. Это первый гейт, чтобы не отвлекать тестировщика от повседневных задач. Раньше разработчики ждали обратной связи от тестировщиков, пока те соберут все и прогонят тесты. А теперь тестировщик даже не знает, что задача в Ready For Testing, а тесты уже идут.

Еще пример:

Разработчик переводит задачу в Ready for Testing, но она не попадает к тестировщику, а сразу прогоняются тесты. Так мы уменьшаем время нахождения задачи в этом статусе. Тесты прогонятся, возможно, найдутся проблемы, задача вернется разработчику, и он сам все починит.

Пример задания в Porter
Пример задания в Porter

После запуска Porter у нас, в основном, были положительные отзывы пользователей. Мы поняли, что сервис нужен и он приносит людям пользу. Увидели, что стало меньше конфликтов в тестировании, связанных с тем, что кто-то занимал чужую среду и был вынужден еще раз планировать себе время.

Пример комментария в Jira после выполнения тестов
Пример комментария в Jira после выполнения тестов

Стало проще собирать статистику и экспериментировать. Наши девопсы часто экспериментируют со средами, меняют какие-то конфиги, правят в Teamcity пайплайны. Мы со своим фреймворком тоже делаем какие-то эксперименты: над многопоточностью, решениями в коде. Приходишь в Porter, накликиваешь 50 заданий, и они выполняются. А в это время можно заняться другими делами.

Планы на будущее и обратная связь

Мы добились главной цели — сделали тестирование проще, все ручные процессы не нужно держать в голове. Есть Porter, в котором легче работать тестировщикам и разработчикам, не вникая в пайплайн Teamcity.

Наши планы связаны с совершенствованием авторизации пользователей. Кроме того, мы планируем собирать статистику по переходу задачи от одного статуса в другой: сколько она задерживались в каждом статусе до Porter и после, отображать динамику на графике.

У сервиса большая популярность — у нас было 1 569 запусков заданий в 4 квартале 2020 года, в 1 квартале 2021 года — 2 207 запусков, во 2 квартале 2021 года — уже 3 107.

Буду рад вашей обратной связи или идеям по улучшению сервиса. Пишите в комментариях к этой публикации или стучитесь в личку @orlovrs.  

Теги:
Хабы:
Всего голосов 4: ↑4 и ↓0 +4
Просмотры 1.9K
Комментарии Комментарии 3

Информация

Дата основания
Местоположение
США
Сайт
indriver.com
Численность
1 001–5 000 человек
Дата регистрации
Представитель
Владислав Тетерин