Consider a requirement like “The system shall require a valid date entry in the form of mm/dd/yy.”
(Ok, now if you’ve really been paying attention, you know that this is far from a completely defined requirement – we haven’t said what to do if the date is not valid, etc. But for the sake of this example, ignore that for now).
3 Separate Fields
In the implementation, the developer decided to implement this as 3 separate fields, one for mm, one for dd, and one for yy.
The implementation doesn’t allow the user to enter anything in dd until mm is filled out (and validated) nor will it allow the yy field to be filled in unless both mm and dd
are entered (and validated).
Sounds like a reasonable implementation, right? How do we establish test it?
Do we:
- Have a test step for each field and verify that a bad mm entry is rejected, you can’t enter dd until mm is entered and validated, etc.
- Have a test step to verify that an error message pop-up is raised if a bad mm is entered?
- Have a test step to attempt to enter a dd or a yy before each of the predecessors is entered and validated?
- Any of the above?
(Ok, be honest, did you guess ‘d’ because you just guessed?)
Implementation And Not The Requirement
You could but you’d be testing the implementation and not the requirement.
We want to test our requirements, not the implementation.
Testing the implementation can cause much undue testing / test steps and, at times, can even stray away from the intent of the test (to verify the requirement).
Exploratory Testing
We’ll talk a bit more about ‘exploratory testing’ in a bit where we give the tester a little more freedom to bang on the software but in terms of functional testing, focus on whatever your requirements are and not the implementation.
As you develop your protocols, be sure to avoid testing the implementation.
Focus on the requirements.
It’s an easy trap to fall into so be cognizant of the trap and avoid it.
Testing the implementation will often lead to failures that have nothing to do with the true requirements.
