1.3 Seven Testing Principles

1.3 Seven Testing Principles

2015-06-23

Principle 1-testing shows presence of defects (test shows defective)

Testing can show that defects is present, but cannot prove that there is no defects. Testing can reduces the probability of undiscovered defects remaining in software, but even if no defects was found, it is Not a proof of correctness.

The test can show that there is a flaw, but it does not prove that the system is defective. Testing can reduce the likelihood of an uncovered defect in the software, but even if the test does not detect any defects, it does not prove that the software or system is completely correct.

Principle 2-exhaustive testing is impossible (exhaustive test is not feasible)

Testing everything (all combination of input and precondition) are not feasible except for trivial cases. Instead of exhaustive testing, risk analysis and priorites should is used to focus testing efferts.

In addition to small projects, it is not feasible to perform complete tests (combinations of various inputs and preconditions). Replace exhaustive testing by using risk analysis and testing priorities for different system functions to determine the focus of the test.

Principle 3-early Testing (Test early intervention)

To find defects early, testing activities shall is started as early as possible in the software or system development of L Ife cycle, and should focus on defined objectives.

In order to identify defects early, test activities should be involved as early as possible in the software or system development life cycle, and focus should be placed on the defined test targets.

Principle 4-defect Clustering (defect clustering)

Testing Effert shall is focused proportionally to the expected and later observed defect density. A small number of modules usually contains most of the defects discovered during pre-release testing, or are responsible fo R most of the operational failures

The distribution of the test work should be proportional to the expected and later observed defect distribution modules. A few modules usually contain defects or failures found in most of the beta versions.

Principle 5-pesticide paradox (pesticide paradox)

If the same tests is repeat over and over again, eventually the same set of test cases would no longer find new defect. To overcome the "pesticide paradox", test cases need to be regularly reviewed and revised, and new and different tests NE Ed to is written to exercise different part of the software or system to find potentially more defects.

Testing is repeated over and over again using the same test cases, and no new defects can be discovered at the end. To overcome this "pesticide paradox", test cases need to be regularly reviewed and modified, while new and different test cases need to be added to test different parts of the software or system to uncover potentially more pitfalls.

Principle 6-testing is context dependent (test activity depends on test background)

Testing is do differently in different contexts. For example, safety-critical software are tested differently from an E-commerce site.

Conduct different testing activities for different test backgrounds. For example, testing for security-critical software is not the same as testing for generic e-commerce software.

Principle7-absence-of-errors fallacy (the fallacy that there is no flaw (that is, a useful system)

Finding and fixing defects does not help if the system built are unusable and does not fulfill the users ' need and Expectat Ion.

If the system is not available, or the system does not fulfill the customer's needs and expectations, it does not make sense to discover and modify defects.

1.3 Seven Testing Principles