Information Technology Reference
In-Depth Information
Chapter
6
Software Testing Project
Risk Management
Any project is supposed to be delivered at an agreed-upon time at agreed-upon costs
and with agreed-upon product or service quality. If the project meets these objectives,
then it is considered to be successful. If not, then it is supposed to be a failure.
The goal looks so simple. But there are always inherent risks involved in any
project which undermine any or all of its objectives. Due to these risks, the project
can be delayed, cost overruns may happen, or the delivered product or service may
be of poor quality.
Software testing projects are no different when it comes to meeting these same
objectives: delivery at an agreed-upon time, at agreed-upon costs, and at agreed-
upon quality. There is one more dimension to software testing projects along with
these goals: effectiveness of software testing! Even if the project deliverables look
good but the testing team actually finds a fewer number of defects than anticipated
(using software engineering defect estimation techniques), then the project team has
failed in its job. So many times the team tries to find more defects irrespective of
whether the defects are critical to the end users. This way of doing things only brings
mediocrity to the project. It fails from the perspective of effectiveness of efforts put
into the project. If the team has not found critical defects that are later found by end
users, then no matter how the team defends itself they have failed miserably.
Any software product may have different kinds of defects, and their impact
on the product may be different. That is why we have must-fix defects and not-so-
critical defects. Effectiveness applies more to these must-fix defects. So the testing
team's performance is measured in terms of how many must-fix defects have been
found by them and later on, when the tested application is used by end users, how
..
Search WWH ::




Custom Search