Acceptance before production: A checklist for AI-supported workflows

Test the exception path

Acceptance testing covers normal, incomplete and deliberately misleading inputs. Anthropic recommends clear success criteria, tested interfaces and human oversight. Google Cloud recommends stable metrics, reference examples and repeatable checks, plus tests for deliberate misuse, versioning and continuous evaluation.

The acceptance checklist download is a two-page worksheet. The CSV test register is useful for ongoing maintenance.

Ten questions before release

Suggested boundary tests for a quoting workflow

Suggest these four test groups: the time boundaries 21:59, 22:00, 05:59 and 06:00; distances of 19, 20 and 21 km; missing deployment details; and contradictory inputs. These are proposed tests, not reported Hofmann results. Before each run, write down the expected pricing logic and route: automatic or human.

The case material records 38 enquiries in 7.5 weeks, 21 of 38 outside office hours and a cycle time under 60 seconds. Those figures describe usage and workflow. They do not prove that the suggested test cases were run or passed. Later conversion must be measured separately.

Risk-weighted release decision

Rate each test high, medium or low risk. A high-risk failure blocks release when the expected boundary is violated: for example a wrong price, unauthorised action, data leak or unlogged handoff. Medium risks need a named action and due date. Low risks may be released with an observation plan. This is a decision rule, not a certification.

When the rule card, prompt, model or data changes, rerun the relevant test set. For variable outputs, one run is not enough: repeat each important case with the same input and record passes, deviations and rationale. Record test ID, expected output, actual output, owner, version, date and open action in the register. This does not claim a system will remain error-free; it makes changes and variability visible.