Page 265 - DCAP305_PRINCIPLES_OF_SOFTWARE_ENGINEERING

Unit 13: Testing

one common form of the phrase that exists in the industry’s shared consciousness. Each of Notes
these statements has an effect on the person hearing them or thinking about them. And each of
the Development Lifecycle personnel, no matter what their role is, will re interpret the phrases
based on their own experience. The benefit of such statements is that they provide something
to think around. The danger is that the brain loves to simplify things, identify patterns, reduce
and compartmentalise information and can therefore build a less than optimal reasoning chain.
• Testing can only prove the presence of faults and not their absence
• The objective of testing is to find faults

• A good test is one that has a high chance of finding a fault
• A successful test is one that finds a fault
• An unsuccessful test is one that does not find a fault

• Testing can only prove the presence of faults
• Testing cannot prove the absence of faults.
Practicing tester might well argue about statement as it may run contrary to their experience and
the aims of testing as defined by their organization. One of the aims of their testing process is to
validate the requirements, in effect, to prove the absence of faults. If a test runs to completion
without a fault being identified, and on repeated runs (when it is run in exactly the same way)
does not identify a fault. Possibly, but we cannot prove it. The test did not identify a fault but
that does not mean that at a lower level of abstraction than the test was described in terms of,
a fault did not occur. Perhaps the results were merely coincidentally correct.
13.1.5 Failure

If under certain environment and situation defects in the application or product get executed
then the system will produce the wrong results causing a failure. Not all defects result in failures,
some may stay inactive in the code and we may never notice them. Example Defects in dead
code will never result in failures. It is not just defects that give rise to failure. Failures can also
be caused because of the other reasons also like.
• Because of the environmental conditions as well like a radiation burst, a strong magnetic
field, electronic field or pollution could cause faults in hardware or firmware. Those faults
might prevent or change the execution of software.
• Failures may also arise because of human error in interacting with the software, perhaps
a wrong input value being entered or an output being misinterpreted.

• Finally failures may also be caused by someone deliberately trying to cause a failure in
the system.

The main premise is that scientists get so comfortable with accepted theory and the status quo
that they do not recognize that failures might be breakthroughs instead of just mistakes in their
own equipment or experimental method. There is certainly some value there gives the example
of sensitive radio telescope static finally being accepted as cosmic background radiation and not
a problem with the dish, and cites some serious ethnographic research of scientists and how
they make discoveries.
Fault: It is a condition that causes the software to fail to perform its required function.
Error: Refers to difference between Actual Output and Expected Output.

Failure: It is the inability of a system or component to perform required function according to
its specification.

LOVELY PROFESSIONAL UNIVERSITY 259