Every profession has some building block or principles and likewise any other profession testing too have some principle on which it relies. These define very basic yet roots of software testing and should be kept in mind while testing.
Software testing has seven basic principles and each of them have its own meaning /purpose. We can go in detail with each of the principle to understand its meaning.
Principle 1 – Testing cannot prove there are no defects
"testing shows that there are defects but it cannot prove there are no defects"
The basis of this principle is the fact that it there are always some scenarios /combinations left which are either not possible to test or are less important. Testing can always reduce the possibility of finding a failure of software in production but it cannot guarantee that the software is defect free.
Let’s take an example of some mail server like GMail or yahoo mail, no matter how thoroughly it was tested there will always be probability that it will not work properly on some newly developed browser. But after testing it is guaranteed that mail server will work on most of the web browsers.
Principle 2 – Exhaustive testing is impossible
"Exhaustive testing is not possible except of trivial cases."
Testing everything i.e. each and every possible combination of inputs and the precondition is not possible because there are constraints such as time limit or the cost of testing and in some cases testing each combination is not even practical.
For example if a user ID on a login page accept numbers and characters with a total max length to 15 then it would not be practical to test each and every combination of characters that are accepted for the user ID. That will consume much of time and will cost too much even if done by some automated program.
Principle 3 – Early testing
"Testing should start as early as possible in software development life cycle"
Once the development is started there remain many defects which costs more to fix then to fix them in requirement phase only or in other words if it is the responsibility of software testing to ensure the quality then imparting the quality process late would obviously cost something. As the development progresses costs to fix a defect increases because the area affected by the defect can be increased and/or the complexity of code is increased.
If a product has a feature which can never be used or wrongly represented in requirements document and testing is not started early i.e. with requirement phase itself then it would obviously convert to a faulty design and a lot a rework might need at later stage but if the testing process is implemented in the very beginning of software life cycle then the faulty design can be identified and the amount of rework can be reduced very much.
Principle 4 – Defect clustering
"A small number of modules usually contains most of the defects discovered during pre-release testing, or is responsible for most of the operational failures"
Usually it is observed that most of the defects that are identified for a software are from certain modules only and the testing should be focused on those modules only after observing the defect density.
Principle 5 – Pesticide paradox
"If the same tests are repeated over and over again, eventually the same set of test cases will no longer find any new defects."
We can understand this principle by the example of an agriculture farm where a farmer is using facing problems with some pests. Now one of his friend suggested his a pesticide, the farmer started using it and found that it removed the pests very significantly. He was so impressed that he used the same pesticide next year as well and then next many years. After few years he observed that his crop has developed pests and his old best friend the pesticide has no effect on the pests. He was very surprised and was not able to figure out the reason for the problem. any guesses why this happen?
Answer is simple, pests have developed immunity for the pesticide over the time.
Same thing happen with the software also, if same test is applied to the software repeatedly then the test would no longer uncover any new defects. Hence, to overcome this "pesticide paradox" it is advisable to always try to update and enhance your test cases. New and different test cases should be added to the test suit so that new defects can be uncovered.
Principle 6 – Testing is context dependent
"Testing is done differently in different contexts"
Same things are done differently for different contexts in our real life as well, like saying hello to your parents will have different tine than saying hello to your friend.
Similarly in software field testing is also done differently for software with different purposes. Like for a e-commerce website testing money transaction related tests is very crucial while for a satellite software most important thing is to make sure that satellite is able to communicate with ground station successfully
Principle 7 – Absence-of-errors fallacy
"Finding and fixing defects does not help if the system built is unusable"
Sometimes this happen that a software is built and validated with QA but still that remains unusable because it is unstable and does not fulfill the user requirements. So, it remains duty of a QA tester to always think from a user perspective and provide a feedback as if real production user would have been using the software.
