Verification by those paying.
WHAT IT ESTABLISHES
Whether the software meets the need.
WHO PERFORMS IT
The client, or their users.
WHAT TO PREPARE
A working environment Realistic data Clear scenarios to work through A way to record findings
WHY SCENARIOS RATHER THAN FREE EXPLORATION
Unstructured testing produces scattered feedback and misses requirements.
WHAT TO AGREE BEFORE STARTING
What is being accepted What criteria apply How long it will take What happens to findings
WHAT TO CLASSIFY FINDINGS AS
Defects, against the agreed scope Changes, outside it Misunderstandings
WHY THAT CLASSIFICATION MATTERS
It determines who pays.
WHAT TO HANDLE CAREFULLY
Requests framed as defects that are actually new requirements.
HOW
Return to what was agreed, without argument.
WHAT TO DOCUMENT
Every finding, its classification, and its resolution.
WHAT TO OBTAIN
Written acceptance.
WHY
It marks the transition, and prevents indefinite extension.
WHAT TO PLAN FOR
Findings after acceptance, and how they are handled.
