Software Testing Mentor

www.softwaretestingmentor.com

ISTQB Foundation Level and Software Testing Training

www.softwaretestingmentor.com
 Module 1
Fundamentals of Software Testing

Session 3 – Seven Principles of Testing

www.softwaretestingmentor.com
 Seven Testing Principles

There are
seven testing • Testing shows the presence of defects
• Exhaustive testing is impossible
principles
• Early testing
which offer • Defect clustering
general • Pesticide paradox
guidelines • Testing is context dependent
common for • Absence-of-error fallacy
all testing
Principle 1: Testing shows the presence of defects
Testing can show that 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 proof of correctness

For example: If you only see white swans, you can say that “All swans are white”
but as soon as you see one black swan you cannot say “All swans are white”

Similarly for software

If you are executing test cases and you did not find any defect in many test cases
that you executed, you still cannot say that there are no bugs in software.
As soon as you find one bug you can say that “Software is not defect free”
 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.

• There are 10 possible valid numeric values

Example 1: How many • Invalid scenario: There are 26 uppercase alpha characters, 26
tests would you need to lower case,
do to completely test a • At least some special and punctuation characters as well as a
one-digit numeric field? blank value. So there would be approx. 68-70 tests for this
example of a one-digit field.

Example 2: If we take an • Each having 5 possible values, then to test all of the valid input
value combinations you would need 30 517 578 125 (5^15)
example where one tests!
screen has 15 input • It is very unlikely that the project timescales would allow for this
fields number of tests.
 Principle 3: Early testing
Testing activities should start as early as possible in the software development life
cycle and should be focused on defined objectives.

Early testing - such as early test design and review activities because its cheap to find
and fix defects in initial phases of SDLC.

After development objective should be to find as many integration, system defects as

you can

UAT objective should be to find out if the software meets end user requirements

Maintenance testing objective should be to ensure that there are no new defects
introduced in system by changing the software or fixing defects. This is known as
regression testing

If we continue testing production use, main objective should be to asses system

availability and reliability.
 Principle 4: Defect clustering

A small
number of
modules • Most of the testers have noticed that
contain most defects tend to cluster
of the defects • Defect clustering can happen because an
area of the code is complex and tricky
discovered
• Changing software and other products
during pre- tends to cause knock-on defects.
release testing • Testers should use this information when
or show the making their risk assessment for planning
most the tests, and focus on known 'hot spots'.
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 • As the 'hot spots' for bugs get cleaned
be regularly reviewed up we need to move our focus
and revised, and new elsewhere because same set of tests
and different tests would not find any more defects
need to be written to
exercise different • Over time, focus should be changed
parts of the software from finding coding bugs, to looking at
or system to the requirements and design defects
potentially find more
defects.
 Principle 6: Testing is context dependent
Testing is done differently in different contexts

For example, safety critical software is tested differently from an e-commerce site

Not all software systems carry the same level of risk. So, different approach is taken to
test software's in different contexts

Few examples:
1. Family website – Adhoc testing is enough, no tool used, just manual testing is
enough
2. eCommerce application – More testing done for websites functional, non-
functional attributes, different tools are used and general company procedures and
guidelines are followed.
3. Traffic control system – Testing is done by different set of tools and technologies,
also much more strict testing guidelines need to be followed. Strict entry and exit
criteria for testing.
 Principle 7: Absence-of-error fallacy

Finding and
fixing defects • The customer who buys software
does not help do not bother about number of
if the system defects until software directly
built is affects them and is unstable to
unusable and use
DOES NOT • They are more interested in
fulfill the software fulfilling their
users needs requirements and does what
and they want it to do.
expectations
 Conclusion

To conclude, • Testing shows the presence of defects

In this • Exhaustive testing is impossible
• Early testing
session we • Defect clustering
learned 7 • Pesticide paradox
principles of • Testing is context dependent
testing • Absence-of-error fallacy
Thank You!!!