Software Testing Principles

To measure and improve the quality of software, tests are conducted on the software as well as on the processes that are used to build it. Software testing is a set of procedures and tasks performed on the software and applications throughout the software development life cycle. Testing should be done appropriately to deliver high performance, bug-free, reliable software and applications with high customer satisfaction. To accomplish the target of delivering such products, there is a need for software testing principles to determine whether the testing strategies are correct or not.

Every tester should understand and study the testing principles to achieve customer satisfaction as well as a high-quality standard in the tested products. These principles will help a software tester to create a powerful testing strategy, test scenarios, and test cases with less effort and time. There are seven essential testing principles of software testing that are broadly used in the software industry:

1. Testing shows the presence of defects.
2. Exhaustive testing is not possible.
3. Early testing
4. Defect clustering
5. Pesticide Paradox
6. Testing is context-dependent
7. Absence of error fallacy

Testing shows the presence of defects

The aim of software testing is to make the software efficient and work as expected without any defects and failures.

This principle states that testing software or an application helps a tester to detect all the possible number of hidden defects present in it. It is correct that testing decreases the number of bugs present in any software. However, it doesn't prove that software is completely bug-free. Even after performing multiple types of testing can never result in completely defect-free software. Hence, testing shows the presence of defects, but it can't make a software 100% defect-free.

Exhaustive testing is not possible

 A testing technique that tests all the functionalities of software with all the possible combinations of input data (valid and invalid) and preconditions is referred to as Exhaustive testing.

This principle states that it is impossible to test everything in the software. A tester can try to cover all the possible combinations, but it will increase the software execution time, cost, and timelines and will not permit a tester to do such testing activities. Let us understand exhaustive testing with the help of an example; suppose we have one text field which accepts characters from only a-z; in this case, we will try all inputs that are a, b, c, d…, and z. This is the basic example, but if the text field accepts alpha-number characters. In that case, testing all the possible combinations of alpha-number characters is impossible. Hence, exhaustive testing is an impossible task.

Early testing

This principle states that testing should be involved in the early stage of the software development life cycle. Involving testing during the requirement analysis phase will help testers to find bugs in the requirement and specification documents so that defects can be fixed immediately if requirements are specified incorrectly. This process will save a lot of time and cost of fixing defects. Defect fixing is much easier and cheaper at the initial stage as compared to the last stage of SDLC. Hence, early testing helps both the tester and the process to reduce the score of errors and bugs.

Defect clustering

This principle states that clusters of defects can be found in a single module. In other words, some small modules or components of software contain the maximum number of defects which leads to operational failures. There could be several possible reasons behind this, such as defects being clustered and unevenly spread in the software, the complexity of the module or component, or the coding part might be complicated.

Defect clustering is based on the Pareto Principle of software testing. According to Pareto Principle, 80% of defects/issues come from 20% of the modules. Therefore, testers should be more focused on those 20% complex and risky modules, which leads to 80% of defects and failures.

Pesticide Paradox

This principle states that repetitive use of the same test cases will not find new defects in the application. In simple words, executing the same number of test cases on a particular module over a period makes the module immune to the test cases. Let's understand this with the help of an example, using a particular pesticide on crops over a period will make insects render it effective. Similarly, in testing, if a tester runs the same tests on software, then the software must be working as expected, but they won’t find new bugs in the system.

To overcome this, a tester should keep track of the test cases by reviewing and modifying them regularly. And if required, add some new test cases, or change the current testing technique to find defects in the system. Hence, beware of the pesticide paradox.

Testing is context-dependent 

This principle states that testing depends on the context of the application or software. Testing in an application completely depends on its context of it, as based on the application domain, testing strategies, methods, test scenarios, and test cases will be planned and implemented.

Let us understand this with the help of an example, there are multiple fields, such as health, e-commerce, banking, etc., in the market, and each field has various software and application. Testing a banking application will be different than testing a gaming application. Testing approaches, techniques, and procedures will be different for both applications. Hence, testing ultimately depends on the context of the application.

Absence of error fallacy

This principle states that a system or software is fully tested and has zero defects, referred to as a 99% defect-free system, but still, it can be unusable for not meeting the customer’s need. There could be multiple reasons behind this like requirements are incorrectly specified, and testing has been done on the same requirements. Testing such applications is just a waste of time and effort. Therefore, the first thing all the testers should do is to check the potential of an application of software, whether it is fulfilling the customer's requirement or not. Hence, beware of the absence of error fallacy.