7 Basic Principles of Software Testing You Must Know

Consider a scenario where you are moving a file from folder A to folder B. Think about all the possible ways you can test this. Apart from the usual scenarios, you can test the following conditions:

• Trying to move the file when it is opened
• You do not have the security rights to paste the file in folder B
• Folder B is on a shared Drive and storage capacity is full
• Folder B already has a file with the same name

In fact, the list is endless. Supposed you have 15 input fields to test each having 5 possible values, the number of combinations to be tested would be: 5^{15=30517578125}

If you were to test all the possible combinations, project Execution time & Costs will rise exponentially. Hence, one of the testing principles states that Exhaustive testing is not possible. Instead, we need an optimal amount of testing based on the Risk assessment of the application. And the million dollar question is how do you determine this risk. To answer this let’s do an exercise. In your opinion, which operation is most likely to cause your operating system to fail?
A. opening Microsoft Word
B. opening Internet Explorer
C. opening 10 heavy graphics applications all at the same time
Most of you would have guessed opening 10 heavy graphics applications all at the same time. If you were testing this operating system you would realize that defects are likely to be found in a multi-tasking module and that needs to be tested thoroughly.

Defect clustering states that a small number of modules contain most of the defects detected. With experience, you can identify such risky modules, but this approach has its own problems. If the same tests are repeated over and over again, eventually the same test case will no longer find new bugs. This is another principle of testing called Pesticide paradox. To overcome this, the test cases needed to be regularly reviewed and revised, adding new and different test cases to help find more defects.

But even after all this sweat and hard work and testing, you can not claim that your software is bug-free. Testing shows the presence of defects, for instances, reduces the probability of undiscovered defects remaining in the software but even if no defects are found, it is not a proof of correctness.

What if you work extra hard taking all precautions and making sure software product is 99% bug-free and the software does not meet the needs and requirements of the client. The absence of errors is a fallacy. Finding and fixing defects does not help if the system build is unusable and does not fulfill the users’ needs and requirements. To fix this problem, Early testing should start as early as possible in the Software Development Life Cycle, so that any defects in the requirements or design phase are captured as well.

The last principle of testing states that testing is context-dependent which basically means that the way you test an e-commerce site will be different from the way you test a commercial off-the-shelf application.

Here’s a quick recap of the 7 testing principles:

1. Testing shows the presence of defects
2. Exhaustive testing is impossible
3. Early testing
4. Defect clustering
5. Pesticide Paradox
6. Testing is context-dependent
7. The absence of errors is a fallacy

Note: This video is contributed by Guru99

Original source: testautomationresources.com