Page 165 - SOFTWARE TESTING & QUALITY ASSURANCE

Software Testing and Quality Assurance

11.1.2 Test Design
The overall test plan for the project is written at a very high level. It breaks up the software into specific
modules based on the features and testable elements and assigns them to individual testers, but it does
not specify as to how those modules will be tested. There may be an indication of using automation,
black-box, or white-box testing, but the test plan does not get into the details of exactly where and how
they will be used.
IEEE 829 states that “the test design specification improves the test approach (defined in the test plan)
and finds the modules to be covered by the design and its associated tests. It also identifies the test cases
and test procedures, if any, required to accomplish the testing and specifies the feature pass/fail
criteria.”
The purpose of the test design specification is to organize and describe the testing that needs to be
performed on a specific module. However, it does not provide the detailed cases or the steps needed to
perform the testing. The following points, adapted from the IEEE 829 standard, address this purpose
and should be part of the test design specifications that you create:
1. Identifiers: A unique identifier that can be used to refer and locate the test design specification.
The specification should also refer to the overall test plan and should contain pointers to any
other plans or specifications that it refers to.
2. Features to be Tested: These contain a description of the software feature covered by the test
design specification. The example below illustrates the features to be tested for a calculator.

These are some of the features of a calculator that need to be tested.

1. The addition function of Calculator
2. Font size selection and display in WordPad
3. Video card configuration testing of QuickTime

This section should also identify features that may be indirectly tested as a side effect of testing
the primary feature.

Although not the target of testing a calculator, the user interface of the file
open dialog box will be indirectly tested in the process of testing the load and
save functionality.

It should also list features that will not be tested and may be misunderstood as being covered by
this plan.

Testing the calculator's addition function will be performed with automation by
sending keystrokes to the software. Hence, there will be no indirect testing of
the onscreen user interface.

3. Approach: This includes a description of the general approach that will be used to test the
features. It should give details about the approach, if any, listed in the test plan, describe the
technique to be used, and explain how the results will be verified.

A testing tool will be developed to sequentially load and save pre-built data
files of various sizes. The number of data files, the sizes, and the data they
contain will be determined through black-box techniques and supplemented
with white-box examples from the programmer. A pass or fail will be
determined by comparing the saved file bit-for-bit against the original, using a
file compare tool.

158 LOVELY PROFESSIONAL UNIVERSITY