Seven Testing Principles

Profile picture for user devraj

Here are the classic seven testing principles widely practiced in the software industry and presented by ISTQB. Every Software Tester must understand these principles, which will help them achieve a high-quality standard and reduce the possibility of undiscovered defects.

1. Testing Shows the presence of defects, not their absence

Bugs are always in software. No Application is bug-free. Testing reduces the probability of undiscovered defects. If Testers or automation scripts cannot find any defect, it does not mean the software is bug-free. Even multiple testing techniques can never guarantee that software is 100% bug-free. Testing can decrease the number of defects but not remove all defects.

2. Exhaustive testing is impossible

Test for all combinations of inputs and preconditions is impossible except for trivial cases. Unless the application under test has a straightforward logical structure and limited input, it is impossible to test all possible data combinations and scenarios.  Attempting exhaustive testing on complex applications is not an efficient use of time and budget. For example, If you have an email field that accepts alphabets, special characters, and numbers, it would have numerous combinations for testing, and testing all combinations is exhaustive testing. So, instead of exhaustive testing, we can use risk analysis, test techniques, and priorities to focus testing efforts.

3. Early Testing saves time and money

Testing activities should be started as early as possible in SDLC. The testing team should be involved in the project from the beginning. An important point about early testing is that when defects are found earlier in the life cycle, they are much easier and cheaper to fix. For example, In Agile, we test the requirements before coding begins. Early testing is sometimes referred to as a shift left

4. Defect Cluster together

A small number of modules contain most of the defects discovered during pre-release testing or show the most operational failure. We can relate Defect Clustering with Pareto Principle. According to this Pareto Principle, approximately 80% of the problems are found in 20% of the modules. Thus, we prioritize testing on 20% of modules where we experience 80% of bugs. Defects are not evenly distributed; they cluster together. If so many defects are detected in one place, there is a possibility that more defects would be there.

5. Beware of the Pesticide Paradox 

Tests are no longer helpful at finding defects, just as pesticides are no longer effective at killing insects after a while. Test cases need to be regularly reviewed and revised. If the same tests are repeated on the same release, it will not find any defect and lose effectiveness. You need to update and regularly add test cases to detect new defects.

6. Testing is context-dependent

Testing is not the same for a different type of software. Banking and E-Commerce applications are tested differently than safety-critical software. You might use a different technique, methodologies approach, and testing types based on the application type.

7. Absence of errors is a fallacy

It is impossible to run all possible tests and find all possible defects. Further, it is a fallacy to hope that just discovering and fixing a large number of defects will guarantee the success of a system. Finding and fixing defects does not benefit if the system build is unusable and does not meet the user's requirements. Even bug-free software may be worthless if incorrect requirements are incorporated or the software fails to meet the business needs.