The short answer
Define what a correct result looks like, test realistic examples and inspect the evidence behind each output. Include cases that should fail or need help, and keep a person responsible for consequential decisions.
Describe correctness before testing
For a report, decide which figures must match the source and which explanation needs review. For a customer reply, decide which facts must be present and which commitments the draft must never make.
Use those requirements to judge the result. A polished paragraph or a plausible-looking table does not establish that the underlying work is correct.
Use examples from across the task
Collect suitable examples of ordinary work and the exceptions people encounter. Keep a set you can use again when instructions, software or information sources change.
Use fictional or appropriately handled data where needed. The test set should represent the work without exposing information to an unsuitable system.
- A complete, ordinary request.
- A request with a missing or contradictory detail.
- An input outside the agreed task.
- An outdated or unavailable source.
- An attempted duplicate.
- An output that should require approval.
Check the source and the proposed result together
A reviewer needs to see what the workflow used, what it produced and what it proposes to do next. Compare important statements with the original material and keep fixed calculations separate from generated commentary.
If the evidence is missing, the next step should be asking for information or handing the task back. Agree when the workflow stops instead of guessing.
Repeat the checks after a meaningful change
Instructions, documents, integrations and provider behaviour can change. Re-run representative examples before relying on a revised workflow, and make it clear who can approve that revision.
Track the corrections still needed and feedback from the people using it. A small repeatable check is more useful than treating the first demonstration as permanent proof.
A useful test checks the evidence, the result and the decision that follows.
A few related questions
Is a fluent answer a reliable answer?
It still needs checking against the task and the source information. Presentation alone does not establish accuracy.
Should we test again after changing instructions?
Yes. Use representative examples, including exceptions, to check whether the change affects behaviour elsewhere in the task.
Explore the connected topic
Put the idea to work
Ongoing Support & Improvements
A workflow lives in a real business. Documents change, people join, software updates and a new requirement turns up. Support keeps the implementation connected to that reality.
How we can help