??? The system tests for the build incorporating the changes are updated and once the build is
successfully system-tested, the units are moved into the system build library. To speed the release
try using the two charts prepared (see
Figure 7.8 and Figure 7.9 for details) to show the system
test coverage, such that those tests affecting the changed units can be run immediately after the
smoke, confidence and any regression tests. In this way a new release can be made:
??“ Unofficially as soon as the changed units have been exercised
??“ Officially as soon as the tests have all been run to some level of satisfaction
Complete a system test after an unofficial release since there is always the risk of unexpected side effects.
The test environment should be stable, with all development of the test configuration suspended
during testing.
Daily builds
alla
Microsoft
are an invaluable means of testing that the automated build scripts work.
7.3 Test Environment
Test development, execution, and management are simpler with a test environment. Here??™s a list of
desirable features:
1.
Scheduler.
A place to create, review, display, and send alerts concerning meetings, project deadlines,
and tasks to team member??™s calendars.
2.
To Do
list(s).
3.
Project tasks
, showing:
a. Deliverables to and from the project
b. Milestones
c. Workpackages
which can be stored, edited, and viewed by all team members.
4.
Requirements management
.
Pages:
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256