Functional specifications are incomplete without test plans!

There is a problem, a modification is suggested to overcome the problem. Stakeholders become bound up in tide of enthusiasm regarding the suitability and elegance of the modification, relieved the problem is solved. But is it? It is easy to lose sight of ensuring that time is not wasted in development and testing by having to re-develop and re-test because the functional and technical specification were not subjected to proper scrutiny and diligence in the rush to solve the problem. Does this situation sound familiar?   

The synopsis of the change is written outlining, functionality, benefits, costs and risks. The change is approved in principle. A detailed functional and technical specification is prepared. At this point are the specifications ready for review, approval and development? Only if the specifications includes a test plan.

Insisting on a test plan before the modification is approved for development will inform and challenge the functional and technical specifications ensuring they are complete and robust. The stipulation that a test plan must be included becomes moderating influence on the modification requestors forcing them to think through the modification before submitting it for approval. It also immediately raises the quality bar on the specification. As a starting point the user who requested the modification should be invited to explain how they would go about testing the functionality of the modification. This basic test premise should be then developed into a battery of test cases covering unit, edge or envelope and integration testing.

 The development of a comprehensive test plan for the modification is best done in a team setting where business analysts, users and developers can build on and challenge each other’s ideas. Time spent deriving the test plans prior to final submission and approval will pay dividends in ensuring the veracity of both the functional and technical specifications saving time later in development, unit and user acceptance testing. Once the test cases have been developed like any other project document they should be subject to peer review. This is best done again in a project team setting, often suited to a walkthrough type meeting supported by an algorithmic diagram, a few days after the test cases were originally documented.  In most cases a second walkthrough review separated by a few days proves beneficial in ensuring quality, the old adage measure twice cut once comes to mind.

Happy implementing