Information Technology Reference
In-Depth Information
approaching the end of the testing schedule, consider doing a quick prioritization of
the outstanding defects. Place most of the testing and correction emphasis on the
most severe defects, the ones that present the highest possible business risk. Then
review the testing plans that you will not have time to complete and assess the risk
that the incomplete testing represents.
Present the development manager with an assessment of the risks that are ex-
pected due to the premature halting of testing. The development manager must then
decide whether to halt the testing to meet project schedules or to seek additional time
and resources to complete the testing as planned.
When you know you can not test it all—positive testing objectives
When you know you can not test it all, review all the completed testing results and
compare them with the application or system functionality that the customer has
deemed most important. The object of this review is to determine the features to test
with your remaining schedule and resources that would make the largest positive
impact on the customer's function and feature expectations.
When you know you can not test it all—hidden defect testing objectives
When you know you can not test it all, review the completed testing results and
determine if there are trends or clusters of defects that indicate more defects are
likely to be found in the same area. Then request a review of that area of code by
the development team to determine if additional, hidden defects can be corrected
by minor development rework. With minimal additional effort on the part of the
developer and tester, likely trouble spots can be addressed before the last remaining
testing resources are expended.
1.2.5 Development Axiom—Quality Must Be Built In
Because Quality Cannot Be Tested In
Testing can only verify the product or system and its operation against predetermined
criteria (requirements). Testing neither adds nor takes away anything. Quality
is an issue that is determined during the requirements and design phases by the
development project stakeholders or requesting customers. It is not decided at testing
time.
1.3 THE VALUE VERSUS COST OF TESTING
Most business decisions are based on a comparison of the value of doing something
versus the cost of doing something, typically called the
return on investment
(
ROI
).
ROI is the calculation of how quickly and how large the “payoff” will be if a project
is fi nanced. If the project will not quickly provide a payoff or the payoff is too small,
then the ROI is considered bad. The business motivation for doing something is to
receive more benefi t than the investment necessary to realize that benefi t.
Testing requires the same ROI decision as any other business project. The im-
plication is that testing should be done only when the test results can show benefi t
Search WWH ::
Custom Search