Привет! Меня зовут Катя, я тестировщик.

Когда я только пришла работать в 2ГИС, я занималась тестированием фронтенда карты. Всё было чётко и понятно, ведь был один проект. Но когда я переключилась на тестирование бэкенда, ситуация радикально изменилась. В работу команды, связанной с пользовательским контентом, входило 30+ проектов разного размера и приоритета, с разным уровнем покрытия тестами. Из общего только, что все проекты разработаны на Go, а автотесты — на Python.

Ситуация была настоящий «омагад». Даже опытным сотрудникам было сложно ориентироваться в каждом проекте, не говоря о новом члене команды. Это приводило к неприятным последствиям. Например, перед внедрением фич мы часто не могли прогнозировать время тестирования и оценивать необходимые усилия. Бизнесу давались одни сроки, но на практике они сдвигались из-за неожиданно обнаруженных проблем. В результате доставка фич на бой затягивалась или срывались сроки, нарастал техдолг, и вся эта вакханалия повторялась по кругу.

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

Первая попытка: ручное управление

Наша первая идея была проста: составить таблицу в Confluence и вручную фиксировать всю информацию о проектах — их статус, покрытие тестами, версии библиотек и так далее.

Скриншот всей таблицы, чтобы оценить масштаб

Какие данные собирали в таблицу:

название проекта, ответственный, сценарии (количество тестов), наличие плагина GitLab Reporter и New Schemas (схемы из district 42), инфраструктурные тесты (проверяли, как ведёт себя приложение при недоступности сторонних сервисов), Perf-тесты (нагрузочные тесты), TestOps (отчёты в Allure), количество перезапусков тестов в джобе, наличие в тестах версии Python 3.10, обновление библиотек командой pip-compile, E2E Linter (приведён ли кода к нашим правилам), Tech Debt QA (количество тикетов в Jira по техническому долгу), количество Flaky-тестов, дата обновления.

На практике всё обернулось провалом:

Всё нужно было заполнять вручную. Это отнимало кучу времени, а учитывая, что проекты постоянно обновлялись, таблица быстро теряла актуальность.
Огромный объём информации. Таблицей было неудобно пользоваться, вёрстка могла «поехать», случайные клики удаляли данные.
Не было доверия. Многие записи были устаревшими. Например, в 2023 году дата последнего обновления на некоторых проектах значилась 2022 годом, а в некоторых строках её не было вовсе.

В итоге таблица не прижилась. Мы вернулись к нашему хаосу, теперь уже удвоенному: ведь тестировщиков стало к тому моменту ещё больше. Осознали: нужно автоматизировать процесс.

Что мы сделали дальше

Возвратились к главной цели: мы хотели упростить мониторинг проектов и сделать его актуальным. Для этого мы сформулировали четыре понятных шага:

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

Шаг 1. Очистка от информационного шума

Выметая старый хаос из таблицы, мы определили, что нам действительно важно:

Среда выполнения тестов. Какие плагины используются, версии библиотек.
Время прохождения пайплайнов. Это критично, так как от этого зависит общий цикл релиза.
Количество QA-техдолга. Какие проекты требуют доработок перед запуском новой фичи.
Дополнительные джобы/настройки, которые упрощают работу – например, джоба, проверяющая новые тесты на flaky или рераны упавших тестов внутри джобы с тестами.

Лишние данные, такие как имя ответственного за проект (часто меняется) или дата последнего обновления (неактуальная), полетели в корзину.

Шаг 2. Автоматизация — наш лучший друг

Дальше перешли к автоматизации. Ниже несколько инструментов, которые мы использовали.

1. vedro-telemetry

Работая с фреймворком Vedro, мы обнаружили встроенный плагин для сбора телеметрии. Он автоматически собирает:

список используемых плагинов и их версии,
количество автоматизированных тестов.

В Grafana мы сразу видим, какой проект устарел и где нужно ускориться. Это особенно удобно, поскольку vedro использует и фронтенд, и бэкенд.

Grafana позволяет настраивать дашборд по-разному. Это может быть общая сводная по всем направлениям, включая бэк и фронт для оценки ситуации по Web-отделу в целом

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

2. Freshdeps: автоматическое обновление зависимостей

