Software Testing Principles -ISTQB

Testing is a crucial element of software development. It can also be a complex activity to structure correctly, and in a way that supports maximum efficiency. Because of this complexity, it is always helpful to review processes and guidelines to ensure test team is following best practice, and a great place to start is with the ISTQB, who list seven fundamental principles of testing. Together they serve as guidelines for testing process.

Principle 1 - Testing shows the presence of defects:

Every application or product is released into production after a sufficient amount of testing by different teams or passes through different phases like System Integration Testing, User Acceptance Testing, and Beta Testing etc.

So have you ever seen or heard from any of the testing team that they have tested the software fully and there is no defect in the software? Instead of that, every testing team confirms that the software meets all business requirements and it is functioning as per the needs of the end user.

In the software testing industry, no one will say that there is no defect in the software, which is quite true as testing cannot prove that the software is error-free or defect-free.

However, the objective of testing is to find more and more hidden defects using different techniques and methods. Testing can reveal undiscovered defects and if no defects are found then it does not mean that the software is defect free.

Principle 2 - Exhaustive testing is impossible:

Testing all the functionalities using all valid and invalid inputs and preconditions is known as Exhaustive testing.

Why it's impossible to achieve Exhaustive Testing?

Assume we have to test an input field which accepts age between 18 to 20 so we do test the field using 18,19,20. In case the same input field accepts the range between 18 to 100 then we have to test using inputs such as 18, 19, 20, 21, ...., 99, 100. It's a basic example, you may think that you could achieve it using automation tool. Imagine the same field accepts some billion values. It's impossible to test all possible values due to release time constraints.

If we keep on testing all possible test conditions then the software execution time and costs will rise. So instead of doing exhaustive testing, risks and priorities will be taken into consideration whilst doing testing and estimating testing efforts.

Learn More !

Our On-Premise Corporate Classroom Training is designed for your immediate training needs

---

Principle 3 - Early testing

The third principle basically talks about the effectiveness of testing early. This is a no-brainer - early testing will help find issues faster. Testing shouldn't be thought of as an afterthought or a supporting activity, and testing activities should be a part of the SDLC early on, right from the point of requirements analysis. Even early feedback from the testing team at this stage helps uncover scenarios/conditions that were either not thought through or not thought about at all. Correction at this stage itself will help save a lot of time, efforts, and cost rather than later on through actual testing where the cost and time of correction will escalate.

Principle 4 - Defect clustering

Finding numerous defects within the same component or module is common. The principle of defect clustering conforms with the Pareto principle, also known as the '80 -20 rule,' which identifies that 80% of defects are found in just 20% of the module.

Understanding the defect cluster will reduce effort required during regression and retest. One cause of a defect cluster could be a misinterpretation of the requirement by the developers, which may lead to an incorrect implementation that exposes a lot of flaws in the same module. Another example could be that a contact form is missing specific field-level validation. Understanding this principle has benefits, but at the same time, the tester should not limit their focus to just defect clusters while ignoring other parts of the application. Testing must be thorough in all other areas of the application.

Principle 5 - Pesticide paradox

Repetitive use of the same pesticide mix to eradicate insects during farming will over time lead to the insects developing resistance to the pesticide Thereby ineffective of pesticides on insects. The same applies to software testing. If the same set of repetitive tests are conducted, the method will be useless for discovering new defects.

To overcome this, the test cases need to be regularly reviewed & revised, adding new & different test cases to help find more defects.

Testers cannot simply depend on existing test techniques. He must look out continually 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.

Learn More !

Our On-Premise Corporate Classroom Training is designed for your immediate training needs

---

Principle 6 - Testing is context dependent

Testing is a context-dependent principle states that we have multiple fields such as e-commerce websites, commercial websites, and so on are available in the market. There is a definite way to test the commercial site as well as the e-commerce websites because every application has its own needs, features, and functionality. To check this type of application, we will take the help of various kinds of testing, different technique, approaches, and multiple methods. Therefore, the testing depends on the context of the application.
To add to this, there are also international standards defined to help determine that the software conforms to certain established benchmarks/criteria. For example, the ISO 27001 standard for information security systems differs from the ISO 9564 standard for e-commerce systems. Testing should importantly consider these standards.

Principle 7 - Absence of errors fallacy

It is possible that software which is 99% bug-free is still unusable. This can be the case if the system is tested thoroughly for the wrong requirement. Software testing is not mere finding defects, but also to check that software addresses the business needs. Absence of Error is a Fallacy i.e. Finding and fixing defects does not help if the system build is unusable and does not fulfill the user's needs & requirements.
Therefore, it is very much important to note that the Client's requirements and expectations are as important as the quality of product.

In summary

History is replete with examples of the dangers of deploying untested software.. Applying these thoughtful principles to your testing can help you become more efficient and focused, and can even help improve the quality of your overall testing strategy. Additionally, sometimes by applying one principle you will find others naturally fall into place. For example, testing early can help mitigate the 'absence of errors' fallacy - if testers are involved at a requirements level, you can help ensure the software will match client requirements/expectations.
Combine all these points, and you can really achieve maximum efficiency by utilizing your time and endeavors effectively and economically.

These principles can be applied for testing the project and coding. The main objective of this life cycle process is to find correctness, completeness, quality and detecting errors in the software.

Support our effort by subscribing to our youtube channel. Update yourself with our latest videos on Data Science.

Looking forward to see you soon, till then Keep Learning !

Learn More !

Our On-Premise Corporate Classroom Training is designed for your immediate training needs

---