Testability means observable evidence
A requirement is testable when the team can determine, with reasonable objectivity, whether the delivered solution satisfies it.
That generally requires a clear condition, expected behaviour, and observable result.
Characteristics of a testable requirement
- Clear
- Specific
- Unambiguous
- Measurable where appropriate
- Observable
- Feasible
- Traceable
- Complete enough to design tests
Weak vs testable examples
Performance
Weak: “The page should load quickly.”
Testable: “The page should load within 2 seconds for 95% of requests under the agreed normal workload.”
Authorization
Weak: “Only authorized staff can edit records.”
Testable: “Editor users can modify active records; Viewer users can read but cannot create, edit, or delete records.”
Questions QA should ask
- What business outcome is required?
- Who is allowed to perform the action?
- What happens when input is invalid?
- What are the boundaries?
- What if a dependency is unavailable?
- What data states must be supported?
- How will success be observed?
Acceptance criteria are not the whole story
QA should also consider negative behaviour, interfaces, data, permissions, error handling, performance, accessibility, and operational impact.
Definition of Ready should enable delivery, not become bureaucracy. Use it to expose missing information before commitment.