Чтобы обновлять зависимости, мы внедрили бот Freshdeps. Он:

Запускается по расписанию в GitLab CI.
Компилирует файлы requirements.txt через pip-tools.
Создаёт merge request с обновлёнными зависимостями.
Тегает ответственного для проверки.

Если тесты проходят успешно, обновления быстро вливаются в мастер. Если что-то падает, бот ждёт исправления, не создавая новых MR. Это устраняет панику, когда одно и то же обновление клонируется несколько раз.

3. Pipeline Metrics: собственный инструмент

Мы разработали и выложили в опенсорс инструмент Pipeline Metrics , который собирает метрики по результатам прохождения e2e-тестов в Pipeline в Gitlab CI:

время начала и окончания выполнения пайплайнов,
количество джоб,
общее время тестирования.

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

Данные по столбцам

pipelines — количество пайплайнов на мастере в указанный промежуток времени,
jobs — количество e2e-джоб на последнем пайплайне мастера,
start pipeline — e2e start — время, которое проходит от старта пайлайна до начала e2e-тестов в 95 перцинтиле,
e2e — время, которое проходит от начала первой e2e-джобы до конца последней в 95 перцинтиле (с учётом рестартов и без),
job diff — разница между самой короткой/долгой джобами в 95 перцинтиле

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

Шаг 3. Укрощение таблицы

Несмотря на автоматизацию, часть данных всё равно приходится заполнять вручную. Мы упростили этот процесс:

Сократили количество столбцов до самого важного.
Добавили визуальные элементы, например, явно разделили проекты по приоритетам и заменили чекбоксы на сердечки.

Сердечки оказались полезны: в отличие от чекбоксов их состояние можно отследить в истории изменений Confluence. А ещё они внезапно стали радовать глаз во время планирования.

Добавили метрики и телеметрию (столбец "Python" переехал в дашборд телеметрии). В тикетах по техническому долгу выделили несколько категорий: coverage (тестовое покрытие) и flaky (нестабильные тесты), и все остальные. Поняли, что важно смотреть, какие используем mocks (моки). Также добавили разделение проектов по приоритетам: проекты с наивысшим приоритетом (P0) теперь располагаются сверху, причём эти группы редактируются редко. — Добавили метрики и телеметрию (столбец "Python" переехал в дашборд телеметрии). В тикетах по техническому долгу выделили несколько категорий: **coverage** (тестовое покрытие) и **flaky** (нестабильные тесты), и все остальные. Поняли, что важно смотреть, какие используем **mocks** (моки). Также добавили разделение проектов по приоритетам: проекты с наивысшим приоритетом (P0) теперь располагаются сверху, причём эти группы редактируются редко.

Шаг 4. Налаженный регулярный процесс

Сначала мы собирались раз в месяц, чтобы выработать привычку: что-то изменил в проекте— сразу вноси изменения в таблицу, потому что это действительно важно. Мы даже распределяли задачи между собой, фиксировали, кто что должен сделать, и старались отслеживать выполнение после каждой встречи.

Сейчас встречи проходят реже, но мы чаще обращаемся к общей таблице во время планирования. Обновления происходят автоматически: если кто-то что-то меняет, правки вносятся сразу.

Шаг 5. Бонус — рейтинг проектов

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

Это оказалось гораздо нагляднее, чем просто смотреть закрытые тикеты в Jira. Графики прогресса действительно мотивируют и дают более понятное представление о том, как движутся дела. Изначально мы делали это просто ради интереса, но в итоге оказалось, что подход реально полезен.

Результаты

После внедрения системы мы:

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

Из задач, которые ещё предстоит решить — пока что все данные хранятся всё же в разных источниках: два дашборда в Grafana с результатами из vedro-telemetry и собственного инструмента Pipeline Metrics + табличка, заполняемая вручную + фоновый Freshdeps, который периодически создаёт merge request’ы. Мы мечтаем объединить их в один дашборд, об этом расскажу позже. Но даже с текущим решением результат уже вдохновляет.

Захочешь развивать сервисы вместе с нами — смотри открытые вакансии. А ещё мы делимся опытом в QA в телеграм-канале, заглядывай.

Наводим порядок в мониторинге 30+ проектов