The following are the software testing principles from the ISTQB syllabus:
- Testing shows presence of defects: Testing can show that defects are present, but cannot prove that there are no defects. So, from the testing perspective it is very important to design test cases that find as many defects as possible. In other words try to cover each negative and positive scenario by understating the project requirements.
- Exhaustive testing is impossible: Testing everything, including all combinations of inputs and preconditions that is not possible. So, instead of doing exhaustive testing we can use risks and priorities to focus testing efforts. So, depending on the project time scale the Tester or Testing Team must identify test scenarios or test cases by priority and by risks. In other words, high risk test cases need to be given a higher priority.
- Early Testing: To find an early defect, testing activities shall be begun as early as possible in the Software Development Life Cycle. If defects are found early in the SDLC, it is relatively cheap to find and fix it. For example, the cost of finding and fixing a defect is cheap if it's found during the requirements gathering phase compared to if it's found and fixed during the UAT phase or the product is in production.
- Defect clustering: Defect clustering means a small number of modules contain the most of the defects discovered during pre-release. Defect clustering provides an idea of which modules have the most defects discovered so by that the testing team has a better idea of what modules need more focus during testing.
- Pesticide Paradox: The Pesticide Paradox means if the same test cases are repeated over and over again, then after some time the same test cases are able to determine more defects. So, there is a need to regularly review and update test cases.
- Testing is context dependent: Testing is context-dependent, in other words testing is done differently in varying contexts. For example, a safety-critical module is tested differently from an e-commerce site.
- Absence-of-errors fallacy: The Absence-of-errors fallacy means that finding and fixing defects does not help if the system is unusable or does not fulfill the customer requirements. In other words customers are not interested in determining how many defects are found and fixed by the software vendor but they interested in how the software works against the requirements and whether the end user is able to complete their day-to-day activities using this software without encountering any difficulties.