There are two different ways to approach developing your test plan and these two ways are commonly known as black box and white box.
With developing a black box test plan you do not consider the actual code to be tested at all in developing your test plan. The test plan simply considers tests where if you feed X into the test you expect result Y. How the actual code gets from X to Y doesn't matter. This type of test plan can be developed long before any code is written. It can also be developed by someone who has never seen the code in the script or by someone who couldn't understand the code even if they did see it.
With black box testing it is only the results that matter. Provided that the actual code will produce the appropriate Y for each and every X in the test plan then that code will be considered to have passed all the tests.
A white box test plan is developed from the code itself. Every logic test in the program whether it be an if statement, a switch, or some type of loop will result in two or more different tests being developed, one to follow each path through that piece of the code. The overall list of tests that are developed by examining the code will ensure that every path through the code is run by at least one of the tests.
With white box testing the code must be written before the test plan because the tests will be developed from the code.
Each of these approaches has advantages and disadvantages.
- A white box approach makes sure that every path through the code gets run whereas a black box approach will not necessarily run every path.
- A black box test plan runs all of the tests that matter in making sure the script can handle everything it is supposed to handle. A white box approach doesn't test for your having left out a path in the code completely.
- A white box approach tests the code to make sure that the code does what the code has been written to do. A black box approach tests that the code does what the requirements specify that the code is to do. These are not necessarily the same thing.
One situation that you may want to consider is what happens if you have a white box test plan and one of the modules is completely rewritten so as to produce the required results in a totally different way. So now your test plan no longer covers all of the paths through that module the way it did before. Does this matter? After all the substitute module is supposedly doing exactly the same thing as the prior version, just in a totally different way and so if you were to run all of the tests you had developed for the prior version then they should all produce the exact same results in the new version because if they don't then the new version of the module isn't a proper substitute for the old version.
The actual choice between a black box and a white box approach to developing your test plan is actually far less important than that you develop a test plan in the first place. Any test plan is far better than no test plan at all particularly when it comes to retesting your code to ensure that the changes that you have made to implement a new feature have not had any unwanted effect on any of the functionality that already existed in the code before the change.
Of course if you develop the test plan prior to the code itself being written then the black box approach is the only one possible since you don't at that point have any code to use as the basis for a white box plan. That of course opens up an alternative possibility - that of using the test plan as an aide to writing the code itself. Tempting as this might be, I think it is better to not consider the test plan at all when writing the actual code. This way you maintain the advantages of a black box test plan.
It may still be worthwhile cross checking that all of the paths through the code you have written are included in your test plan. If you have a path without a test then either you have an unnecessary path or you have omitted a test.Resolving the discrepancy will result either in more efficient code or in a better test plan.