7 Principles of Software Testing

Testing is an essential part of software development.

The problem is that software testing is extremely difficult and requires substantial resources. So you need to enhance the testing process to ensure you put out the best quality products.

The seven principles of software can help you do just that. These principles of software testing describe how testing engineers or software testers should develop code that is error-free, clear, and maintainable. 

According to the ISTQB (International Software Testing Qualifications Board), the seven principles of software testing are:

• Testing shows the presence of defects
• Exhaustive testing is impossible
• Early testing
• Defect clustering
• Pesticide paradox
• Testing is context dependent
• Absence-of-errors fallacy

Testing shows the presence of defects

You test software to identify problems so you can fix them before you deploy the software to production environments. However, this process doesn't mean that there aren't any bugs in the product. It just means that there may be bugs, but you didn't find them.

There could be any number of reasons that you didn't uncover every bug, including the fact that the test cases didn't cover every scenario.

This principle, which helps to set stakeholder expectations, means that you shouldn't guarantee that the software is error-free. 

Exhaustive testing is impossible

The truth is that you can't test everything, i.e., every combination of preconditions and inputs. And if you try to do so you'll waste time and money, but it won't affect the overall quality of the software.

What you need to do is assess risk and plan your tests around these risks so you can be sure you're testing the key functions. Careful planning and assessment ensures your test coverage is good so you can have confidence in your final product — and you don't even have to test every individual line of code.

Early testing

When it comes to the software development lifecycle, testing early is the key to identifying any defects in the requirements or design phase as soon as possible. It's much easier and less expensive to fix bugs in the early stages of testing than at the end of the software lifecycle as then you might have to rewrite entire areas of functionality. And that likely means missed deadlines and cost overruns.

Defect clustering

Defect clustering is the idea that a small number of software modules or components contain the most defects — sort of applying the Pareto Principle to software testing, i.e., approximately 80% of the issues are found in 20% of the components.

Understanding this can help in your testing because if you find one defect in a particular area, you'll likely find more in that same module. If you identify the complex areas that are changing the most or the ones that have more dependencies, you can focus your testing on these key areas of risk.

Pesticide paradox

This principle centers around the theory that if you repeatedly use a particular pesticide on your crops, the insects you're trying to kill or repel will eventually become immune to the pesticide and it will no longer be effective.

Likewise, if you continuously run the same tests, eventually they'll fail to find new defects, even though they'll probably confirm the software is working.

Consequently, you must continue to review your tests as well as add to your scenarios or modify them to help prevent this pesticide paradox. For example, maybe you could use a variety of testing techniques, methods, and approaches simultaneously.

Testing is context dependent

Software testing is all about the context, which means that no one strategy will fit every scenario. The types of testing and the methods you use totally depend on the context of the systems or the software, e.g., the testing of an iOS application is different from the testing of an e-commerce website. Put simply, what you're testing will always affect the approach you use.

Absence-of-errors fallacy

If your software is 99% error-free but it doesn't follow your user's requirements, it's still not usable. That's why it's critical to run tests that pertain to the requirements of the system. Software testing isn't just about finding bugs, it's about ensuring that the software meets the user's needs and requirements. 

As such, you should also test your software with the users. You can test against early prototypes at the usability testing phase so you can get feedback from the users that you can use to ensure the software is usable. Even though your software might have relatively few issues, doesn't mean it is ready to ship; it also has to meet your customer's requirements and expectations.

Conclusion

If you apply these seven principles to your testing, you can become more focused and efficient as well as enhance the quality of your overall testing strategy. 

In addition, you might find that when you apply one principle, the other principles may fall into place organically. For instance, testing early in the software development lifecycle can help mitigate the absence-of-errors fallacy because if you test at the requirements level, you can help ensure that the software will meet your user's requirements.