Testing unclear requirements
June 10, 2007
In Lukas’ talk there he pointed out a bad requirement, that would be impossible to test because it lacks details:
The instrument shall provide the capability for authorized users to create, edit and load files.
What do you do about a requirement that is vague?
One way is to raise your hand and tell people that this requirement isn’t testable. It needs more detail. Have them write it down in a document.
Another one is to just write test cases for it. Like this:
Try to login as Administrator and create a tst file.
| enter | username | admin |
| enter | password | geheim |
| press | login |
| check | isInRole | Administrator |
| check | countFiles | 0 |
| enter | createFile | newTestFile.tst |
| check | countFiles | 1 |
This is an almost-valid fitnesse test, that tries to login, makes sure the person is in the administrator role and tries to create a file. Similar ones are needed for somebody who doesn’t have access rights. For editing and loading.
The requirement quickly becomes less important, because the details are in the tests. The tests have to be in an easily readable format. By readable I mean:
The customer (a nontechnical person) has to be able to look at it and say whether this is what he wants or not. If he doesn’t like it, he should be able to change it or enhance it.
To further limit possible test tools, add to the above:
It has to be possible to specify the tests before any software exists.
And:
It should be little or no effort for the programmers to connect production code to the test specification.
Is there a tool that allows for all that? I don’t know. I guess fitnesse comes closest. But there is a lot of room there…
As you can see, the requirements can be vague. But with the details documented in automated test cases you are in a much better shape than with a BLOB called requirements document.
Another question is: Do you really need to write down those details at the beginning of the project?