Page 164 - SOFTWARE TESTING & QUALITY ASSURANCE

Unit 11: Test Case Planning

Figure 11.1 shows the relationships among the different types of test plans.
Figure 11.1 Relationships Among the Different Types
of Test Plans

As shown in Figure 11.1, tracing down from the top-level test plan, less emphasis is given to the process
of creation and more to the resulting written document. The reason for this is that the test plans become
so useful that they are used on a daily, sometimes hourly, basis by the testers performing the test.
The information on test planning provided in this chapter is adapted from the IEEE 829 Standard for
Software Test Documentation (available on standards.ieee.org). This standard is widely used by many
testing teams as test planning documentation, because it represents a logical and reasonable method for
test planning. The important thing to understand about this standard is that it should be used as a
guideline and not a standard. You are bound to follow it strictly only when the type of software you are
testing demands it or if your company or industry policy instructs you to follow the standards.

However, what used to be presented as a written document can be better and more efficiently presented
today as a spreadsheet or a database. The test team should create test plans that include the information
outlined in IEEE 829. If written documents work best, then they are used. However, if a central database
proves to be more efficient and there is time and budget to develop or buy one, this approach is
adopted. This is because the four goals of test planning -- namely organization, repeatability, tracking,
and proofing should always be met.

It is important that the test cases, whose expected result is an error, have conditions.
Only by testing the software for such non-regular conditions can it be assured that the
software does not produce undesirable and unexpected situations.

LOVELY PROFESSIONAL UNIVERSITY 157