What are Software Testing Principles?

---

Welcome to this Post – ” What are Software Testing Principles?”.

This post discusses about the ” What is Software Testing Principles?”. We will focus on definitions, why and which principles is important to be considered around the software testing plus see examples on principles to completely grasp the concept.

So, go ahead and enjoy reading…

 

Below are the 7 Software Testing Principles

---

Principle 1: Testing shows presence of defects

Testing is primarily being taken into account to uncover defects or errors. This means that focus is only on finding defects, faults or errors in accordance to the requirements. This also means the Testing cannot prove that there are no defects. No software is defect free but Software Testing reduces the probability of uncovered defects remaining in the software but on the other hand it doesn’t mean if no defects are found it can be seen a way of proving correctness of software.

For example: say a software is developed and testing has also been done on all parts of software but miraculously tester didn’t find a single defect. This doesn’t prove that software is correct.

 

 

---

Principle 2: Exhaustive testing is impossible

What is exhaustive testing? Exhaustive Testing means that tester should take into account all possible combinations for all parts of the system to test the software which is impossible. In other words, all combinations of inputs and preconditions is not feasible except for trivial cases.

For example, lets assume a system has four components. Each component has 15 units i.e. 4*15=60 units. Hence there are 60 units to be tested. These 60 units can be simple, independent on other units, or can be dependent on other units. To test one single unit, assume we might have 50 test cases on an average. Now if we multiply again 50*60=3000 test cases are needed for execution. You should consider few points before dealing with such scenarios:

Is this worth to be considered?

Can I have priorities defined for units?

How much risk is involved here?

How much do I have?

How many people or resources do I have?

In short, we never go ahead with exhaustive testing, instead we use risks and priorities to focus testing efforts.

 

---

Principle 3: Early testing

Most of the test team members think testing starts after unit testing done by developers, which absolutely a wrong perception. Software Testing activities should start as early as possible in the software or system development life cycle and should be focused on defined objectives.

For example, there are various methods available in static testing to start with reviewing i.e. Informal Reviews or Technical Reviews, walkthrough, etc.

 

---

Principle 4: Defect clustering

What is defect clustering? Defect clustering means that the majority of the defects are caused by a small number of modules, i.e. the distribution of defects is not across the application but rather centralized in limited sections of the application.

For example, in a certain defined time scheduled for testing of some module, you may find defects more and more which are related or dependent on other modules. These defects will be concentrated on very few modules but in high volumes.

 

 

---

Principle 5: Pesticide paradox

What is pesticide paradox? You must have encounter or must have come through this fact that whenever farmers use pesticides to eradicate insects during farming, the insects over time will lead to develop resistance to the pesticide. Thereby insects become ineffective of pesticides. Similar principle is applied here in testing, if the same set of tests are repeated over and over again, eventually there will no longer be any new bugs.

How to overcome of this problem? To overcome this ‘pesticide paradox’,

1. the test cases need to be reviewed and revised regularly.
2. new and different tests need to be written to exercise different parts of the software or system to potentially find more defects.
3. Old test cases should also be revised as per dependent functionality changes.

 

---

Principle 6: Testing is context dependent

Testing is done to uncover defects in software and to achieve this we cannot just use same type of testing across all parts of software and phases of development. Hence software testing is done differently in different contexts.

For example, when developer is developing software module, he may do unit testing. Once code is deployed to system integration environment testers do smoke, sanity, integration testing, functional testing etc.

 

 

---

Principle 7: Absence-of-errors fallacy

Any SDLC process’s ultimate goal is to have working user centric software without any defects or defects as low as possible. Performing testing in accordance of requirement to uncover defects and later fixing them doesn’t establishes that software which has been built is stable and user centric. This what last principle of testing focusses on stating that absence of errors doesn’t certify the software as a product is stable and will be as per user’s needs and expectation.

 

 

---

Conclusion

Software testing should be measurable, time bound and focused. These cannot be achieved if one skips the below principles. These principles also help in laying down the Test strategies around the requirement to be tested.

 

Principle 1      Testing shows presence of defects

Principle 2      Exhaustive testing is impossible

Principle 3      Early Testing

Principle 4      Defect Clustering

Principle 5      Pesticide Paradox

Principle 6      Testing is context dependent

Principle 7      Absence of errors – fallacy