Written . Original operational guidance, not legal advice.
Set the boundary
Choose one administrative workflow and an accountable evaluator. Agree whether you are testing a public demonstration, a trial environment or a contracted live service. Those are different settings with different data permissions. Use fictional inputs until the team has approved the handling of real information.
- Workflow and owner: what task, performed by whom?
- Input: which fictional records or example text will be used?
- Success criterion: what visible result would demonstrate the task?
- Data boundary: where may the information go and how will it be removed?
Run a small vertical test
Complete the task once, then test a missing record, an invalid input and a recovery action. Capture the actual result, not just a screenshot of a button. If an export is involved, open it and compare its contents with the selected scope. If sending or payment processing is unavailable, record it as untested rather than interpreting a sample success label as proof.
- Expected result and actual result
- Evidence: screen, export or documented error
- Recovery: clear filter, reset or retry
- Unverified dependency: provider, permissions, data source or service configuration
Use this copyable evidence-log format
Create one row per requirement in a document or spreadsheet using these columns: Requirement | Owner | Test input | Expected result | Actual result | Evidence location | Unresolved question | Decision. Keep unknowns visible. A failed test should not be rewritten into a success criterion after the fact.
Before purchase, add the written quote and explicitly separate subscription, setup, usage, processing and third-party costs. Confirm support, exports, retention and cancellation terms. This checklist is an evaluation aid, not a certification or legal review.