Understanding software testing principles is crucial for QA engineers because testing plays a vital role in the software development process, and structuring it correctly for maximum efficiency can be a challenging task. Given the complexity involved, it is advisable to adhere to guidelines and follow best practices. A great starting point is the International Software Testing Qualifications Board (ISTQB). According to ISTQB, there are seven fundamental testing principles that provide valuable guidance for QA engineers in ensuring effective and high-quality testing processes.
1) Testing shows the presence of defects
2) Absence-of-errors fallacy
3) Early testing
4) Exhaustive testing is impossible
5) Defect clustering
6) Pesticide paradox
7) Testing is context dependent
Let's dive in the details of each principle.
Testing shows the presence of defects
This principle, designed to manage stakeholder expectations, emphasizes that guaranteeing error-free software is not a realistic goal. Indeed, the purpose of testing is to reveal the presence of defects rather than to assert the absence of defects. In other words, software testing serves to diminish the likelihood of undiscovered defects, but the absence of identified flaws does not prove the correctness of the software.
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 - Absence-of-errors fallacy
Absence-of-errors fallacy
Even if software is 99% free of bugs, it can remain unusable if it is extensively tested against the wrong set of requirements. Software testing goes beyond the mere detection of bugs; it is also about ensuring that the software meets the needs of the business. It's a fallacy to assume that the absence of errors equates to a flawless system. 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
Early testing
Early testing is the key to identifying any defects in the requirements or design phase. 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'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.
Exhaustive testing is impossible
In reality, testing every possible combination of preconditions and inputs is impractical. Attempting to do so not only consumes time and resources but does not necessarily enhance the overall software quality.
The key is to evaluate risks systematically and tailor your testing efforts accordingly, focusing on critical functions. Through thoughtful planning and risk assessment, you can achieve comprehensive test coverage, instilling confidence in the final product without the need to test every single line of code.
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.
GO TO FULL VERSION