7.5 Test Plan

   

---

How do you know when you have finished? Sounds like a stupid question, but it is when there is no more software to write of course! Wrong. You are finished when you meet the test plan. The test plan should detail exactly what the system should do, what the interactions are, the expected outputs, and so on. It should exercise the system in normal scenarios as well as abnormal, so there are no hidden surprises . Most importantly, it should prove that all the requirements are met. If missing or poor requirements are the primary reason for projects failing, then lack of a test plan is second. We have been involved in projects that have never ended because no one knew where the end was.

Another pitfall is writing the test plan at the end. Come on! Why an earth would you write it before the software has been written? The answer is simple, all these documents need to be agreed upon, which means they give a common discussion point for all concerned . You need to get everyone to buy into these documents, all expectations should be thrashed out, and then all will know what is expected.

Table 7.1. Button and lamp tests

Action	Result	Pass/Fail
Press button X	Lamp X lights	Pass
Etc. . . .

Having the test plan at hand will aid the software construction process immensely. Whenever the developers raise questions about how a certain aspect of the system should perform, consult the test plan. It will aid the entire process. It will also enable unit testing to be clearly applied, since it will not only give a clear insight into the overall goals of the system but also gauge the performance of your components as they are built.

All of our test plans use the same layout, a table with three columns as shown in Table 7.1.

This makes all tests simple to evaluate and gives a clear indication of completion and to what criteria.

How did you ever live without it?

---

Top