In the software testing industry, there are 7 principles of testing. It’s very important to learn about this principle because these are nothing but the pillars of your testing efforts.
But let me ask you one question. Do you really know the meaning of principle? If yes then please skip the next paragraphs and start reading about the principle from “What is Software Testing Principle?” section. If you don’t know the meaning of principle then please continue with this post.
What is Principle?
Basically, the principle is nothing but the rules or law which has to be followed.
Or you can say principles are the essential characteristic of the system which needs to follow for developing the best system. Ignoring any one principle may cost the effectiveness of the performance of the system. A principle of software testing refers to the brief mentioned and proven concepts which guide testing professionals during the software testing process.
What is ISTQB Software Testing Principle?
1st Principle: Testing Shows Defects Are Present In The Software
As per this principle, testing is a process which shows defects are present is software. Defects are identified by using different software testing execution techniques. At the same time, testing doesn’t prove that after finding defects that there are no defects present in the system. In many cases, it is identified that defects are present is software even after undergone through the rigorous testing activity. This principle talks about the reduction of a number of defects in software. There are always chances that the software has undiscovered defects, testing should not be considered as proof of defect-free software.
2nd Principle: Exhaustive Testing Is Not Practically Possible
If we talk about this principle, it says it is not possible to test complete software. Test with all combinations of inputs and outputs. Test with all possible scenarios is not possible. Then you must be thinking of how we will test the complete software. See, instead of performing complete or exhaustive testing, we go for risk-based testing. Identifying the impact can help us to identify the module which is on high risk.
Don’t think much about it, at this moment it is enough for you to know exhaustive testing is not possible. Later on, you will come to know, why principle itself says it not possible.
3rd Principle: Start Testing In Early Stage of SDLC
This principle asks to start testing software in the early stage of the software development life cycle. As we are starting a testing activity in early stage, this helps us to identify defects and fixed early with a low budget and within the assigned time period. It allows to handover ordered software on time with expected quality.
4th Principle: Defects Clustering
Usually, maximum defects in software lie within the limited set of software areas. If you successfully identify this area, it’s become quite a simple task for you to bring the that sensitive area under the focus of testing. It is considered as one of the most efficient ways to perform testing efficiently.
5th Principle: The Pesticide Paradox
If you are using the same set of test cases repeatedly, then after some time those test cases do not find any new defects. The effectiveness of test cases starts degrading after some round executions, so it is always recommended to review and revise the test cases on a regular interval in order to find new defects. It is allowed to add a new scenario or test cases even after the execution of a particular test set.
6th Principle: Testing is dependent on context
According to this principle; if you are testing a web application and mobile application using the same testing strategy, then it is wrong. This principle says the testing approach should be different and that’s depending on the application. Strategy for testing web application would be different from android mobile app testing.
7th Principle: Absence of errors – a fallacy
This principle points towards the usefulness of the system. In other words, finding the defects and fixing it will not help the user unless and until the software is not developed according to the requirement.