Сегодня в нашем CI ежедневно запускается более 5 000 автотестов, которые проверяют всё: от корректности скриншотов панели до скорости отклика API. Это не просто тулза в пайплайне, а часть инженерной культуры команды, которая помогает нам выпускать изменения быстро и с уверенностью.

Привет! Меня зовут Михаил Шпаков, я руковожу разработкой Timeweb Cloud.

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

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

В этой статье расскажу, как устроена наша система, какие типы тестов мы используем, как выстроен процесс, и какие уроки мы из этого извлекли.

❯ Тесты как часть разработки

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

У нас есть выделенная команда AQA, но её роль — помогать масштабировать автотестирование, а не закрывать долги. AQA-инженеры тесно работают с разработкой, участвуют в планировании, развивают общую инфраструктуру тестов, помогают с поддержкой и улучшением покрытия.

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

Мы стремимся проверить всё, что имеет ценность: UI, API, производительность, адаптив, Terraform-сценарии, скриншоты, инфраструктурные кейсы. Благодаря этому мы можем выпускать фичи быстро, не теряя контроль над системой в целом.

❯ Типы автотестов

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

Вот что именно мы тестируем:

? UI и визуальные тесты

Мы используем скриншотные тесты для проверки интерфейса панели управления и маркетингового сайта. Сравниваем рендер с эталоном, проверяем, что ничего не «поехало» после изменений.

Особое внимание уделяем адаптиву — десктоп и мобилка. Верстка не должна разваливаться ни при каких условиях.

? API-тесты

Проверяем статус-коды, ошибки, контракты и время ответа. Многие API покрываются тестами по принципу: что бы ни делал пользователь — мы должны понимать, как это отразится на бекенде, и правильно ли всё отрабатывает.

Это помогает ловить не только баги, но и регрессы в логике и производительности.

Дополнительно все методы проходят базовые проверки на безопасность: тестируем на IDOR (доступ к чужим ресурсам через подмену ID), ошибки авторизации и типовые сценарии обхода прав. Это помогает отслеживать, что изменения в коде не открыли уязвимости, которые ранее были закрыты.

⚡ Performance-тесты

Для нас важно, чтобы не только работало, но и работало быстро. Мы замеряем:

• скорость загрузки страниц (например, панели управления),

• скорость отклика API-методов (особенно — публичных).

В том числе мы используем Lighthouse-тесты, которые дают объективную оценку производительности фронтенда: метрики типа Time to Interactive, Largest Contentful Paint и другие. Эти тесты позволяют не только отслеживать деградации, но и задавать ориентиры для оптимизации интерфейса.

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

?️ Terraform-тесты

Timeweb Cloud — это инфраструктура как код. Мы предоставляем Terraform-провайдер, и многие пользователи используют именно его. Поэтому мы тестируем сценарии, где с помощью Terraform создаются, настраиваются и удаляются ресурсы (VM, базы данных и т.д.).

Тест проверяет не только успех операций, но и то, что ресурс реально создан и работает.

? End-to-End (E2E) тесты

Это полноценные сценарии, имитирующие действия пользователя. Например, создать VPS, подключиться к нему по SSH, развернуть приложение. Такие тесты охватывают путь пользователя от интерфейса до рабочих ресурсов и проверяют, как компоненты платформы взаимодействуют между собой.

У нас таких тестов два типа:

• Классические E2E-тесты — проходят через пользовательский интерфейс панели управления. Они эмулируют реальные сценарии: создание ресурсов, навигацию по разделам, настройки и удаление.

• Инфраструктурные E2E-тесты — более сложные. Они проверяют каждый отдельный сервис платформы: создают, подключаются, взаимодействуют. Например, создать базу данных → подключиться к ней по хосту и порту → выполнить SQL-запрос → проверить, что данные сохранились.

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

E2E-тесты не быстрые, но бесценные: именно они чаще всего ловят интеграционные баги и регрессии, которые невозможно заметить в изоляции.

? Smoke-тесты

Быстрые тесты, которые бегут при каждом релизе.

Они не пытаются проверить всё, но дают ответ на ключевой вопрос: «живо или нет».

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

Smoke-тесты прогоняются быстро, давая команде мгновенную обратную связь.

❯ Инфраструктура тестирования

Все наши автотесты написаны на Playwright — он дает хорошие возможности для работы с UI, API и даже сценариями, где нужно подождать, пока ресурс «прогреется». Мы используем единую технологию для всех уровней — от UI тестов до e2e, что упрощает поддержку и ускоряет разработку.

Запуск тестов полностью автоматизирован и встроен в наш GitLab CI. Тесты гоняются:

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

