Download
1 / 11
110 likes | 117 Views
1) an exhaustive examination is not possible<br>2) Lack Clustering<br>3) Pesticide Paradox<br>4) examination shows a presence of defects<br>5) lack of error-fallacy
E N D
Software testing Principles: 1) an exhaustive examination is not possible A comprehensive examination is not possible. Instead, we need the optimal amount of Tests based on the risk assessment of the application.
2) Lack Clustering Defect Clustering, which means that a small number of modules contain most of the defects found. This is the application of the Pareto principle to software testing: approximately 80% of the problems are found in 20% of the modules. By experience you can identify such risky modules. But this approach has its own problems If the same tests are repeated again and again, the same test cases will eventually no longer find any new errors.
3) Pesticide Paradox The repeated use of the same pesticide mixture for the eradication of insects during agriculture leads over time to the fact that insects develop resistance to the pesticide, whereby pesticides on insects become ineffective. The same applies to software testing. If the same repeated tests are performed, the method is useless to discover new defects. To overcome this, the test cases need to be reviewed and revised regularly, adding new & different test cases to find more defects.
4) examination shows a presence of defects Therefore, test principle states that-Test speaks about the presence of defects and does not talk about the absence of defects. this means that software testing reduces the likelihood that undetected defects remain in the software, but even if no defects are found, it is not proof of correctness.
5) lack of error-fallacy It is possible that Software that is 99% error free is still unusable. This can be the case if the system is thoroughly tested for the incorrect requirement. Software testing is not only the discovery of defects, but also the verification that software meets the business needs. The absence of an error is an error, i.e. finding and correcting errors does not help if the system structure is unusable and does not meet the requirements of the user.
6) Early Tests Early Test Tests should start as early as possible in the software development lifecycle. In order to detect any defects in the requirements or design phase at an early stage. It is much cheaper to fix a defect in the early stages of testing. But how early should one start testing? It is recommended that you find the error as soon as the requirements are defined.
7) testing depends on context Testing is context-sensitive, which basically means that the way you test an e-commerce Website is different from the way you test a commercial off-the-shelf application. All developed software are not identical. You can use a different approach, methods, techniques, and types of Tests, depending on the type of application. For example, testing every POS system in a retail store will be different from testing an ATM machine.
