Upon reading Paul Holland’s blog post entitled ‘Functional Specification Blinders’ (found here: http://testingthoughts.com/blog/185), I harkened back to all my past test experience and realized that this was the main source for all my test plans, test cases or test ideas.
The functional spec document is the ‘bible’ for the developers. This is everyone’s main focus of attention when developing a new feature. If your developer(s) are solid and the spec is well defined and complete, it kind of makes sense that the solution should be fairly solid based on what’s in the design document. Kind of makes you question why tests are based solely on these documents – is there real value in that?
If you think about it, the functional spec is constantly reviewed by multiple stakeholders and SMEs, reworked and re-written continually. The solution is demo’d and goes through many variations of testing (CAT, UAT, etc).
It does make sense to expand your test ideas and strategies beyond what’s solely in the design/functional spec document. As Paul suggested, it may be a good idea to come up with ideas prior to even reading the spec.
This is not to say the spec should be ignored. It is an invaluable tool in testing the feature, particularly if you are thinking of writing regression tests.
Just do not make it your sole focus…
