How much test coverage do we need? See section 2.8.
2. How many tests do we need to write to achieve that level of coverage? See section 18.12.
3. How many tests have been written?
4. How many tests have been run? See section A.6 in Appendix A.
5. How many bugs have been found?
6. Have we found as many as we expected? See section 18.10.
7.5.1 Test Monitoring Document
Create a spreadsheet such as the
Test monitoring document
in section 8.6 for daily use. Keep it on your
lap-top and use it at meetings. It should tell you:
??? The expected and actual number of tests to be developed
??? The expected and actual number of tests run
??? The proportion of units of a release that have been tested
??? The number of system features tested
??? The priority of each feature
??? The test coverage of each feature
??? Bugs found per feature
??? Bugs found to date (
expected
against
actual
)
7.5.2 Test Objectives
The details of tests can confuse. Ensure each test has a simple title by which you can recognize it. This
will enable you to connect the test to the strategic question you are trying to answer and act as a
placeholder for the test architect.
As tests are planned, relate them using the test objectives in your spreadsheet and group them by
feature. See section 8.8.3, sections 14.4 and 14.5.1, section A.1, section A.3, and section A.11.7 in
Appendix A for examples of the sources and types of test objectives.
7.
Pages:
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266