Overview of Testing - Software Testing: Testing Across the Entire Software Development Life Cycle - page 10

Testing objective 3: Know when testing is completed.
Knowing that 100% testing of the development is unachievable, the tester must
a p p l y s o m e k i n d o f p r i o r i t i z a t i o n t o d e t e r m i n e w h e n t o s t o p t e s t i n g . T h a t d e t e r m i n a t i o n
should start with the positive test items in the test plan. The tester must complete the
positive testing that validates all the development requirements. Anything less, and
the tester is actually introducing business risk into the development process.
The tester must then complete as much of the risk-targeted testing as possible
relative to a cost and benefi t break-even point. For example, if there is a $10,000
business risk in some aspect of the development, spending $50,000 to reduce that
risk is not a good investment. A rule of thumb is a 10-20% cost to benefi t break-even
point for testing. If the same $10,000 business risk can be thoroughly tested for
$1000-2000, then cost to benefi t is very favorable as a testing investment.
Finally, the tester must complete as many of the negative test items in the plan
as the testing budget allows after the positive testing and risk testing are completed.
Negative testing presents two situations to the test planner:

• The fi rst situation is the complement of the positive test items. For example, if

a data fi eld on a screen must accept numeric values from 1 to 999, the values 1,
10, 100, 123, 456, 789, and 999 can be used for positive test completion while
the values 1, 0, and 1000 can be used for negative test completion.

The second situation is the attempt to anticipate novice user actions that are not
specifi ed in the requirements or expected during routine business activities.
Planning these kinds of tests usually takes deep insight into the business and
into the typical ways inexperienced business staff perform routine business
activities. The time and expense necessary to test these “outlier” situations
often are signifi cantly out of proportion to the likelihood of occurrence or to
the magnitude of loss if the problems do occur.

•

Testing objective 4: Manage testing as a standard project within the development
project.
All too often, testing is treated as a simple skill that anyone can perform without
planning, scheduling, or resources. Because business risk represents real dollar loss,
real dollar testing is required to reduce the risk. Real dollar testing means that per-
sonnel with testing expertise should be formed into a testing team with access to the
management, resources, and schedules necessary to plan and complete the testing.
The testing team, as any other business team, can deliver the testing results on time
and within budget if the team follows good standard project management practices.
The benefi t of this observation is the reassurance that testing does not have to
be hit or miss. It can be planned and completed with the confi dence of any other
professional project to achieve its objectives. The liability of this observation is the
realization that testers are a limited resource. When all available testers are scheduled
for an imminent testing project, further testing projects cannot be scheduled until
you fi nd additional qualifi ed testers.

When you run out of time to test
As with all project schedules, it is possible to run out of testing time. If that situation
arises, what can be done to make the most of the testing that you can complete? When