The short answer
Write down what each test should do before running it. Check normal work, missing information, duplicates, uncertain output and unavailable systems, then record the actual result and who approved it.
1. Agree what a working result means
Name the task, its owner and the systems involved. For each step, describe what should be prepared, what may be changed and what needs a person’s approval.
Use an agreed test environment or demonstration with suitable sample data. Check that tests cannot send customer messages or change live records unintentionally.
2. Include these test cases
Adapt the expected behaviour to your process before running the tests.
| Test case | A result to define and check |
|---|---|
| Complete, ordinary input | The right information reaches the intended review step, with no unexplained changes. |
| Missing or invalid information | The workflow identifies the gap and asks for a correction or stops at the agreed boundary. |
| The same request twice | A repeat run does not create an unintended second message or record. |
| Unclear or unsupported output | The reviewer can see the source, reject the proposal and resolve the uncertainty. |
| A connection is unavailable | The failure is visible, an owner knows what to do and retrying does not repeat completed actions. |
| Approval has not been given | The restricted action remains pending until the authorised person approves it. |
3. Keep a record that another person can follow
For each test, record a reference, the input, the expected result, the actual result, the reviewer and any follow-up. Keep the relevant source and output together so the decision can be checked.
If the workflow drafts or interprets information, try several representative examples. Check whether the meaning, names, figures and commitments are supported by the source. One successful run does not establish reliability.
An example to adapt: an incomplete enquiry
In a fictional enquiry process, a request arrives without a contact email. The agreed result is to flag the missing email, keep the request available and prepare no outgoing reply. Record whether each of those things happened.
After correcting the email in the test, complete the agreed review step and run the same reference again. Check that retrying cannot create a second response. This is a test design to adapt, not a claim about a client implementation.
4. Resolve failures before everyday use
Record who will correct a failed test and repeat the affected checks after the change. Agree who can pause the workflow and how the team continues the task manually if needed.
Before handover, the process owner should know how to review output, report a problem and find the current instructions. Keep the test log available when a connection, source or instruction changes.
Take a copy to your team
Download the plain-text checklist and repeatable test log. Add your examples, expected results, observations and follow-up actions.
Download the workflow testing checklistPut this into practice
AI Workflow Automation
Workflow automation for small and medium-sized businesses: connect enquiries, documents, reporting and everyday admin with clear checks and human approval.
Custom AI Tools
Custom AI tools for small and medium-sized businesses. Practical assistants, internal applications, document tools and dashboards built around your work.
Ongoing Support & Improvements
Ongoing support for implemented AI tools and automations. Maintenance, troubleshooting and improvements as your business and systems change.