Software Testing : Test Plan
As part of a project, testing must be planned to ensure it delivers on its expected outcomes. It must be completed within a reasonable time and budget. But test planning represents a special challenge.
The aim of test planning is to decide where the bugs in a product or system will be and then to design tests to locate them. The paradox is of course, that if we knew where the bugs were then we could fix them without having to test for them.
Testing is the art of uncovering the unknown and therefore can be difficult to plan. The usual, naïve retort is that you should simply test “all” of the product. Even the simplest program however will defy all efforts to achieve 100% coverage.
Even the term coverage itself is misleading since this represents a plethora of possibilities. Do you mean code coverage, branch coverage,or input/output coverage ? Each one is different and each one has different implications for the development and testing effort. The ultimate truth is that
complete coverage, of any sort, is simply not possible (nor desirable).
So how do you plan your testing?
At the start of testing there will be a (relatively) large number of issues and these can be uncovered with little effort. As testing progress more and more effort is required to uncover subsequent issues.
The law of diminishing returns applies and at some point the investment to uncover that last 1% of issues is outweighed by the high cost of finding them. The cost of letting the customer or client find them will actually be less than the cost of finding them in testing.
The purpose of test planning therefore is to put together a plan which will deliver the right tests, in the right order,to discover as many of the issues with the software as time and budget allow.