Automation for SaaS: the release checks itself before people check it

In a small product team what is worth automating is not testing as a whole but what repeats before and after every release: build checks, an API collection run, intake of support requests into tickets, the release report. We build these workflows so they run without a human and need no dedicated engineer to maintain.

What we automate in SaaS

• Pre-release checks: environment availability, link and translation validity, mandatory field completeness, version currency — on a schedule, with a report into the release ticket.
• API and integration regression: a request collection with contract and state checks runs in CI or on a schedule.
• Requests into tickets: messages from support and chats are classified, enriched with user data and environment and land in the tracker with a draft reproduction.
• Release report: run results, open defects by severity, unchecked zones — assembled into one document by the deadline.
• Post-release monitoring: errors, crashes, a rise in requests on a topic — alerts to the chat in the first hours.
• Operations: onboarding of new clients, renewals, notifications — workflows that take manual steps off the team.

What we keep manual

Exploratory testing of new features, LQA, acceptance and the release decision. Automation in SaaS pays off on stable, repeating checks; an attempt to automate an unstable suite turns into tests that fail for unclear reasons and stop being trusted. So the suite is first stabilised by manual regression, then candidates go to automation under three conditions: stability, frequency, determinism.

How the first workflow is built

1. We take the check that eats the most time before a release — usually a manual pass over the API or over links and translations.
2. We build the collection and workflow, run it in parallel with the manual check on two releases.
3. We compare findings, fix thresholds, connect it to CI or a schedule.
4. We hand over documentation and show the team how to fix the test when the interface changes.

Requests as a source of tickets

The "it doesn't work" stream from support becomes tickets automatically: a workflow classifies the message, asks the user for missing data, fills in environment and version and creates a ticket with draft steps. An agent or tester checks reproduction and sets severity — the rest is already filled in. Support thus feeds the regression suite with new cases without manual transfer.

Guard rails and implementation

Workflows do not change user data and do not ship releases — they only check and report. Access — separate tokens with minimal rights. Implementation — one to two weeks for the first workflow with a trial period, then one workflow every two to three weeks. Automation is a separate contract as development; for clients from Russia that matters for tax.