A Full Software Development Lifecycle Testing Project - Software Testing: Testing Across the Entire Software Development Life Cycle - page 216

13.4.4 Design Test Planning

When the logic design is drafted, the testing team starts writing the test plan, the
next step after the testing strategy in the “P” of S P RAE. As the logical design is
refi ned, the test plan is refi ned and the test cases are written. The Case Study B De-
sign stage section shows you what the test plan might look like by the time the logic
design is completed.
At the beginning of the logical design phase, the design details are sketchy at
best. Rather than trying to guess the design details and start writing test cases, con-
sider blocking out groups of test cases that you will most likely need to write as the
details become available. The authors have found two patterns of test case groups to
be useful as starting points.
The fi rst pattern of test cases is for the use cases. Regardless of the actors in-
volved, you can anticipate some kind of user process to be executed with some kind
of results captured in some kind of data fi le. Many times, the speed with which the
software allows you to complete the process is also of interest. Therefore, our fi rst
draft list of test cases for use cases is a group of four test cases per use case: FTPOS-
nn . m , FTNEG- nn . m , ST- nn.m , and PT- nn.m . The nn.m notation indicates use case
UC-nn process path m where m 0 is the main path or “happy path” and m 1 is the

fi rst alternate path, m 2 is the second alternate path, and so forth.

The FTPOS- nn.m test case will use positive functional testing techniques
described in Chapter 7 to validate the operation of the input data fi elds and ac-
tions on each screen. The FTNEG- nn.m test case will use negative functional test-
ing techniques described in Chapter 7 to try to “break” the operation of the input
data fi elds and actions on each screen. The FTDAT- nn.m test cases will use data-
base testing techniques described in Chapter 7 to validate the associated use case
ADD, CHANGE, DELETE, and SEARCH data fi le activity hidden from the user's
view. The PT- nn.m test cases will use performance testing techniques described in
Chapter 9 to verify that the search times are not linear with respect to the increasing
size of the master fi les; the backups can be accomplished within the available busi-
ness day window; and the record archiving can be accomplished within the available
business day window.
The second pattern of test cases is for the user interfaces and architecture design,
which may not be associated directly with any use cases. As we have seen from the
testing strategy, the test planning activity must pay attention to the support levels of
hardware and software in addition to the application software being developed.
Our draft list of test cases for the user interfaces is a group of test cases pre-
fi xed by UI for “user interface.” The draft list will contain test cases designated
IUFTPOS- nn for positive menu tests, IUFTNEG for negative menu tests, and
UIERMSG- nn for menu error message tests. The nn is an arbitrary sequential
number usually beyond the range of the use case numbering. For Case Study B, we
started numbering the user interface test cases at 20.
Our draft list of test cases for the architecture design is a group of test cases
prefi xed by ST for “structural test.” The draft list will contain test cases des-
ignated STHWR- nn for hardware test cases and STSWR- nn for software test