Some people say they “don’t have enough requirements to start testing,” or that the requirements are unclear or incomplete or contradictory or out of date.
First, those people usually mean requirements documents; don’t confuse that with requirements, which may be explicit or tacit. There are plenty of sources of requirements-related information, and it’s a tester’s job to discover them and make inferences about them.
Second, insufficient clarity about requirements is both a test result and a project risk, and awareness of them may be crucially important project information. (If the testers aren’t clear on the requirements, are the programmers? And if they’re not, how is it that they’re building the product?)
Finally, if there is uncertainty about requirements, one great way around that problem is to start testing and reporting on what you find. “Insufficient requirements” may be a problem for testing—but it’s also precisely a problem that testing can help to solve.
Oho! Now you offered me some foundation for understanding ‘Oracles From the Inside Out’.
Still, there is the question if its right for testers to define the scope of the product, priorities of different aspects etc. –
Or should they get these guidelines in advance.
Of course – if these are missing – its already indicates lack of quality.
@halperinko – Kobi Halperin
[…] Blog: Very Short Blog Posts (9): “Insufficient Requirements” – Michael Bolton – http://www.developsense.com/blog/2013/11/very-short-blog-posts-9-insufficient-requirements/ […]
Hello Michael –
Have you actually heard someone say they don’t have enough requirements to start testing /after/ the programmers have ‘delivered’ a build to test? That seems odd to me. I may be misreading you.
Thinking on it further, I have heard people mutter statements like that, /WHILE/ testing. It seems to me that what they meant was “we are unhappy about the current ‘lax’ state of documentation.”
Michael replies: I think that’s what they mean, along with “I’m nervous that I don’t have enough information to check things that someone will presume that I should be checking” (which often happens in places where checking and testing are assumed to be the same thing).
Of course, that conflates the documentation with the ‘figuring out what we are going to build’, which are two different things …
Yes—a classic example of reification.
Matthew: in my current situation (fortunately coming to an end on Friday), that is exactly what is being said.
And yes, it’s all about the ‘requirements’ not being in an ‘appropriate form’, which in this case appears to be an Excel spreadsheet.