Всем привет! 

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

В нашей компании начальный этап и рост количества тестов принесли множество вызовов, особенно в мониторинге. Одной из главных сложностей стало создание полноценного и оперативного обзора состояния продукта. Стандартные TMS-системы не всегда позволяют гибко собирать и визуализировать нужные данные, такие как покрытие API тестами, тренды ошибок и готовность к релизу. Это часто затрудняло анализ и повышало риск выпуска недостаточно протестированных функций.

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

В этой статье я расскажу о наших основных инструментах и подходах, которые помогают нам держать под контролем все аспекты тестируемого продукта — от уведомлений в Telegram и отчетов по API-покрытию до аналитики и визуализаций в Grafana.

Содержание:

• Давайте знакомиться

• Инструменты

• Источник данных

• Визуализация в Grafana

• Уведомления в Telegram

• Отчеты по покрытию API тестов

• Статистика и отчетность в TMS

• UI для конфигурации и запуска тестов в CI

• UI для общего обзора состояния тестов и саммари по готовности к выпуску

• Swagger Diff и Models Diff

• Отслеживание задач в спринте

• Заключение

Кто я?

Давайте сначала познакомимся. Меня зовут Александр, и я 19 лет работаю в тестировании. В основном я занимаюсь unit, API, UI, E2E и нагрузочным тестированием. Мой основной стек — это JS, TS и Python. Также я преподаю в университете курс автоматизации тестирования и консультирую компании по вопросам внедрения автотестов.

Инструменты

• Telegram — отправка отчетов и уведомлений команде.

• Grafana — визуализация данных для наглядного представления состояния тестирования и ключевых метрик.

• Supabase — база данных для хранения и обработки данных тестирования.

• Python (библиотеки Requests, Pytest) — написание и выполнение API тестов.

• Playwright (TypeScript) — инструмент для UI тестирования.

• Allure — TMS для хранения отчетов, истории запусков и логов тестов.

• GitLab CI — настройка и управление процессами CI/CD.

Источник данных

Перед тем как начать, немного расскажу о том, что для нас является источником данных для получения представления о тестируемой системе:

• База данных (БД)— ядро, где хранится большая часть информации.

• Allure TestOps — современные TMS предоставляют API для взаимодействия, поэтому конкретная TMS может варьироваться.

• GitLab CI — платформа для управления процессом CI/CD.

Визуализация в Grafana

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

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

Более подробно о том, как мы используем Grafana + источник данных я описывал здесь.

Уведомления в Telegram

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

Пример одного из наших уведомлений:

Список уведомлений, которые мы используем:

• Результат прохождения пайплайна в CI — уведомление с результатом выполнения тестов, которое помогает команде оперативно узнавать о статусе сборки.

• Отчет о состоянии тестируемой системы — актуальная сводка о текущем состоянии продукта, включающая информацию о покрытии тестами, найденных ошибках и других критичных метриках.

• Отчет о текущем спринте — включает количество открытых багов, активных задач, «застрявших» задач на этапах In progress/Review, а также задачи, которые были закрыты без прохождения тестирования.

Отчеты по покрытию API тестов

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

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

Наш отчет. И еще один.  

Статистика и отчетность в TMS

Возможно, у вас возникнет вопрос: почему мы используем Grafana и базу данных, а не Allure, ведь в этой TMS также есть отчеты и статистика. На данный момент (ноябрь 2024 года) мы не встречали TMS, которая обеспечивала бы столь гибкие возможности для создания и настройки дашбордов, хранения данных и отображения, например, покрытия API тестами. Поэтому Allure мы используем для хранения истории тестов, логов и ручных тест-кейсов. Но вы можете вытянуть дополнительную информацию, которая вам может понадобиться через API TMS. 

UI для конфигурации и запуска тестов в CI

E2E тесты — это один из основных индикаторов того, что сборка готова к выпуску в продакшен. Без успешного прохождения этих тестов мы не можем выпустить релиз. В процессе работы мы столкнулись с рядом проблем:

• Перед проведением E2E тестов система должна быть приведена в рабочее состояние. Иногда, из-за особенностей тестовой среды, подготовка требует ручных действий, иначе тесты могут упасть, и это приведет к потере времени на диагностику ошибок.

• У тестов множество входных параметров, которые мы задаем через переменные (VARIABLES) в GitLab CI. Но когда таких параметров много или требуется их валидация, управление становится сложным и неудобным. К тому же приходится поддерживать актуальность документации, как README или локальная Wiki.

Чтобы решить эти проблемы, мы разработали собственный UI для конфигурации и запуска тестов. Он автоматически подсвечивает моменты, требующие подготовки системы, и, если все готово, позволяет запустить тесты в CI или скопировать команду для запуска в CLI.

Этот инструмент ускорил проверки и дал разработчикам возможность быстро проверить текущую сборку, не беспокоясь о том, как настроить параметры в GitLab или какие данные использовать для локального запуска.

Абстрактный пример конфигурации тестов. Следующая страница (после нажатие кнопки «View») позволяет увидеть проблемные места, которые выделяются визуально, что позволяет команде сразу определить потенциальные препятствия для тестов. Также на этой странице предусмотрена возможность запуска E2E тестов напрямую через GitLab CI:

UI для общего обзора состояния тестов и саммари по готовности к выпуску

Нам пришлось разработать еще один собственный UI, чтобы решить несколько ключевых задач. Вот проблемы, с которыми мы столкнулись:

• Перед выпуском сборки нам важно собрать общее саммари по состоянию всего проекта. В нашем случае это два бэкенда (покрытые unit-тестами), три фронтенда (с UI-тестами), а также API и E2E тесты.

• Любой член команды должен иметь возможность легко увидеть, есть ли на текущий момент блокирующие проблемы.

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

Также стоит отметить, что функционал этого UI частично дублирует возможности раздела «Визуализация в Grafana». Мы провели анализ, составили сравнительные таблицы и, взвесив все за и против, решили реализовать собственное решение для этих задач. ?

Swagger и Models Diff: контроль изменений в API

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

Models Diff используется в API тестах и проверяет соответствие моделей в тестах и Swagger. Разницу можно получить в виде собственного отчета, а также визуализировать на дашбордах Grafana.

Swagger Diff запускается перед выкладкой, сравнивая, например, dev и prod стенды. Этот инструмент позволяет своевременно выявлять изменения и минимизировать риски, связанные с неожиданными изменениями в API.

Отслеживание задач в спринте

В нашей команде мы стараемся быть в курсе текущего спринта. Здесь я бы хотел выделить информацию, которая относится к QA

• количество багов

• проблемные тикеты (долго висят в In progress или Review)

• задачи, которые были закрыты без QA. Например, не были назначены на наш отдел или не были выполнены все условия (протестировано/добавлены тест кейсы и так далее)

Заключение

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

• Ускорение выпусков билдов

• Прозрачный отчет в текущем моменте тестируемой системы

• Возможность участвовать любому члену команды в тестировании - запускать любой из тестов по пирамиде тестирования и получать быстрый результат.

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