Information Technology Reference
In-Depth Information
as simple as possible, the test team would defi ne six test cases, one for each group
of data entry screens—regardless of the actual number of data entry screens to be
tested in each group. The writing schedule of these test cases then needs to be coor-
dinated with the developer schedule for these data entry screens.
Another common example of test case planning is performance testing. Al-
though we have not yet discussed the particulars of performance testing, hopefully
the reader can identify at least four potential test cases for most applications: a base-
line performance test case, a batch workload test case, an online workload test case,
and an Internet workload test case.
5.3.1 Test Case Details
The purpose of the test plan is to collectively document the testing “what” and “why”
for this application. We focus on the testing “how” for this application by drafting
test cases. As we saw with the test plan terminology, you will fi nd references to these
“how” test documents as test scenarios, test cases, and test scripts elsewhere. As long
as you understand the purpose of these test documents and confi rm that you are col-
lecting all the information necessary for successful testing, the terminology choice is
arbitrary. For the purposes of discussion in this textbook, the detailed test execution
document will simply be called the test case.
The contents of the test case take on the narrow focus of just one of many testing
activities that collectively support the overall test plan. Defi ning the boundaries of
a good testing case is still very much an art that is learned over a number of years
of testing experience. A good starting place is to identify some of the smallest or
simplest business activities that the new software needs to support and defi ne test
cases for each of these activities. Then, defi ne test cases that portray either larger
business activities or specifi c sequences of smaller business activities that tend to
approximate useful business tasks. Check the software business requirements and
confi rm that you have accounted for all required business activities with your test
cases and add test cases for the business activities that are not covered yet by testing.
We will examine some test cases in Chapters 8 and 9 that cover other aspects of the
software besides business activities, but business activities are the logical starting
place for designing test cases. Test cases should include the following:
1.
2.
3.
4.
5.
6.
7.
8.
unique test case ID (from test plan)
unique title (from test plan)
brief description (from test plan)
development phase in which this test case is executed (from test plan)
specifi c testing goals and their achievement measures
suggested test data
suggested test tools
test startup procedure
Search WWH ::




Custom Search