7 Software Testing Principles
1) Testing is exhaustive impossible
2) Defect Clustering
3) Pesticide Paradox
4) Testing indicates presence of defects
5) Absence of Error – fallacy
6) Early Testing
7) Testing context dependent
Background
It is essential that you reach the optimal test results while doing software testing without straying from the objective. But how do you know you are on the correct testing approach? For that, you must adhere to some fundamental testing principles. Below are the common seven testing principles that are mostly applied in the software world.
To comprehend this, think of a situation where you are copying a file from folder A to Folder B.
Think of all the scenarios where you can test this.
Other than the common scenarios, you can test the following conditions
Trying to copy the file when it is Open
You do not possess the security rights to paste the file in Folder B
Folder B is located on a shared drive and storage space is at capacity.
Folder B already contains a file of the same name, in fact, the list goes on and on
Or if you have 15 input fields to test, each of which can take on 5 different values, the number of combinations to be tested would be 5^15
If you were to test the whole possible combinations project EXECUTION TIME & COSTS would increase exponentially. We require some principles and strategies to maximize the testing effort
Here are the 7 Principles:
1) Exhaustive testing is not possible
Yes! Exhaustive testing is not possible. Rather, we require the optimal level of testing based on the risk assessment of the application.
And the million dollar question is, how do you determine this risk?
To respond to this let's conduct an exercise
In your opinion, Which operation is most likely to make your Operating system fail?
I am sure most of you would have thought, Opening 10 different application all at the same time.
So if you were testing this Operating system, you would realize that defects are likely to be found in multi-tasking activity and need to be tested thoroughly which brings us to our next principle Defect Clustering
2) Defect Clustering
Defect Clustering to the effect that a few modules have the majority of the defects found. It is the software testing application of the Pareto Principle: roughly 80% of the faults occur in 20% of the modules.
By experience, you can pick out such risk modules. But this method has its own pitfalls
If the same tests are constantly repeated, sooner or later, the same test cases will no longer discover new bugs.
3) Pesticide Paradox
Repeated application of the same pesticide combination to kill insects in agriculture will eventually result in the insects becoming resistant to the pesticide Thus rendering pesticides ineffective on insects. The same is true for software testing. If the same repetitive set of tests are run, the approach will be useless for finding new defects.
In order to overcome this, the test cases must be periodically reviewed & updated, incorporating new & distinct test cases to identify defects in greater numbers.
Testers cannot just rely on current test methods. He has to keep an eye out at all times to enhance the current methods to make the testing more effective. But even with all this sweat & hard work while testing, you can never say your product is free from bugs. To illustrate this fact, let's view this video of the public launch of Windows 98
You believe MICROSOFT as a company wouldn't have adequately tested their OS & would compromise their reputation simply to witness their OS crashing during its public unveiling!
4) Testing indicates existence of defects
Therefore, testing principle states that – Testing discusses the existence of defects and does not discuss the non-existence of defects. i.e. Software Testing decreases the likelihood of unknown defects still present in the software but even when no defects are detected, it is not a proof of correctness.
But what if, you work extra hard, taking all precautions & make your software product 99% bug-free. And the software does not meet the needs & requirements of the clients.
This introduces us to our next principle, which is that- Absence of Error
5) Absence of Error – fallacy
It may be possible that software that is 99% bug-free is still unusable. This may happen if the system is tested rigorously for the wrong requirement. Software testing is not just finding defects, but also to verify that software meets the business needs. The lack of Error is a Fallacy i.e. Finding and correcting defects does not matter if the system build is unusable and does not meet the user's needs & requirements.
To address this issue, the second principle of testing says that Early Testing
6) Early Testing
Early Testing – Testing needs to begin as soon as possible in the Software Development Life Cycle. So that all defects during the requirements or design phase get caught in early stages. It is far less expensive to repair a Defect during the initial stages of testing. But when early one must begin testing? It is suggested that you begin locating the bug the moment requirements are being specified.
7) Testing is context specific
Testing is context-specific which in effect means that testing an e-commerce website will be different from testing a commercial off the shelf application. All the software's developed are not the same. You may follow a different approach, methodologies, techniques, and testing types based on the application type. For example testing, any POS system in a retail shop will be different from testing an ATM machine.
Myth: "Principles are only for reference. I will never use them in practice ."
This is so not true. Test Principles will assist you in developing a good Test Strategy and write error catching test cases.
Learning testing principles is as learning how to drive for the first time.
Initially, while you learn to drive, you pay attention to each and everything like gear shifts, speed, clutch handling, etc. But with experience, you just focus on driving the rest comes naturally. Such that you even hold conversations with other passengers in the car.
The same applies to testing principles as well. The principles have been internalized by experienced testers to an extent that they practice them instinctively. Therefore, the myth that the principles are never practiced is nothing but a lie.
Comments
Post a Comment