Автоматизация для SaaS: релиз проверяет себя до того, как его проверят люди

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

Что автоматизируем в SaaS

• Проверки перед релизом: доступность окружений, валидность ссылок и переводов, заполненность обязательных полей, актуальность версий — по расписанию, с отчётом в тикет релиза.
• Регрессия API и интеграций: коллекция запросов с проверкой контрактов и состояния прогоняется в CI или по расписанию.
• Обращения в тикеты: сообщения из поддержки и чатов классифицируются, дополняются данными пользователя и окружением и попадают в трекер с черновиком воспроизведения.
• Отчёт о релизе: результаты прогонов, открытые дефекты по severity, непроверенные зоны — собираются в один документ к сроку.
• Мониторинг после релиза: ошибки, падения, рост обращений по теме — алерты в чат в первые часы.
• Операционка: онбординг новых клиентов, продления, уведомления — сценарии, которые снимают ручные шаги с команды.

Что оставляем ручным

Исследовательское тестирование новых фич, LQA, приёмку и решение о релизе. Автоматизация в SaaS окупается на стабильных и повторяющихся проверках; попытка автоматизировать нестабильный набор превращается в тесты, которые падают по непонятным причинам и которым перестают верить. Поэтому сначала набор стабилизируется ручной регрессией, потом кандидаты уходят в автоматизацию по трём условиям: стабильность, частота, детерминированность.

Как строится первый сценарий

1. Берём проверку, которая отнимает больше всего времени перед релизом, — обычно это ручной проход по API или по ссылкам и переводам.
2. Собираем коллекцию и сценарий, запускаем параллельно с ручной проверкой на двух релизах.
3. Сравниваем находки, фиксируем пороги, подключаем к CI или расписанию.
4. Передаём документацию и показываем команде, как чинить тест при изменении интерфейса.

Обращения как источник тикетов

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

Ограничители и внедрение

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