Over the years it
has become a misconception among some that using the seven principles of
software testing is not compulsory or required. But in fact, it is a necessity.
Most of these principles are implied sub-consciously by tester that have been
in the field for long. Even so, it best to check consciously for the presence
of these of principles to ensure good quality testing and effectiveness of the
Let’s consider an
example. I make an application to deliver pizza.
Principle 1: Testing
shows presence of defects:
This principle merely says that
in every software there is the presence of errors and having done testing does
not say or mean that the software is now bug or error free. There may not be any technical errors but there my exist logical
A person using my pizza application
my be allowed to order 0 pizzas, which does not make any sense. This is an
2: Exhaustive testing is impossible:
The whole point of conducting testing on a software application/ web-
application is to uncover the errors which were not spotted earlier. Therefore,
the best testers would obviously try to cover every inch of the program, or in
other words conduct extensive testing. In reality, it is extremely difficult to
perform such of a kind fully comprehensive study of the program. Thus,
‘exhaustive testing is impossible”.
3: Early testing:
Testing should begin in the very initial stages of the development of the
software. Defects can be found even in the documentation, not only in
programming or functionality. Moreover, defects found at these stages can be
fixed in lower the cost and saves time.
When we start with the documentation of the pizza application
we begin with the requirements and planning the design of the user interface
and structure of the program. It is at this stage that I may realize there
should be limit to the number of pizzas ordered. Or that a pizza should have a
maximum number of toppings. These errors would be caught before beginning to
program and help the developer implement the changes beforehand instead of
changing it later.
4: Defect clustering:
The Pareto principle
states that “approximately 80% of the problems are found in 20% of the
modules”. This means that a bunch of errors are usually found in some particular
cluster of the program. Sometimes after fixing errors, new errors are generated
in that section and theses to have to be tested for.
5: Pesticide paradox:
After testing the
system a few times, we may not be able to find new bugs in the program using
the same old test cases over and over again, which is of course a good thing.
But we have to make sure that new types of errors have not been generated,
especially after the older ones have been fixed. Thus, we perform what is
called as regression testing.
6: Testing is context dependent:
For every which content
type, there exist different methods / approaches and techniques for testing.
Some software’s maybe be tested using tools. Mobile devices and web
applications shall use different tools and approaches.
application for the ordering pizza and desktop website for the same will be tested
using different methods.
7: Absence–of–errors fallacy:
For the customer, the most
devastative defects are those that do not fulfil their requirement. Hence it
said that “All tests should be
traceable to customer requirements “. A software without any errors (very
unlikely!) may not be the best made if it does not do what the customer has
In the application I have made,
an user is able to order pizza and the pizza is even delivered successfully.
One would say that the application works very well. Although the error that is
uncovered later is that the application has been making an error in calculating