This should both interface to existing requirements tools and yet
allow testers to enter requirements baseline data for test-group use alone (there may be contractual
reasons why the original requirements specification or tool data cannot be changed). Users should
have user-definable fields in which to enter requirement data. Requirements can then be assigned
to team members. Requirements should be maintained in a central repository along with the
history of each requirement??™s evolution.
1
Assumes no integration testing of compiled units need occur which today is usually the case.
Testing Processes and Infrastructure
97
5.
Test case management
. The tool should
support
test case identification and development. Each
test case should:
a. Be traceable to one or more requirements.
b. Be assignable to a team member.
c. Relate to at least one test script. If the script detects a bug this should automatically provoke
the raising of a bug report.
d. Have several statuses: { under development | completed | run | passed | failed }. ???Failed??? will
automatically generate a bug record.
e. Have a change history.
f. Relate to a feature.
6.
Bug management
. Bug reports are typically raised when a test case fails. The bug report should
include details of the case, the script, the baseline, and the test run. The tool should also provide
a place to track
support
issues and enhancement requests.
7.
Logging.
The tool should simplify the logging of test run events other than bugs such as the nonavailability
of an environment, the beginning and end times of test runs, and environment changes.
Pages:
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257