The 7 QA Software Testing Principles

The seven testing Principles

1.??????Testing shows the presence of defects, Not their absence.

-?????????When you test software, you may or may not find defects. If you find defects, then that’s a proof of the presence of bugs. But if your test didn’t find defects, that’s not proof that the software is defect free. Maybe you didn’t select the right test data to exercise the software. Maybe the defect is waiting for an exceptional circumstance to fail the software. There’s nothing called bug-free software, there’s no way we can prove that. We simply need to design as many tests as possible to find as many defects as possible. Testing is not a proof of correctness.

2.??????Exhaustive Testing is Impossible.

-?????????Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases.

3.??????Early Testing saves Time and Money

-?????????We are trying to find errors and effects as early as possible, before they are passed to the next stage of the development. When a bug in the requirement is discovered during the requirement phase, the cost of fixing this bug is very cheap. The more we wait on fixing this bug, the more costly it is to be fixed. Why? Because now we might have built some of our design based on this faulty requirement.

-?????????If a customer discovers a bug after delivering, the software will cost as 1000 times higher than if we would have discovered and fixed the bug in the requirement phase. To find defects early, testing activities shall be started as early as possible in the software or system development life cycle, as soon as the document are in draft mode, and shall be focused on defined objectives. (Can we find missing requirements, etc.) If we wait until the last minute to introduce the testers, time pressure can increase dramatically. The earlier the testing activity is started, the longer the elapsed time available. Testers do not have to wait until the software is available to test.

4.??????Defect Cluster Together

-?????????Reasons for defect clustering: System Complexity, Volatile code, The effects of change, Development staff experience, Development staff inexperience. A small number of modules usually contains most of the defects discovered during pre-release testing or is responsible for most of the operational failures. Predicted defect clusters, and the actual observed defect clusters in test or operation, are essential input into a risk analysis used to focus the test effort. Pareto principle 80/20 (80% of problems are found in 20% of the modules) so if you want to uncover a higher number of the fix is useful to employ this principle and target the area of the application where a hype of defects can be found.

5.??????Beware of the Pesticide Paradox

-?????????If the same tests are repeated, eventually the same set of test cases will no longer find any new defects. To detect tests, new test cases need to be regularly reviewed and revised.

6.??????Testing is context dependent

-?????????Different testing is necessary for different circumstances. A simple static website will be tested differently than a dynamic e-commerce site. A software used in an airplane will be tested differently than a flight simulator. Safety-critical industrial control software is tested differently from a mobile e-commerce app. The log in for a banking system will be done differently than a log in game, even though the interface might look identically the same in both applications. Testing in an Agile project is done differently than testing in a sequential lifecycle project.

7.??????Absence of Errors is a Fallacy

-?????????To expect that just finding and fixing many defects will ensure the success of a system. Software with no known errors is not necessarily ready to be shipped. Does the application under test fulfill the needs or not?