Principles of Software Testing:
As software development techniques have advanced during the last decades, some basic principles of testing have also been established. Describing theoretical ideas and practical hints, these principles can be seen as a basic guideline for both, testing and coding.
There are seven principles of testing.
1) Testing shows presence of defects: 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. Sufficient testing reduces the likelihood of existing, not discovered error conditions within the test object. It does not verify that no more bugs exist, even if no more errors can be found. Testing is not a prove that the system is free of errors
2) Exhaustive testing is impossible: Testing everything including all combinations of inputs and preconditions is not possible. So, instead of doing the exhaustive testing we can use risks and priorities to focus testing efforts. For example: In an application in one screen there are 15 input fields, each having 5 possible values, then to test all the valid combinations you would need 30 517 578 125 (515) tests. This is very unlikely that the project timescales would allow for this number of tests. So, accessing and managing risk is one of the most important activities and reason for testing in any project.
3) Test early and regularly: In the software development life cycle testing activities should start as early as possible and should be focused on defined objectives. They should be repeated regularly and have its’ own agenda. Early testing helps detecting errors at an early stage of the development process which simplifies error correction (and reduces the costs for this work).
4) Defect clustering: A small no. of modules contains most of the defects discovered during pre-release testing or shows the most operational failures. There is no equal distribution of errors within one test object. The place where one error occurs, it’s likely to find some more. The testing process must be flexible and respond to this behavior.
5) Pesticide paradox: If 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. The effectiveness of tests fades over time. If test-cases are only repeated, they do not expose new errors. Errors, remaining within untested functions may not be discovered. In order to prevent this effect, test-cases must be altered and reworked time by time. It is also called as fading effectiveness
6) Testing is context depending: 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. No two systems are the same and therefore cannot be tested the same way. Testing intensity, the definition of end criteria etc. must be defined individually for each system depending on its testing context. E-commerce websites require a different approach than online-banking applications
7) Absence –of – errors fallacy: If the system built is unusable and does not fulfill the user’s needs and expectations then finding and fixing defects does not help. Error detection and error fixing does not guarantee a usable system matching the users expectations. Early integration of users and rapid prototyping prevents unhappy clients and discussions.