Automation acceptance testing: what to check before going live
A successful demonstration shows that a workflow can work once. Daily operation also needs rules for missing data, repeated inputs and outages. Our acceptance template helps clients and implementation teams agree expected behaviour before launch. It is a project framework, not a general guarantee about a particular platform.
Describe the expected workflow in checkable terms
Record the trigger, required data, processing and expected result. An example is assigning an accepted website enquiry to an owner in the CRM. Do not just check that a contact appears somewhere: check its content, ownership and working status. Agree which decisions remain manual and which timing requirement makes sense for the business.
- Trigger and permitted input data.
- Expected record with specific field values.
- Owner and next working step.
- Agreed processing time and measurement point.
- Deliberately manual decisions and exceptions.
Build a test matrix with expected results
Our matrix records case number, input, expected outcome, observed outcome and decision. Start with a normal case and deliberately add edge cases. Use identifiable test data and agree which notifications are permitted. A real customer address is not a convenient substitute for a planned test contact.
- Complete, valid input.
- Missing required field and invalid value.
- The same input is processed again.
- An existing contact sends a new enquiry.
- The destination system is temporarily unavailable.
- One step succeeds and the next step fails.
Treat repeated delivery and new enquiries separately
A message delivered twice is different from a new enquiry by the same person. Agree how the implementation distinguishes them. Our check sends the same input twice, then submits a new enquiry with the same contact address. Define the expected outcome before testing, including tasks, notifications and ownership. Not every repeat should create new work, and not every matching address is an error.
Make failures visible and recoverable
Ask the team to show where failed work appears, who is notified and how safe recovery works. A green status after the first step is insufficient if CRM assignment later fails. Test a deliberately interrupted workflow and its restart. Also agree what data logs need and who may read them rather than automatically copying complete customer content into logs.
Record business approval and launch conditions
Have future users inspect the outcomes. A technical success message does not answer whether sales can actually handle the enquiry. Record blocking defects, accepted limitations and follow-up work separately. Our approval log also names an operational owner, a way to stop the workflow and treatment of inputs arriving during an interruption.
Use the same expectations after launch
Schedule an early review and inspect a small selection of real records against the same expectations used in testing. Record missing assignments, repeated processing and manual cleanup. If a failure pattern repeats, correct the rule and add that case to the test plan. Acceptance then becomes a reusable basis for later changes, rather than simply a signature.
Frequently asked questions
- Is a successful demo video enough?
- It shows one workflow but does not replace agreed tests with expected results. Pay particular attention to repeats, invalid data and interruptions.
- Who should perform acceptance testing?
- Our proposal involves the implementation team and responsible business users together. One checks the technical behaviour; the other checks whether the results are usable.
- Must every possible error be tested?
- Prioritise realistic cases with high impact or frequent occurrence. Document accepted limits rather than promising complete freedom from failures.
- Does a small workflow need a test plan?
- A short list can be enough. Specific inputs, expected outcomes and an owner matter more than a large document.
Describe the workflow and its intended result. We can develop a manageable test plan covering normal cases, exceptions and clear operational ownership.
Discuss automation and acceptance