The 7 Principles of Software testing

1. Exhaustive testing is not possible

Exhaustive testing, which is also known as complete testing, occurs when all the testers in your team are exhausted and when all the planned tests have been executed. It is a quality assurance testing technique in which all scenarios or data is tested for testing. In a more understandable way, exhaustive testing means ensuring there are no undiscovered faults at the end of the test phase. Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases. As testers, we often say “well I just never have enough time for testing”. Even if you had all the time in this world, you still wouldn’t have enough time to test all the possible input combinations and output combinations.

 Instead, we need the optimal amount of testing based on the risk assessment of the application.

And the million dollar question is, how do you determine this risk?

To answer this let's do an exercise

In your opinion, Which operation is most likely to cause your Operating system to fail?

I am sure most of you would have guessed, Opening 10 different application all at the same time.

So if you were testing this Operating system, you would realize that defects are likely to be found in multi-tasking activity and need to be tested thoroughly.

2. Defect Clustering

Defect clustering principle states that a small number of module contains the most number of defects.

This application of Pareto principle that 80% of the defects are found in 20% of the modules.

By experience, you can identify such modules in your application.

3.Pesticide Paradox

Definition: If the same set of tests are repeated over and over again, eventually the same set of test cases will no longer find any new defects. To overcome this "Pesticide paradox", the test cases need to be regularly reviewed and revised.

For example,

In the initial stages of software development the testers find several bugs in a particular module.

The bugs are now fixed and all the test cases are passing. With time these test cases will continue to pass but this does not mean that the module is totally bug free. The team needs to regulary review and revise the test cases and find new ways to test the module. example, start looking into the documentation to find any gaps or defects

4. Testing shows the Presence of defects but cannot prove that the software is defect free.

Testing can show that defects are present, but cannot prove that there are no defects. 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.

5. Absence of Error 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.

6. Early Testing

Early Testing - Testing should start as early as possible in the Software Development Life Cycle. So that any defects in the requirements or design phase are captured in early stages. It is much cheaper to fix a Defect in the early stages of testing. But how early one should start testing? It is recommended that you start finding the bug the moment the requirements are defined. 

7. 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.