Multiple Information Sources Rikard Edgren
When I wrote blog post The Complete List of Testing Inspiration, I didn’t think so much about many testing efforts being totally based on requirements and specifications.
I took for granted that we know that requirements are incomplete and wrong, and that we should learn from many places.
But when reading a good book such as Lee Copeland’s A Practitioner’s Guide to Software Test Design you see that the classic black box testing procedure is to base your test design solely on requirements and specifications.
It’s the same as with code coverage models, the most interesting stuff is what isn’t there.
Maybe we need to sharpen the argumentation for this, so here are my first attempts:
1. What problem is testing trying to solve?
I think there are more situations like this:
“We know that there will be defects in the product we are building. We need your help to make sure that the released product can be used by customers without problems, and satisfactorily help them with their tasks.”
than like this:
“We want to make sure that the actual product meets the statements in the requirements document.”
2. Requirements checklist of one
Did an omnipotent write the requirements?
(We know more when testing than when requirements are written; testers look at other details; testers also test the requirements, how things turned out.)
3. The intuitive argument
A visual representation, like the software potato: an image showing that requirements cover less than what’s important, that is less then everything.
4. Requirement realism
Requirements aren’t explored, but if all were written according to Exploring Requirements by Gause and Weinberg, we would probably be in a better position. We would not only know what needs to be in the product, we would also know about Preferences, Constraints, and “Want it without Cost”
One argument should suffice, but which one, and how can it be polished?
I think this is a good start!
I do not think that one argument can suffice; it depends on which situation you are in. Sometimes you need all these four + some more in order to convince someone.
Even those who know about the imperfect models that requirement documents represent needs to be convinced.
In the last couple of years I have been using at least the three first arguments above in each project (thank you for the potato which has helped a lot!).
In essence, the arguments are:
— valid arguments to each original formulation of a question.
— representing different dimensions of “what isn’t there”.
Nice potato, nice post – though I suspect you meant omniscient rather than omnipotent (I looked it up 🙂
Thanks for the correction.
Omniscient is much better, an omnipotent would of course create the perfect software at once.