Define the evidence of success
Describe the result a person needs and how you will verify it. A successful API request, a saved record, and a delivered email are different states. Decide which one your workflow promises.
Test where the process can break
Include a normal request, incomplete input, conflicting instructions, duplicate input, unavailable service, and an uncertain external action. Use test data and owned destinations. Write down the expected behavior before running each test.
Give failures an owner
For every failed or uncertain result, define who investigates and what evidence they need. Avoid automatic retries for actions that might already have happened. Keep the workflow limited until the unresolved cases have a clear handling path.
Copy this prompt
Build a test plan for the workflow below. For each case give the input, expected result, evidence to inspect, and recovery action. Cover normal operation, missing fields, duplicate requests, permission failures, service timeouts, and an action accepted by a service when its response is lost. Distinguish saved, accepted, and completed states. Do not execute tests or send anything. Flag cases that require a human decision.
Workflow:
Systems involved:
Customer-facing promise:
Actions that must not happen twice:Your first useful result
Run the prompt on one approved example. Review the output against the original material, resolve missing information, and save the version you would actually use.