But if the answer to these questions is ???yes,??? and we??™ve exercised all the code, and we??™ve tested all the
features, then the software is ready for release.
See [Johnson] for details of the LEAP open toolkit and experience in estimating project size and bug
numbers.
4.6.6 Test Outputs
You should write:
??? A test plan (see Chapter 8). Even if no one wants to see it, and it isn??™t contractually-required, write it
anyway. It??™ll help you think. You need this to get an overview of where you and your team are going.
It??™s just a plan with activities, schedules, and responsibilities. It isn??™t a test specification (see below).
??? A test (case) specification (see Chapter 8) because what the developers build to, and what you
test, aren??™t the same thing. They are simply two views. You need your own. Thus the requirements
specification may say good things about the information appearing on a screen. The test case
specification goes into detail about how you are to test that screen and what happens when you
press button ???B.??? If you are wise and minimally-funded you will have written this using test
management software. The test case specification may (if it??™s embedded in the test management
tool) also be the tests you will run.
??? Test reports (see section 8.18).
??? Release notes.
You will find it useful to write a test strategy document (see Chapter 8).
Internal test standards are useful to convince assessment bodies and train new testers with.
Pages:
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198