7 FUNDAMENTAL PRINCIPLES OF SOFTWARE TESTING AS PER ISTQB

7 FUNDAMENTAL PRINCIPLES OF SOFTWARE TESTING AS PER ISTQB

In 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 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 towards the performance of the system. A principle of software testing refers to the brief mentioned and proven concepts which guide testing professionals during 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 a 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 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 are 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 software development life cycle. As we are starting testing activity in early stage, this helps us to identify defects and fixed early with a low budget and within 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 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 new scenario or test cases even after the execution of particular test set.

6th Principle: Testing is dependent on context

According to this principle; if you are testing web application and mobile application using 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 – fallacy

This principle points towards the usefulness of the system. In other words finding the defects and fixing it will not help user unless and until the software is not developed according to the requirement.