• при каждом релизе на прод — чтобы ничего не ушло с багами;

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

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

❯ Отчёты и нотификации

Результаты всех запусков автотестов у нас хранятся в Test Management System и в GitLab CI. В TMS ведётся структура сценариев, история запусков, стабильность тестов и покрытие. В GitLab — пайплайны, артефакты, логи и статусы по каждому шагу. Это основа для анализа и работы с качеством на длинной дистанции.

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

У нас настроены отдельные Telegram-каналы для каждого окружения: dev, stage, prod. Это помогает избежать путаницы и сразу понимать, где именно произошло падение.

Каждое сообщение содержит:

• инициатора запуска с тегом в Telegram, чтобы человек сразу получил уведомление;

• тип тестов (например, smoke, e2e, terraform);

• проект/сервис, для которого выполнялись тесты;

• статистику по прогону — сколько тестов прошло, сколько упало;

• ссылку на GitLab pipeline с логами и артефактами;

• ссылку на расширенный отчёт, где виден результат каждого теста, ошибки, трассировки и скриншоты (если есть).

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

❯ Чем это нам помогает

Система автотестов — это не просто защита от багов. Для нас это инструмент, который влияет на ритм разработки, уверенность в релизах и культуру команды.

1. Быстро ловим регрессы

   Регрессы не копятся — мы видим их в тот же день, а иногда ещё до того, как кто-то нажмет «Merge». Это позволяет фиксить баги сразу, пока контекст в голове и не затронуты соседние задачи.

2. Уверенность при релизах

   Тесты дают зелёный свет на выкаты. Мы реже прибегаем к ручной проверке, не держим релизы «на паузе» из-за сомнений. Если всё зелёное — выкатываем спокойно.

3. Меньше страха менять старый код

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

4. Меньше ручного тестирования, но больше контроля

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

❯ Сложности и уроки

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

⚠️ Нестабильные тесты

Часть тестов, особенно UI и e2e, на старте были флаковыми: зависели от таймингов, нестабильных данных или окружения. Это размывало доверие к автотестам и мешало команде реагировать быстро.

Что сделали: добавили ретраи, продумали явные ожидания, уменьшили зависимости от конкретных данных. Часть нестабильных API мокается. Если тест всё равно флейковый — он автоматически исключается из релизных запусков, но остаётся в отчётах с флагом.

? Перерасход облачных ресурсов

Однажды мы заметили, что часть тестов создает ресурсы (серверы, IP-адреса, БД) и не чистит их. Постепенно они накапливались и начинали занимать реальные ресурсы облака. В какой-то момент «потерялось» больше 10 000 IP-адресов и серверов, которые копились несколько месяцев.

Что сделали: внедрили отложенное удаление и проверки на «висящие» ресурсы. Теперь каждый тест обязан явно чистить за собой окружение, а фоновые джобы регулярно проводят ревизию. Заодно мы научились лучше считать утилизацию ресурсов.

? Конкуренция за CI-ресурсы

Тесты начали занимать слишком много GitLab-воркеров. Это влияло на всё — сборки приложений замедлялись, пайплайны ждали очереди, разработчики не могли нормально проверять свои изменения.

Что сделали:

• Вынесли тяжелые тесты (например, инфраструктурные e2e) в отдельные runner-группы,

• Расширили кластер GitLab Runners и начали отслеживать нагрузку как метрику.

Каждую такую проблему мы воспринимаем как сигнал, что система автотестов — это тоже продакшн, и её нужно масштабировать, поддерживать и оптимизировать как любую боевую часть платформы.

❯ Заключение

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

Автотесты экономят время, снижают количество ручных проверок, делают регрессии предсказуемыми, а баги — контролируемыми. Но главное — они становятся частью культуры: тесты помогают писать все, тесты запускают все, и все на них ориентируются.

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

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

Если вы тоже когда-нибудь случайно забывали подчистить за собой 10 000 IP-адресов — значит, мы точно друг друга поймем. Спасибо, что дочитали до конца. Надеюсь, наша история поможет избежать некоторых грабель — или хотя бы наступить на них чуть мягче.

Новости, обзоры продуктов и конкурсы от команды Timeweb.Cloud — в нашем Telegram-канале ↩

? Читайте также:

• ➤ Как я по вечерам разрабатывал Statuser — платформу для мониторинга доступности приложений

• ➤ Инфраструктура, которую видно: как мы делаем визуализацию облака

• ➤ Веб-студии создавали сайты, но тут пришли нейросети. Как ИИ меняет правила игры

• ➤ Вредные советы. Сборник для компаний и маркетологов с примерами и иллюстрациями

• ➤ Огромный гайд по настройке рабочего окружения: Linux, VScode, Python