It is important to achieve maximum test results while doing software testing without deviating from the actual goal. This is a stated fact, but how can we actually determine that we are following right strategy for testing???
For that, we need to stick to some basic testing principles as these principles were established to balance both, software testing and development. These testing principles are seen as a basic guideline for Software Testing.
This must have encouraged you to know more about them. Isn’t it? So, why wait, let’s get started…
Seven Testing Principles Of QA
There is always a strong predefined foundation on which the stones of success is laid. Below are the basic 7 testing principles of QA:
Testing shows the presence of defects:
Testing shows the presence of defects but cannot prove that the software/application is defect free. In many cases, it is identified that defects are present in software even after the rigorous testing activity. This principle talks about the reduction of a number of defects in software. There is always the possibility that the software has undiscovered defects, testing should not be considered as a proof of defect-free software.
For better utilization of time, testing should be started as soon as possible. Testing can be started after the initial products, such the requirement or design documents are available. By starting testing early, we can prepare to test for each level of the development life-cycle.
One important point about early testing is that defects found in early life-cycle are much easier and cheaper to fix. It is easier to fix to change and incorrect requirement than changing a functionality in a large system which is not working as requested or as designed.
Exhaustive Testing Is Not Practically Possible:
If we talk about this principle, it says it is not possible to test complete software. Test with all combinations of inputs and outputs. Test with all possible scenarios is not possible. Then you must be thinking how we will test the complete software. See, instead of performing complete or exhaustive testing we go for risk-based testing. Identifying the impact can help us to identify the module which is high risk.
Let us assume that we have to test an input field which accepts age between 20 to 22 so we do test the field using 20, 21, 22. In case the same input field accepts the range between 20 to 100 then we have to test using inputs such as 20, 21, 22, 23, …., 99, 100. This a basic example, we may think that we can achieve it using some automation tool. Assume that the same field accepts n number of values may be billions of values but it’s impossible to test all possible values due to release time constraints.
For testing all possible values and test conditions, the software execution time and cost will rise eventually. Therefore, instead of doing exhaustive testing, priorities and risk factors should be taken into consideration while testing and estimating testing efforts.
Testing should start as early as possible in the Software Development Life Cycle. By starting testing early, a 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 allows to handover ordered software on time with expected quality.It is much cheaper to change an incorrect requirement than having to change a functionality in a large system that is not working as requested or as designed!
Early testing – such as early test design and review activities – finds defects early on when they are cheap to find and fix.
Defect (Requirements + Design) = ½ Defect (Total)
Cost of Defects:
Defect Cost (fix & finding) : Life Cycle Stages (Specification < Design < Build < Test)
Considering the above factors, it is highly recommended to start testing in the project as soon as it is possible.
Usually, maximum defects in software lie within the limited set of software areas. Defect Clustering in software testing means that a small module or functionality contains most of the bugs or it has the most operational failures. Testing effort should always be focused on the expected and later observed defect density of modules/areas. Usually, a small number of modules contain most of the defects which in many cases can be responsible for most of the operational failure. Sometimes defects discovered during pre-release are also responsible for operational failures.
As per the Pareto principle i.e., 80:20 rule 80% of defects are due to 20% of code! This information can be very helpful while doing testing. If one defect is found in a particular module or area during testing activity then there might be high chances of getting much more defects there itself.
The Pesticide Paradox:
As we know that continuous use of a similar type of pesticide mix to eliminate insects/pests during farming leads to develop resistance power in insects for that particular pesticide. Thereby pesticide becomes ineffective for the insects. This same process is applied in software testing. If a similar set of tests are conducted then the testing method will be useless for discovering new defects. To overcome this issue, we need to regularly update, review, revise and add new & different test cases to help us find more defects.
As a Tester, we can not simply depend on existing testing techniques. We must look out new and better ways in order to improve the existing methods to make testing more effective. But even after all this sweat & hard work in testing, you can never claim your product is bug-free.
Testing is context-dependent:
Testing is done differently in different contexts. The type of testing applicable for “Problem-A” may not fit the “Problem-B”.
Generally, it depends on the level of impact and risk associated with the work product. It may also depend on the factors like deadlines, time pressure, resource availability and market needs. A risk is the probability of happening of something that has not yet happened; it’s a potential problem. How much impact does a risk can cause if it happens should also be considered and discussed.
If these risks occur, their solution may be costlier and damaging. Therefore, risk analysis should be done prior to testing and thus accordingly test technique and approach shall be chosen within the context.
The absence of errors fallacy:
If we are not able to find defects in a product using the same set of test-cases/scenarios doesn’t prove that the product is bug-free. If incorrect requirements were incorporated into the software and the software is not fulfilling the business needs then even a 99% bug-free software will be unusable and will be a waste of time, money and resources. The software which we built should also fulfill all the business needs otherwise it will become an unusable software.
These were the Software testing principles. Software testing is an extremely creative and intellectually challenging task.
Learning testing principles is just like learning to drive for the first time. Initially, when we learn to drive, we need to pay attention to each and every detail like gear shifts, speed, clutch handling, etc. But with time and experience, we just focus on driving and rest comes naturally.
Same thing is also true for testing principles. Testers with time and experience have incorporated all these principles to a level that they apply them even without thinking.