Learn How Basic Testing Principles Can Improve QA

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 the 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 probably encouraged you to know more about them. Let’s dive deeper.

Jump to Section

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 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 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 as 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 the early life-cycle are much easier and cheaper to fix. It is easier to fix to change an incorrect requirement than changing functionality in a large system that 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 thoroughly test software. Test with all combinations of inputs and outputs is impossible. Test with all possible scenarios isn’t too.

You must be thinking about how to test the complete software then. See, instead of performing complete or exhaustive testing, we go for risk-based testing. This means identifying the impact will help us to identify the module which is high risk.

Example of Risk-Based Testing

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 an “n” number of values, there could be billions of values. It’s impossible to test all possible values due to release time constraints.

To test all possible values and test conditions, the software execution time and cost will be enormous. Therefore, instead of doing exhaustive testing, priorities, and risk factors should be taken into consideration while testing and estimating testing efforts.

Early Testing:

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 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 the project as soon as it is possible.

Defects Clustering:

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.

The 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 (the 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 the testing activity, then there might be a high chance of getting many more defects there itself.

The Pesticide Paradox:

Continuous use of a similar type of pesticide mix to eliminate insects/pests during farming leads to them developing resistance power 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 testers, we can not simply depend on existing testing techniques. We must look for new and better ways 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 “Problem-B”.

Generally, it depends on the level of impact and risk associated with the product. It may also depend on factors like deadlines, time pressure, resource availability, and market needs. A risk is a probability of something that has not yet happened happening. Or, in other words, it’s a potential problem. How much impact does a risk cause, if it happens, should also be considered and discussed.

If these risks occur, their solution may be costly and damaging. Therefore, risk analysis should be done prior to testing, and thus, accordingly, test techniques and approaches 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 unusable.

Concluding Words…

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, and clutch handling. But with time and experience, we just focus on driving and the rest comes naturally.

The same thing is also true for testing principles. Testers with experience have incorporated all these principles to a level that they apply them even without thinking.

About
Latest Posts

Follow me!

Maneet Kaur

QA Engineer at Loginworks Softwares

I am a Quality Assurance Engineer who loves to work hard and make sure that the quality specifications and technical design documents are highly detailed, comprehensive, and well structured. Estimating, prioritizing, planning, and coordinating quality testing activities are the few responsibilities that fall under my purview as a QA Engineer. Now when I am not busy scrutinizing the digital documents, I spend my time flipping through the more traditional pieces of texts. Yes, I love to read and by that, I mean read a lot, whether it be novels, magazines, blogs, or just a random newspaper article. I make sure that in my leisure time too I am doing something meaningful and enhancing my knowledge of worldly stuff. And yes my favorite author is Khaled Hosseini, and I would recommend his beautifully written books to be read by each and every one.