Scribd
Upload
49 views

Software Validation and Verification (SQT) Testing:: Seven Principles of Testing

1. Testing shows the presence of defects, not their absence. While testing can reduce undiscovered defects, finding no defects does not prove correctness. 2. Exhaustive testing is not possible due to the large domain of possible inputs. Optimal testing based on risk assessment is needed instead. 3. Early testing throughout the software development life cycle is better to minimize later defects. Defects are cheaper to fix early.

Uploaded by

Romaz Riaz
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
49 views

Software Validation and Verification (SQT) Testing:: Seven Principles of Testing

1. Testing shows the presence of defects, not their absence. While testing can reduce undiscovered defects, finding no defects does not prove correctness. 2. Exhaustive testing is not possible due to the large domain of possible inputs. Optimal testing based on risk assessment is needed instead. 3. Early testing throughout the software development life cycle is better to minimize later defects. Defects are cheaper to fix early.

Uploaded by

Romaz Riaz
Copyright
© © All Rights Reserved
Available Formats
Download as DOCX, PDF, TXT or read online on Scribd
You are on page 1/ 3

Software Validation and Verification (SQT)

Testing:
Seven principles of Testing:
1.Testing shows a presence of defect
Testing talks about the presence of defects and don't talk about the absence of
defects. i.e. Software Testing reduces the probability of undiscovered defects
remaining in the software but even if no defects are found, it is not a proof of
correctness. But what if, you work extra hard, taking all precautions & make your
software product 99% bug-free. And the software does not meet the needs &
requirements of the clients. This leads us to our next principle, which states that-
Absence of Error

2. Exhaustive testing is not possible


It is not possible to perform complete testing. For most of the systems, it is near
impossible because the domain of possible inputs of a program is too large to be
completely used in testing a system. Exhaustive testing is not possible. Instead, we
need the optimal amount of testing based on the risk assessment of the application.
Which operation is most likely to cause your Operating system to fail? Opening 10
different application all at the same time.

3. Early testing
A defect can be found throughout all the phases of software development Life
Cycle. So, it is better to start early Testing in the software development life cycle,
so as to minimize defects in the later stages. Such as design review, unit testing. It
is much cheaper to fix a Defect in the early stages of testing. It is recommended
that you start finding the bug the moment the requirements are defined. More on
this principle in a later training tutorial.
4. Defect clustering
Defect Clustering which states that a small number of modules contain most of the
defects detected. The majority of the defects are caused by a small number of
modules. By experience, you can identify such risky modules. But this approach
has its own problems If the same tests are repeated over and over again, eventually
the same test cases will no longer find new bugs.

5. Pesticide paradox
Repetitive use of the same pesticide mix to eradicate insects during farming will
over time lead to the insects developing resistance to the pesticide Thereby
ineffective of pesticides on insects. The same applies to software testing. If the
same set of repetitive tests are conducted, the method will be useless for
discovering new defects. To overcome this, the test cases need to be regularly
reviewed & revised, adding new & different test cases to help find more defects. It
must look out continually to improve the existing methods to make testing more
effective. But even after all this hard work in testing, you can never claim your
product is bug-free.
A company like MICROSOFT would not have tested their OS thoroughly & would
risk their reputation just to see their OS crashing during its public launch!

6. Testing is context dependent


Testing is context dependent which basically means that the way you test an e-
commerce site will be different from the way you test a commercial off the shelf
application. All the developed software’s are not identical. You might use a
different approach, methodologies, techniques, and types of testing depending
upon the application type. For instance, testing, any POS system at a retail store
will be different than testing an ATM machine.
7. Absence of errors fallacy
It is possible that software which is 99% bug-free is still unusable. This can be the
case if the system is tested thoroughly for the wrong requirement. Software testing
is not mere finding defects, but also to check that software addresses the business
needs. The absence of Error is a Fallacy i.e. Finding and fixing defects does not
help if the system build is unusable and does not fulfill the user's needs &
requirements.

You might also like