Привет. Я Роман, 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 у нас, в основном, были положительные отзывы пользователей. Мы поняли, что сервис нужен и он приносит людям пользу. Увидели, что стало меньше конфликтов в тестировании, связанных с тем, что кто-то занимал чужую среду и был вынужден еще раз планировать себе время.
Стало проще собирать статистику и экспериментировать. Наши девопсы часто экспериментируют со средами, меняют какие-то конфиги, правят в Teamcity пайплайны. Мы со своим фреймворком тоже делаем какие-то эксперименты: над многопоточностью, решениями в коде. Приходишь в Porter, накликиваешь 50 заданий, и они выполняются. А в это время можно заняться другими делами.
Планы на будущее и обратная связь
Мы добились главной цели — сделали тестирование проще, все ручные процессы не нужно держать в голове. Есть Porter, в котором легче работать тестировщикам и разработчикам, не вникая в пайплайн Teamcity.
Наши планы связаны с совершенствованием авторизации пользователей. Кроме того, мы планируем собирать статистику по переходу задачи от одного статуса в другой: сколько она задерживались в каждом статусе до Porter и после, отображать динамику на графике.
У сервиса большая популярность — у нас было 1 569 запусков заданий в 4 квартале 2020 года, в 1 квартале 2021 года — 2 207 запусков, во 2 квартале 2021 года — уже 3 107.
Буду рад вашей обратной связи или идеям по улучшению сервиса. Пишите в комментариях к этой публикации или стучитесь в личку @orlovrs.
