7 Software Testing Principles

Testing best practice

Testing is an essential component of software development. It can also be a difficult activity to structure correctly and in a way that maximizes efficiency. Because of this complexity, it is always beneficial to review processes and guidelines to ensure you are following best practices. A great place to start is with the ISTQB (International Software Testing Qualifications Board), which lists seven fundamental testing principles.

What are the seven fundamental testing principles?

These are the principles that the ISTQB has compiled and established over the years as testing and software development have evolved, and they are recognized as the absolute core of testing.

If you are involved in any aspect of software testing, it is worthwhile to thoroughly review and comprehend these standards, ensuring that they are followed within your organization and teams, as they will help you achieve high-quality standards and give your clients confidence that their software is ready for production.

7 Principles of Software Testing

1) Exhaustive testing is not possible

Yes! It is not possible to conduct exhaustive testing. Instead, based on the application’s risk assessment, we require the least amount of testing possible.

And the million-dollar question is, how do you calculate risk?

Let’s do an exercise to answer this.

Which operation, in your opinion, is most likely to cause your operating system to fail?

Most of you guessed it: opening ten different applications simultaneously.

So, if you were testing this Operating System, you would notice that defects are more likely to be found in multi-tasking activities and must be thoroughly tested, which brings us to our following principle. 

2) Defect Clustering

Defect Clustering states that most of the defects detected are contained in a few modules. The Pareto Principle is applied to software testing: roughly 80% of the problems are found in 20% of the modules.

Such risky modules can be identified through experience. However, this approach has its own set of issues.

If the same tests are run repeatedly, the same test cases will eventually stop finding new bugs.

3) Pesticide Paradox

Repetitive use of the same pesticide mix to eradicate insects during farming will result in the insects developing pesticide resistance over time. Pesticides are thus rendered ineffective against insects. The same is true for software testing. If the same set of repetitive tests is performed, the method will be ineffective for detecting new defects.

To overcome this, test cases must be reviewed and revised regularly, with new and different test cases added to help find more defects.

Testers cannot rely solely on existing testing techniques. He must constantly strive to improve existing methods to make testing more effective. Even with your sweat and hard work in testing, you can never claim that your product is bug-free. Watch this video of Windows 98’s public launch to emphasize this point.

Do you think a company like MICROSOFT would not have thoroughly tested its operating system and would risk its reputation just to have its operating system crash during its public launch?

4) Testing shows a presence of defects

As a result, the testing principle states that testing discusses the presence of defects rather than the absence of defects. i.e., Software testing reduces the likelihood of undiscovered defects remaining in the software, but finding no flaws is not proof of correctness.

But what if you work extra hard, take all precautions, and make your software product bug-free 99% of the time? And the software does not meet the client’s needs and requirements.

This brings us to our following principle, which states that- Error Absence

5) Absence of Errors Fallacy

Software that is bug-free 99% of the time may still be unusable. This is possible if the system is thoroughly tested for the incorrect requirement. Software testing is more than just looking for bugs; it is also about ensuring that the software meets the needs of the business. A fallacy is the absence of error. Finding and fixing defects, for example, is useless if the system build is unusable and does not meet the user’s needs and requirements.

To address this issue, the following testing principle states that Early Testing

6) Early Testing

Testing should begin as soon as possible in the Software Development Life Cycle so that any flaws in the requirements or design phases are discovered early on. It is much less expensive to fix a fault in the early stages of testing. But when should one begin testing? You should start looking for bugs as soon as the requirements are defined. More on this principle will be covered in a later training tutorial.

7) Testing is context dependent

Testing is context-dependent, which means testing an e-commerce site will differ from trying a commercial off-the-shelf application. All developed software is not the same. Depending on the application type, you may use a different approach, methodologies, techniques, and types of testing. For example, testing a POS system in a retail store differs from testing an ATM.

Myth: “Principles are just for reference. I will not use them in practice .”

This is entirely false. Software Testing principles will assist you in developing an effective Test Strategy and writing error-catching test cases.

However, learning testing principles is similar to learning to drive for the first time.

When you first start learning to drive, you pay attention to everything, such as gear shifts, speed, clutch handling, etc. However, with experience, you only need to focus on driving; the rest will come naturally so that you can converse with other passengers in the car.

The same is valid for principles of testing. Experienced testers have internalized these principles to the point where they apply them automatically. As a result, the myth that the principles are not used in practice is simply false.