- Testing show the presence of defects: When we test software, we may or may not find defects. If we find defects, then that’s proof of the presence of bugs. But if your tests didn’t find defects, thats not proof that the software is defect free. Testing can show the defects are present, but cannot prove that there are no defects. Even after testing the application or product thoroughly, we cannot say that the product is 100% defect free. Testing always reduces the number of undiscovered defects remaining in the software but even if no defects are found, it is not a proof of correctness.
- Exhaustive testing is impossible: Testing everything including all combinations of inputs and preconditions is not possible. So, instead of doing exhaustive testing we can use risks and priorities to focus testing efforts
- Early Testing: When a bug in the requirement is discovered during the requirement phase, the cost of fixing this bug is very cheap. The more we wait on fixing this bug, the more costly it is to be fixed.
- Defect clustering: A small number of modules contains most of the defects discovered during pre-release testing or shows the most operational failures.
- Pesticide paradox: f the same kinds of tests are repeated again and again, eventually, the same set of test cases will no longer be able to find any new bugs. To overcome this “Pesticide Paradox”, it is really very important to review the test cases regularly and new and different tests need to be written to exercise different parts of the software or system to potentially find more defects.
- Testing is context-dependent: Testing is basically context-dependent. Different kinds of sites are tested differently. For example, safety-critical software is tested differently from an e-commerce site
- Absence – of – errors fallacy: If the system built is unusable and does not fulfil the user’s needs and expectations then finding and fixing defects does not help.