main banner

Development

Testing Principles

Software Testing is an activity that requires intellectual and creative skills and Software can be tested in different ways, depending on the expertise and imagination of the Tester.


There are seven principles of Software Testing that can help us in the testing process; some of them might seem obvious, but its very useful to have them in mind when we are conducting a Test. These principles have been suggested over the past 40 years and offer general guidelines common for all testing.

Principle 1: Testing shows presence of defects.

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

Principle 2: Exhaustive testing is impossible.

Testing everything (all combinations of inputs and preconditions) is not feasible except for trivial cases. Instead of exhaustive testing, we use risks and priorities to focus testing efforts.

Principle 3: Early testing.

Testing activities should start as early as possible in the software or system development life cycle and should be focused on defined objectives.

Principle 4: Defect clustering.

A small number of modules contain most of the defects discovered during pre-release testing or show the most operational failures.

Principle 5: Pesticide paradox.

If the same tests are repeated over and over again, eventually the same set of test cases will no longer find any new bugs. 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 parts of the software or system to potentially find more defects.

Principle 6: Testing is context dependent.

Testing is done differently depending on the 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’ needs and expectations.
Source: ISTQB Syllabus.


Ivan V.

Ivan has 7 years of experience as a developer and 5 more as a Quality Assurance Engineer, making this 12 years of an amazing career; he has an MS in IT and has specially focused on Java, SQL and QA process. Born in Mérida, Yucatán, he moved to Monterrey some years ago and has been working with us for a while now; among his hobbies are playing the guitar an attending concerts, but the one we all have come to know is his passion for basketball which has made him a key player for the Inflection Point basketball team. He has some pretty cool posts into the blog that you’ll love to read.

Articles