There are seven principles of testing. They are as follows:
§ Testing shows the presence of bugs
§ Exhaustive Testing is Impossible
§ Early Testing
§ Defect Clustring
§ Pesticide Paradox
§ Testing is context depending
§ Absence of errors fallacy
Testing shows the presence of bugs:
§ 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 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.
§ The sooner we start the testing activities the better we can utilize the available time.
§ As soon as the initial products, such the requirement or design documents are available, we can start testing.
§ It is common for the testing phase to get squeezed at the end of the development lifecycle, i.e. when development has finished, so by starting testing early, we can prepare testing for each level of the development lifecycle.
§ During testing, it can be observed that most of the reported defects are related to small number of modules within a system. i.e. small number of modules contain most of the defects in the system.
§ This is the application of the Pareto Principle to software testing: approximately 80% of the problems are found in 20% of the modules.
§ 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 â€œPesticideParadoxâ€, 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.
§ Different methodologies, techniques and types of testing is related to the type and nature of the application. For example, a software application in a medical device needs more testing than a games software.
§ More importantly a medical device software requires risk based testing, be compliant with medical industry regulators and possibly specific test design techniques.
§ By the same token, a very popular website, needs to go through rigorous performance testing as well as functionality testing to make sure the performance is not affected by the load on the servers.
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.