7 Basic Principles of Software Testing You Must Know [Video]
Take a quick look at this short video explaining the top software testing principles you need to know as well as the best way to apply them
Join the DZone community and get the full member experience.Join For Free
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¹⁵=30,517,578,125.
If you were to test all the possible combinations, project execution time and 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?
Opening Microsoft Word
Opening Internet Explorer
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 the 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, and 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 possible precautions and making sure a software product is 99% bug-free, but 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:
- Testing shows the presence of defects;
- Exhaustive testing is impossible;
- Early testing;
- Defect clustering;
- The Pesticide Paradox;
- Testing is context-dependent;
- The absence of errors is a fallacy.
Note: This video is contributed by Guru99
This article was originally posted at Test Automation Resources.
Published at DZone with permission of Jefferey Dunn. See the original article here.
Opinions expressed by DZone contributors are their own.