Deriving tests from what was asked for.
WHAT TO EXTRACT
Every stated behaviour Every constraint Every condition and exception
WHAT TO CHALLENGE
Requirements that cannot be verified Requirements using vague terms Requirements with no stated exception handling
WHAT VAGUE TERMS ARE
Fast, user-friendly, robust, scalable, secure.
WHY THEY CANNOT BE TESTED
They have no criterion.
WHAT TO ASK
What figure would count as fast enough?
WHAT ACCEPTANCE CRITERIA SHOULD BE
Specific, observable, and agreed before work begins.
WHAT A GOOD FORMAT IS
Given a situation, when an action occurs, then an outcome.
WHY THAT FORMAT HELPS
It forces the precondition, the trigger and the expected result to be stated.
WHAT TO WRITE FOR EVERY REQUIREMENT
At least one positive case and one negative case.
WHAT A NEGATIVE CASE IS
Behaviour when the condition is not met.
WHY THEY ARE MISSED
Requirements describe success, and failure is assumed.
WHAT TO TRACE
Requirements to tests, so coverage is demonstrable.
WHAT GAPS IN TRACING REVEAL
Requirements nobody tested, and tests verifying nothing required.
