На старте проекта у нас не было ни одного автотеста. При этом продукт уже представлял собой полноценную платформу контейнеризации на базе Kubernetes с большим количеством управляемых сервисов и единой консолью управления. Любое изменение могло затронуть базы данных, брокеры сообщений, системы хранения данных или внутренние управляющие компоненты платформы.
Ручные проверки постепенно переставали справляться с объемом изменений. Поэтому мы начали строить систему автоматизированного тестирования.
Оглядываясь назад, можно сказать, что написание тестов оказалось самой простой частью работы. Гораздо больше времени заняли создание собственного фреймворка, организация тестовых окружений, интеграция с CI/CD, построение отчетности и настройка процессов внутри команды.
Без готового решения
Когда мы начали работу над автоматизацией, готового решения внутри проекта не существовало. Не было ни инфраструктуры для запуска тестов, ни единых подходов к написанию проверок.
Поскольку платформа построена вокруг Kubernetes и объединяет множество сервисов под единым интерфейсом управления, нам требовался инструмент, который позволял бы одинаково удобно работать как с backend-компонентами, так и с пользовательскими сценариями.
В качестве основы мы выбрали Python и PyTest. Причина проста: Python хорошо знаком как разработчикам, так и DevOps-инженерам. Кроме того, экосистема PyTest уже содержит огромное количество готовых решений для организации тестирования, управления окружениями, генерации отчетности и интеграции с CI/CD.
В результате появился единый фреймворк, который сегодня используется для запуска тестов, подготовки окружений, формирования отчетности и уведомления команды о результатах прогонов.
При этом изначально мы не ставили перед собой задачу создать универсальный инструмент. Нам нужен был фреймворк, который решает проблемы конкретного продукта. Именно поэтому многие решения принимались исходя из особенностей платформы, а не абстрактных лучших практик.
То, что действительно ломается
Первый серьезный пласт автоматизации появился на уровне API. Это было продиктовано архитектурой продукта. Большая часть логики платформы находится на стороне backend-компонентов, а пользовательские действия в интерфейсе в конечном итоге сводятся к вызовам управляющих сервисов.
Мы начали автоматизировать проверки основных менеджеров платформы, отвечающих за создание ресурсов, изменение конфигураций, получение статусов и выполнение операций управления.
При этом старались тестировать не отдельные методы, а законченные сценарии работы с системой. Если пользователь создает ресурс через консоль управления, то именно такой сценарий и должен проверяться автоматизированно.
Такой подход позволил достаточно быстро получить реальную пользу от автоматизации. Тесты начали ловить регрессии, ошибки и недочеты в бизнес-логике, а не просто проверять корректность отдельных API-вызовов. Со временем именно API-покрытие стало фундаментом всей системы тестирования.
Немного UI-тестов
Когда речь заходит об автоматизации интерфейсов, часто возникает желание покрыть тестами буквально каждый экран, каждую страницу и кнопку, каждый элемент UI. На практике это редко работает.
UI-тесты значительно сложнее в сопровождении, медленнее выполняются и сильнее зависят от изменений продукта. Любая переработка интерфейса может привести к тому, что десятки сценариев придется актуализировать заново.
Поэтому мы сделали ставку на наиболее важные пользовательские кейсы. Для автоматизации интерфейса был выбран Playwright. Сейчас это один из наиболее популярных и гибких инструментов для тестирования современных веб-приложений. С его помощью мы моделируем реальные действия пользователя через консоль управления платформой и проверяем критически важные сценарии работы.
В результате UI-тестов у нас значительно меньше, чем API-проверок. Но каждый из них воспроизводит реальный путь пользователя и позволяет находить проблемы, которые невозможно обнаружить через API.
Такой баланс оказался гораздо эффективнее, чем попытка добиться стопроцентного покрытия интерфейса.
Проблема в окружении
Один из самых полезных уроков мы получили уже после появления первых стабильных наборов тестов. Поначалу проверки запускались на обычных средах разработки. Казалось, что этого достаточно. Однако очень быстро стало понятно, что результаты таких прогонов сложно считать надежными.
Разработчики постоянно вносили изменения, обновляли сервисы, меняли конфигурации. В результате при падении теста было сложно понять, действительно ли проблема связана с новым кодом или причина находится где-то в самом окружении.
Поэтому мы пошли по пути создания отдельного тестового контура. Появилось выделенное staging-окружение, максимально приближенное к среде препрода. В отличие от обычных сред разработки, оно остается стабильным и не используется для ежедневных экспериментов. Фактически это стало нашей моделью будущего production. Именно здесь теперь проходят основные автоматизированные проверки перед дальнейшим продвижением изменений.
После появления отдельного контура количество ложных срабатываний заметно сократилось, а доверие команды к результатам тестирования существенно выросло.
Проверять изменения до релиза, а не после
Следующим шагом стала интеграция автоматизированных проверок в CI/CD.
Сегодня процесс выглядит достаточно просто. После внесения изменений в основную ветку запускается пайплайн проверки. Сначала тестируется текущая версия системы, чтобы убедиться в корректном состоянии окружения. Затем на staging устанавливается новый билд и выполняется полный набор автоматизированных проверок.
Если тесты проходят успешно, сборка продолжает движение по релизному процессу. Если возникают ошибки, команда получает уведомления и может оперативно приступить к анализу проблемы.
Подобный подход позволил значительно сократить количество ситуаций, когда проблемы обнаруживаются уже после развертывания новой версии продукта. Автоматизация перестала существовать отдельно от процесса разработки и стала его неотъемлемой частью.
Запустить тесты недостаточно
Достаточно быстро стало понятно, что ценность тестирования определяется не только качеством самих проверок. Не менее важно быстро разобраться в причинах падения. Если инженеру приходится тратить часы на поиск информации о том, что произошло во время прогона, эффективность всей системы начинает снижаться.
Поэтому отдельное внимание было уделено отчетности.
Для каждого запуска формируется отчет Pytest, который позволяет быстро получить необходимые данные для воспроизведения ошибки, и полный развернутый отчет Allure Report, где доступна история запусков, информация о нестабильных сценариях и подробная диагностика ошибок.
Уведомления о проблемах сейчас отправляются по электронной почте, также используется интеграция с мессенджерами.
В результате информация о проблеме появляется практически сразу после неудачного запуска, а инженеры получают все необходимые данные для анализа.
Проверять не только функциональность, но и устойчивость
Сегодня основной фокус команды направлен на расширение покрытия существующего функционала. Каждый новый автоматизированный сценарий позволяет сократить объем ручных проверок перед релизом и ускорить получение обратной связи по изменениям. Однако со временем становится очевидно, что функциональное тестирование решает далеко не все задачи.
Для инфраструктурной платформы не менее важны производительность и отказоустойчивость. Поэтому следующим этапом развития стали нагрузочное тестирование и chaos engineering.
Сейчас идет работа над отдельным фреймворком, который позволит моделировать различные профили нагрузки и оценивать поведение системы в условиях повышенного потребления ресурсов. В качестве основного инструмента для нагрузочного тестирования рассматривается K6.
Параллельно ведутся эксперименты с chaos engineering. На начальном этапе планируется использовать Chaos Mesh для моделирования контролируемых отказов отдельных компонентов платформы. Нас интересует не только вопрос корректности работы системы в штатном режиме. Не менее важно понимать, как она будет вести себя при деградации сервисов, отказах инфраструктурных компонентов или других нештатных ситуациях. Именно в таких сценариях обычно проявляются реальные сильные и слабые стороны архитектуры.
ИИ в контуре тестирования
Еще одно направление, над которым мы начали работать, связано с использованием ИИ-агентов для управления тестовыми сценариями и анализа результатов запусков.
Первый вопрос, который обычно возникает в подобных обсуждениях, касается безопасности. В нашем случае работа ведется в рамках корпоративного контура с ограничениями на передачу данных во внешние системы. Используемые решения могут работать внутри контролируемой среды и не требуют передачи внутренней информации за пределы инфраструктуры компании.
Безусловно, такой подход накладывает определенные ограничения и не позволяет использовать весь спектр возможностей публичных сервисов. Однако для задач автоматизации тестирования существующих возможностей вполне достаточно.
При этом речь не идет о замене инженеров. Мы рассматриваем ИИ как дополнительный инструмент автоматизации, который способен взять на себя часть рутинных операций, помочь с анализом результатов и в перспективе упростить управление всей системой тестирования.
Сейчас мы продолжаем расширять покрытие автотестами, развиваем нагрузочное тестирование и экспериментируем с подходами к chaos engineering. Будет интересно узнать, как похожие задачи решаются в других командах. Если вы строили систему автотестирования для сложных платформ, работаете с Kubernetes-продуктами или уже внедряли нагрузочное тестирование и chaos engineering в свои процессы, поделитесь опытом в комментариях. Интересно обсудить как удачные решения, так и ошибки, на которых удалось чему-то научиться.