What We Do Before an Automation Touches Your Business

Test data is always well behaved

Data created for testing has no apostrophes in surnames, no four-line addresses, no product codes that changed in 2019, no records created by someone who left.

Real data has all of those, and they are where late-discovered defects come from. We ask for a copy of your real data, anonymised if needed, and we test against it.

We break things on purpose

• Submit with required fields empty and check the message is useful
• Interrupt a process halfway and start again
• Send the same record twice, quickly
• Take the third-party system offline and see what happens
• Try to do something with the wrong permissions
• Feed it the record everyone in your team dreads

Then parallel running

For two to four weeks the automation runs alongside your existing process. Both produce output; we compare them and investigate every difference.

It feels like duplicated effort and it is the cheapest insurance available. Every discrepancy found in parallel running is one that would otherwise have been found by a customer.

We cover a full cycle including month end, because month end is where the interesting exceptions live.

You test it too

We ask your team to run their own acceptance tests, written before they see the software so they test what your business needs rather than what it happens to do well.

1. The five workflows you run most often, as numbered steps
2. The three exceptions you handle most often
3. The two things that would be worst if they went wrong
4. On the devices your staff actually use, not the newest laptop

What gets fixed before launch

Anything blocking a core workflow, anything touching money or access, anything that loses data. Cosmetic issues can follow.

We agree the severity levels with you before testing starts, so nobody argues about categories while the launch date approaches.