It’s been quite a while since I reviewed a large requirements document, but I remember the process well. It was a big undertaking, but it led to some really interesting and collaborative conversations. Which inspired me to ask the following question:
Do you have to review large requirements documents? If yes, how do you go about it?
This is a very useful article; hats off to Bob There’s one gloss I’d like to put on it: what is the special role of the tester in the process of review?
It’s the tester’s job to raise these questions:
What are we building? Who are we building it for? What do they want from it?
Now: pretty much everyone else around the table is considering these questions too. It’s the tester’s job to go deeper and identify risk:
What could go wrong? (That’s a fundamental testing question.) How would we know? (That’s a fundamental testability question.)
Then, to go deeper still, vary the questions a bit. Are there important aspecs of the requirements that might get forgotten or ignored?
What else are we building (and how will we cover it with testing)?
Who else are we building it for?
What else do they want from it (that is, what features, functions, or quality criteria might be important)?
What else could go wrong (where are the more subtle or consequential risks)?
How else would we know (how can we make the product more testable)?
Are there things that we might want to avoid?
What are we not building?
Who are we not building it for?
What do they not want from it?
What could not go wrong?
How would we not know?
When we’re involved in requirements discussions, we’re there to learn; to identify problems; to advocate for testability; and to represent that testing will happen. While everyone around the table is focused on those first three questions, they’ll often forget the others. Having those questions at the top of our minds — and raising them aloud — is the special role of the tester.