7 Principles of Software Testing

There are 7 principles of software testing that have been established over the last 50 years and more. These are guidelines that are applicable for testing any software.

Why do we need principles in software testing?

Testing is a challenging phase of the software development life cycle that requires the testing team to think out of the box to discover hidden defects. These principles guide the testers in effectively utilizing their time and effort.

The 7 Principles of Software Testing are explained below.

1. Testing shows the presence of defects

Testing does not indicate the absence of bugs but finds the bugs present in the software. Defects are identified by testers through testing.

In this way, the possibility of defects existing in the software is reduced. This does not mean that the software is 100% defect free even after testing is complete.

7 Principles of Software Testing

Just because no defects are found after testing, it does not mean that the software is defect free.

Example: Let us assume that there are 23 defects in a hotel booking application. The testers tested the application and found 20 defects which were fixed by the developers.

Tester then tested the fixes and also performed regression testing.

They were able to find 2 of the 3 previously undiscovered defects. However one defect remained undetected.

In this example, testing showed the presence of defects (22 defects were detected) but it did not mean that the software was defect free.

2. Exhaustive testing is impossible

Performing exhaustive testing means testing the software for all the possible combinations of inputs values and preconditions.

It is not possible to do exhaustive testing of the software as it increases the cost of testing.

It also increases the execution time and requires additional resources.

Example: Let us assume that you have to test an input field like ‘Password’ in a login page that requires at least 6 characters with one character being an uppercase alphabet. This gives us 52 possible values for each character (26 lowercase and 26 uppercase). The total number of combinations will be 52 * 6 = 312.

An application generally has several dozens of such fields which are even more complicated. It is not possible to test all the possible valid input combinations manually.

Even doing it through automation would be overkill, incurring exponentially higher costs and time. Most projects have a fixed timeline and budget which would make this approach impossible.

As you see in the above example, the tester cannot test all the possibilities. So, testing is carried out based on risks and priorities in order to find the most important test cases to test.

3. Early Testing

It is best to involve the testing teams and start testing related activities early in the software development lifecycle and have specific objectives for each activity.

Example: One of the objectives of the testing team during requirements analysis phase is to find incorrect requirements. Early detection of potential defects helps in reducing the cost of bug fixing and time spent on rework. Let us understand this with an example:

Case 1: Consider a situation where you have identified an incorrect requirement in the requirement analysis phase.

Case 2: Consider another case where you found the bug in the software after it is released.

Which case, in your opinion, is more efficient?

Obviously case 1, because making correction in the requirement is easier, faster and inexpensive when compared to fixing the bug in the fully developed software or after the software is released.

Hence, early defect detection helps in reducing the organizational costs, increases the productivity of developers, and ensures delivery of stable and robust software.

4. Defect Clustering

Defect clustering implies that most of the defects are observed in a small number of modules. This is because the defects are not distributed evenly across the application but are centralized.

This approach follows the Pareto principle, according to which around 80% of the defects are found in 20% of the modules.

Our effort should be focused on 20% of the modules that contribute to 80% of the defects.More time and effort should be taken to test important / complex modules to uncover majority of the defects.

This is because complex modules can be tricky to develop and can have more defect. It also gives you an idea about the modules that require more regression testing to ensure that related functionalities are not broken.

5. Pesticide Paradox

After executing the same tests repeatedly, the number of bugs reported start reducing drastically. This is because most of the bugs in the module would have been fixed by developers.

Moreover, the developers take care to focus on those areas where bugs were reported. This is known as pesticide paradox because when a farmer repeatedly uses the same pesticide, the pests develop resistance over time.

To overcome pesticide paradox and uncover new bugs, you need to modify the existing regression test cases on a regular basis. This can be done by including new test cases to focus on new / updated areas of the software. You can also remove the test cases that haven’t produced any defects during the last few testing cycles.

Example: Consider a case where you have around 50 test cases covering a particular module of the application. During the last 7 test executions, not a single test case has failed. In thit situation, it is better to review the tests, verify the importance and try to develop newer tests by examining its interrelation with other modules to find more defects.

6. Testing is context dependent

Testing is context dependent because the method to be used for testing depends upon the content or type of the application / software.

You have to change the testing approach and methodologies based on the context.

Example: Testing of online banking applications will have significant focus on security and transaction integrity, where as testing of a social networking application may focus on usability and performance, among other parameters.

The methodology and approach for testing medical device software will differ from that used for e-commerce website.

7. Absence of errors fallacy

If you are not able to find any bugs in the software, it does not mean the software is ready to ship.

Even if you find the defects and fix them, the software could still remain unusable, if the business requirements are not met or if the software does not meet the expectations of the client.

Software can be defect free and yet, unusable.

Successful software is one that is usable and at the same time meets all the needs and requirements specified by the client.

Summary

These are the 7 important principles of software testing that every software tester needs to understand.

These principles will help testers design effective test strategies and test cases to catch the hidden defects present in the software.