It is a widely held belief that success comes by following a set of principles. We see people set specific targets and define different rules to achieve them. A typical example these days is seen in people who want to be healthy and fit. They believe that to achieve that goal, they need to follow a defined set of rules. Some follow strict diets, and some follow a fitness regime or a combination of both to achieve their goals.
Similarly, for software testers, there are a set of 7 principles of testing. Finding a tester unaware of these software testing principles is rare, but at the same time, finding someone who truly understands their importance and how applying the 7 principles of testing will benefit their projects, is also limited. Software testing principles have existed for many years, but a lot of us have no idea if they offer any advantage. Some consider the list to be just abstract information, needed only to pass certification exams, or clear any interview, but the truth is every testing project employs these principles.
The 7 software testing principles
Let’s now take a look at the seven principles of software testing and see how the software testing life cycle utilizes them to benefit the overall test planning and test execution.
1. Testing shows the presence of defects
The software tester’s objective is to test an application to identify as many bugs as possible. Everyone on the software testing team aims to find and report bugs, indicating that the whole testing team follows this principle. The focus is on showing the presence of defects in the application under test. The total number of reported bugs is a clear indication of defects being present in the system.
2. Exhaustive testing is not possible
QA Leads and Managers approach the challenge of deciding how much testing is sufficient since the whole piece of code is non-testable. Being aware of the principle “exhaustive testing is not possible” assists them in making this decision because it is instructive to remember that testing every flow and combination is not possible. Hence, while planning the tests, the team needs to carefully analyze and identify the combinations and paths which offer the maximum coverage.
3. Early testing
The idea of introducing QA early in the cycle started decades ago, and today in almost all projects, QA is involved much earlier than the usual test design phase, sometimes even at the beginning. This principle acknowledges how the whole team benefits when testing is introduced early in the project. If testing occurs during the design phase, such as before development starts, it can bring in a considerable cost benefit to the project.
4. Defect clustering
Finding numerous defects within the same component or module is common. The principle of defect clustering conforms with the Pareto principle, also known as the “80 -20 rule,” which identifies that 80% of defects are found in just 20% of the module.
Understanding the defect cluster will reduce effort required during regression and retest. One cause of a defect cluster could be a misinterpretation of the requirement by the developers, which may lead to an incorrect implementation that exposes a lot of flaws in the same module. Another example could be that a contact form is missing specific field-level validation. Understanding this principle has benefits, but at the same time, the tester should not limit their focus to just defect clusters while ignoring other parts of the application. Testing must be thorough in all other areas of the application.
5. Pesticide Paradox
The name of this principle describes a situation where, if the same set of tests run every time, they can become ineffective, reducing the ability to identify any new bugs. During the testing and bug life cycle, bugs will be regularly found and fixed, as the application goes through several changes. Accordingly, test plans and scenarios will need revision. Continuing to run the same tests with no accommodation for updates may sometimes deliver incorrect results, consequently becoming a time-consuming task with diminishing returns.
6. Testing is context-dependent
Not all software testing projects are the same, so testers need to understand the type and nature of the project to be worked on before they plan the tests. For example, testing a banking site and testing a e-commerce site will drive the creation of different test cases and test data.
7. Absence of errors fallacy
Even if the application tested is shown to be 100% error-free with zero defects, it might still be in an unusable state. Software with zero defects is not ready for market until it equals all the predefined business requirements. The focus of testing must be to ensure that each business requirement has been well understood and considered during test execution.
At some point in their career, every tester learns these seven principles of testing, but to get the most benefit and maximum outcome, a shift needs to take place. Rather than retaining this knowledge just for the sake of clearing a certification, testers should regard it as practical information that can be applied in their day to day deliverables to reap the maximum benefit.