Test automation

Business systems get large, and the risk in every release is the same: something unrelated to the change stops working, and nobody notices until a user does.

The test automation module exists to answer that. It matters to an organisation evaluating the platform less as a feature than as a statement about how upgrades are handled.

Recorded usage, replayed

Hand-writing end-to-end tests for a system with hundreds of screens is impractical, and the tests that do get written drift out of date faster than the product changes.

So instead of authoring tests, real usage is recorded. Someone works through a genuine task - register a record, take a payment, route an approval - and that session becomes a reusable fixture: an ordered sequence of what was asked and what the system answered.

Before a release, those fixtures are replayed against the new code and the answers compared. A difference is either a regression or an intended change somebody should be able to name.

Why this works where scripted tests do not

Real tasks are multi-step and stateful. A form is rendered, then submitted, and the submission depends on state the earlier step left behind. Replaying a whole session in sequence reproduces that naturally; testing a step in isolation cannot.

Coverage follows actual use. The journeys that get recorded are the ones people perform, so effort lands on what is actually used rather than on what was easy to write a test for.

Fixtures are cheap to produce. Recording a session is a task an analyst or tester can do without writing code, which is what makes broad coverage affordable.

Safety of the process itself

• Replays default to read-only, so a regression run changes nothing.
• Anything that writes is opted into explicitly and runs against a demonstration database.
• Sensitive values are removed at the point of recording, so a fixture is safe to keep.
• A failure in one step is reported rather than aborting the run, so one broken screen does not hide the state of everything else.

Recording is a deliberate act, switched on for the purpose and off again afterwards. It is never enabled on a live deployment.

What it is honestly good for

Being clear about this matters more than overselling it:

• It is strongest as a safety net for change - it proves the system still does what it did before, which is exactly what you want when accepting an upgrade or a refactor.
• It characterises current behaviour. It is not a statement of what the system should do, only of what it did.
• It exercises the server’s request-and-response behaviour, not the browser.
• A replay is only ever as good as the session someone took the trouble to record.

Alongside it sits conventional unit testing for the parts where exact logic matters - calculations, validation rules, data handling - where a precise assertion beats a recorded example.

What this means for you

If you are accepting a deployment or an upgrade, three questions are worth asking, and this module is how they get answered:

1. Which journeys are covered by recorded fixtures?
2. Were they replayed against the release you are being asked to accept?
3. What differences appeared, and what was the explanation for each?

A delivery team that can answer those is not relying on hope. If you are commissioning a system, having your own critical journeys recorded during acceptance is worth insisting on - it is the cheapest assurance you will ever buy.