The purpose of testing is to reduce risk.
The unknown factors within the development and design of new software can derail a project and
minor risks can delay it.
By using a cycle of testing and resolution you can identify the level of risk,
make informed decisions and ultimately reduce uncertainty and eliminate errors.
Testing is the only tool in a development's arsenal which reduces defects. Planning, design and QA
can reduce the number of defects which enter a product, but they can't eliminate any that are
already there.
And any kind of coding will introduce more errors since it involves changing
something from a known good state to an unknown, unproved state.
Ideally testing should take place throughout the development life cycle. More often than not (as in
the waterfall model) it is simply tacked onto the back end. If the purpose of testing is to reduce
risk, this means piling up risk throughout the project to resolve at the end – in itself, a risky tactic.
It could be that this is a valid approach. By allowing developers to focus on building software
components and then, at a later date, switching to rectifying issues it allows them to
compartmentalise their effort and concentrate on one type of task at a time.
But as the lag between development and resolution increases so does the complexity of resolving
the issues (see “Test Early, Test Often” in the nextc hapter).
On any reasonably large software development project this lag is far too long. Better to spread different phases of testing throughout the life cycle, to catch errors as early as possible.
The unknown factors within the development and design of new software can derail a project and
minor risks can delay it.
By using a cycle of testing and resolution you can identify the level of risk,
make informed decisions and ultimately reduce uncertainty and eliminate errors.
Testing is the only tool in a development's arsenal which reduces defects. Planning, design and QA
can reduce the number of defects which enter a product, but they can't eliminate any that are
already there.
And any kind of coding will introduce more errors since it involves changing
something from a known good state to an unknown, unproved state.
Ideally testing should take place throughout the development life cycle. More often than not (as in
the waterfall model) it is simply tacked onto the back end. If the purpose of testing is to reduce
risk, this means piling up risk throughout the project to resolve at the end – in itself, a risky tactic.
It could be that this is a valid approach. By allowing developers to focus on building software
components and then, at a later date, switching to rectifying issues it allows them to
compartmentalise their effort and concentrate on one type of task at a time.
But as the lag between development and resolution increases so does the complexity of resolving
the issues (see “Test Early, Test Often” in the nextc hapter).
On any reasonably large software development project this lag is far too long. Better to spread different phases of testing throughout the life cycle, to catch errors as early as possible.
No comments:
Post a Comment
Any Question? Ask here...