And maybe it??™s in Microsoft??™s best interests to have competitors throwing badly-tested software
onto the market certain in the belief that this way they are ???competing head-on with Microsoft.???
The reality is rather different: in key areas Microsoft tries to get it right before they get it to market.
Don??™t compete head-on with a brick wall.
T
94
Manage Software Testing
7.1.2 Test Plan
See section 8.5 for more details of a test plan document. Create one for each release (put any rarelychanging
stuff in the test strategy document).
Use the test plan to stay focused on the problems of this particular release. Completely rewrite this
document for each release or every six months (whichever is sooner). For faster-changing projects
consider using a test monitoring document (later in this chapter) instead.
7.2 Keeping the Configuration Management System in Order
There are three principal causes of software change:
1. To correct some bug
2. To add some new feature
3. To adapt to a changing environment
It is well known [Hetzel] that corrections are a prime source of bugs. These occur for two reasons:
1. Changes are made to code without such changes being reflected in higher-level specifications.
Consequently:
??? The specifications are increasingly inconsistent with the code.
??? It is not possible to analyze the effects of the change.
??? The changes have unforeseen side effects.
??? The change is itself faultily-applied.
Pages:
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251