Testing Principals

As software development techniques have advanced during the last decades, some basic principles of testing have also been established. These principles can be seen as a basic guideline for both, Software Testing and coding.

1. Testing is context dependent

The same tests should not be applied across the board because different software products have varying requirements, functions, and purposes. Different methodologies, techniques, and types of testing are related to the type and nature of the application. For example, a software application in medical device software needs more testing than games software. Also, medical device software requires to be compliant with medical industry regulators and possibly specific test design techniques.

2. Exhaustive Testing is not possible

It is not possible to test all possible combinations of data and Test Scenarios as it will take to much time. For this reason, risk and priorities are used to concentrate on the most important aspects to test.
Accessing and managing risk is one of the most important activities and the reason for testing in any project.

3. Early Testing is always preferred

In the Software Development Life Cycle testing activities should start early and focus on defined objectives. As soon as the initial products, such as requirement or design documents are available, we can start testing. By starting testing early, the test can be prepared for each level of the development life-cycle. Another important point about early testing is that when defects are found earlier in the life-cycle, they are much easier and cheaper to fix. It is much cheaper to change an incorrect requirement than having to change functionality in a large system that is not working as requested or as designed!

4. Defects Clustering

During testing, it can be observed that most of the reported defects are related to a small number of modules within a system. By identifying and focusing on these clusters, testers can efficiently test the sensitive areas while concurrently testing the remaining “non- sensitive” areas.

5. Pesticide Paradox

If we keep running the same set of tests over and over again, chances are no more new defects will be discovered by those test cases. “Pesticide Paradox” means that it is very important to review the test cases regularly. New and different tests need to be written to cover different parts of the software or system to find more defects.

6. Testing Shows Presence of Defects

Testing an application can only reveal that one or more defects exist in the application. Even after testing the application or product thoroughly we cannot say that the product is 100% defect free.
Testing always reduces the number of undiscovered defects remaining in the software. Therefore, it is important to design Test Cases which find as many defects as possible.

7. Absence of Errors is fallacy

If the system built is unusable and does not fulfill the user’s needs and expectations then finding and fixing defects will not help. Also if testing didn’t find any defects in the software, it doesn’t mean that the software is ready to be used. It must be confirmed whether the executed tests were really designed to catch most of the defects.

Was this article helpful?

Related Articles