Testing Computer Software phần 9 pptx

225

• Dollars. Management can try to add features more quickly, rather than dropping them, by spending

money. However, because new features haven't yet been fully specified or designed, the project's

designers may become bottlenecks.

• Release date. The power of the evolutionary approach is best seen in the degree of schedule control

that it gives management. The project manager can always postpone the release date. Often, though,

he will choose to ship the product on time rather than adding those last 15 features.

Because the program is always stabilized before the next wave of features is added, a proj ect manager

who decides to stop adding features can probably finish the project within a few weeks.

• Reliability. The reliability of evolutionary products is high. Because the product is tested and

stabilized as each new piece is added, most of the project's testing budget is spent before the end of

the schedule. If management says stop adding features and get the thing ready to ship, it won't take

much additional final testing before the product is ready forrelease. The incentive to skimp on testing

and release something buggy is gone.

The testing cost under the evolutionary model threatens to be large because testing starts early. However,

much of that cost is recouped because there isn't so much testing at the end. Further, all those features that

weren't specified or coded weren't the subject of test plans or tests either.

One way to make a mess of an evolutionary project is to have the programmers keep writing fresh code rather

than fixing the problems discovered during testing. This is very tempting when the project is running behind

schedule, but the appearance of progress is deceiving. The problems will take longer to fix and retest later.

The project manager will face last minute tradeoffs between reliability and release date.

Another risk of adopting an evolutionary approach is that an inexperienced project

manager may imagine that he doesn't have to do much initial planning, because the product

will evolve over time. This is a big mistake. If the core is built inflexibly, it will need

extensive reworking before key features can be added. Fundamental work might have to be

redone many times. Also, at what should be the end of the project, the marketing group might

realize that they forgot to identify some features as critical, so others were done instead. Now

the product has to wait until those features are added.

Marketing and sales staff sometimes don't understand this approach well enough to realize that when the

project manager says that some features might be in the product or they might not, no one should sell the

product as if it has a given feature, until that feature has been added.

The test manager has another way to ruin the project. If he doesn't assign test resources to the project early

(perhaps because they're still assigned to some other project that's behind schedule), then the core program

doesn't go through the full test cycle, nor do the incremental changes. No one sees this slippage on the schedule

until the testing staff are finally assigned, perhaps near what should be the very end of the project. At that point,

the testers are in the traditional system test situation, with a big pile of untested code and very little remaining

testing time left in the schedule. The result is something that looks like a badly managed waterfall project—

testing costs more, the schedule falls apart, and lots of bugs are missed.

The Testing Group probably has more ability to destroy an evolutionary project than anyone else. Be

considerate of this risk.

226

A DEVELOPMENT MODEL'S IMPLICATIONS FOR TESTING

Once you understand the project manager's development model from his point of view, think about its

implications for the testing effort. Here are some implications of the waterfall method:

• Review the user interface early, perhaps by testing prototypes. If the user interface is specified and

approved before the code is written, usability tests near the end of the project won't have much effect.

• Start writing the test plan as early as possible because this will force you to critically analyze the

specifications (or drafts of them). Any risks they pose for testability of the project must be raised early.

Theoretical models are important, but you must also be effective when managers throw out the rule book. Think

about this Figure as you read the tidy sequence of tasks in this chapter.