There are seven fundamental principles of software testing as stated below:
Principle 1: Testing shows presence of defects.
Testing can show the defects are present, but cannot prove that there are no defects.
Testing reduces the probability of undiscovered defects remaining in the software but, even if no defects are found, it is not a proof of correctness.
Example:-A software in staging environment is working fine with all defects fixed but the same software may not work in same way in production environment.
Principle 2: Exhaustive testing is impossible.
Testing everything (all combinations of inputs and preconditions) is not possible except for trivial cases. Instead of exhaustive testing, risk analysis and priorities should be used to focus testing efforts.
Let us consider an example of an application which generates bank statement at the end of every month and sends it to their customers.so in this case practically it is impossible for us to test each and every statement that is being generated to each customer. The only way to perform this is by identify a suitable sample for it.
Principle 3: Early testing.
Testing process must start as early as possible in software or system development life cycle and should be focused on defined objectives.
If testing is started early defects will be identified early reducing overall cost and time of software or application.
Principle 4: Defect clustering
A small number of modules contains most of the defects discovered during pre-release testing or responsible for most operational failures.
Testing effort shall be focused proportionally to the expected and later observed defect density of modules.
Principle 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 defects.
To overcome this “Pesticide Paradox”, the test cases need to be regularly reviewed and revised, and new and different tests need to be written to exercise different part of the software or system to potentially find more defects. Because as the system evolves, many of the previously reported defects will have been fixed and the old test cases do not apply anymore.
Anytime a fault is fixed or a new functionality is added, we need to do regression testing to make sure that the new changed software has not broken any other part of the software. However, those regression test cases also need to change to reflect the changes made in the software to be applicable and hopefully fine new defects.
Principle 6: Testing is context dependent.
Testing is done differently in different context. For example, safety-critical software is tested differently from an e-commerce site.
Principle 7: Absence of errors fallacy.
Finding and fixing defects does not help if the system built is unusable and does not fulfill the users need and expectations.Share This: