Goals and roles of the testers in the team during the evolution of software testing.

1. The History of Software Testing

2. The History of Software Testing
DEBAGGING
testing was often
associated to
debugging: there was
no clear difference
between testing and
debugging
… - 1956
DEMONSTRATION
in this period it was
shown, that
software satisfies
the requirements
1957 - 1978
DESTRUCTION
the goal was
to find
errors
1979 - 1982
EVALUATION
during the software
lifecycle a product
evaluation is
provided and
measuring quality
1983 - 1987
PREVENTION
to prevent faults in
requirements,
design, and
implementation
1988 - ...

3. The History of Software Testing
DEBAGGING
testing was often
associated to
debugging: there
was no clear
difference between
testing and
debugging
… - 1956

4. Falsifiability (Popper)
Theory can only be considered
scientific if an experiment can
be conducted that can falsify
the theory.
1934
The Fisrt
Computer
(Analytical
Engine, built
by Babbage)
It was created
to calculate a
series of values
automatically.
1837
The Fisrt
Programmer
(Ada
Lovelace)
Published the
first
algorithm for
Babbage’s
Analyticall
Engine.
1843
The Fisrt Using
the Term ‘Bug’
Thomas Edison:
“..."Bugs" - as
such little faults
and difficulties
are called… ”
1878
THE DEBAGGING - ORIENTED PERIOD
The Fisrt Documented Computer Bug
1946
Juran's Quality Control Handbook
Three processes for the management
of quality: quality planning, quality
control and quality improvement.
1951
The Fisrt High-level
Programming
Language
(FORTRAN)
1954

5. The History of Software Testing
DEMONSTRATION
in this period it was
shown, that
software satisfies
the requirements
1957 - 1978

6. Cost-of-change curve (Boehm)
The curve essentially shows that
the cost of changing the software
(fixing a software defect) rises
exponentially in time.
1976
First software test team (Project
Mercury)
1958
Testing shows the presence,
not the absence of bugs
Edsger Dijkstra, conference by
the NATO Science Committee,
Rome, Italy
1969
Decision table
Burton Grad, working at IBM, introduces
decision tables.
1969
THE DEMONSTRATION - ORIENTED PERIOD
State
transition
testing
Tsun S. Chow
introduces
testing
techniques for
state transition
testing.
1976

7. The History of Software Testing
DESTRUCTION
the goal was
to find
errors
1979 - 1982

8. The First Computer Graphic
Disney movie, Tron is a hybrid
form between actors and
overplayed graphics.
The Art of
Software Testing
The book by Glenford
Myers is the first book
about software testing
only. It introduces
black box testing.
1979
Space
Invaders
and Pacman
Were
Introduced
THE DESTRUCTION - ORIENTED PERIOD
IBM Personal
Computer Goes Mass
Market
The IBM-PC or IBM
5150 set the standard
for mass market
computer products.
1982
1981
1979

9. The History of Software Testing
EVALUATION
during the software
lifecycle a product
evaluation is
provided and
measuring quality
1983 - 1987

10. Use cases
In his paper Object Oriented Development in
an Industrial Environment Ivar Jacobson
introduces the concept of use cases and use
case modeling for the customer requirements.
1987
First testing
industry
conference
The US Professional
Development
Institute.
1984
The first domain name is
registered
Symbolics.com becomes the
first registered domain.
1985
Windows 1.0 released
1985
THE EVALUATION - ORIENTED PERIOD

11. The History of Software Testing
PREVENTION
to prevent faults in
requirements,
design, and
implementation
1988 - ...

12. Pesticide paradox
In the second edition of Software Testing Techniques
Boris Beizer coins the term pesticide paradox to
describe the phenomenon that the more you test
software, the more immune it becomes to your tests.
Exploratory
testing
introduced
In the book Testing
Computer Software
Cem Kaner uses the
term 'exploratory
testing' for the
first time.
1988
HyperText
Markup
Language
Physicist from
CERN Tim
Berners-Lee
First Internet service provider
The World: the first commercial provider
of dial-up Internet access.
THE PREVENTION - ORIENTED PERIOD
Linux
released
Released by
student
Linus
Torvalds
from
Finland
19911990
19901990

13. Context-Driven Testing
Cem Kaner, James Bach, Brian Marick and
Bret Pettichord start the Context-Driven
school of testing based on the principle that
'The value of any practice depends on its
context'.
The first graphical
browser
Marc Andreessen produced
the Mosaic browser
1992
Google online
Larry Page and Sergey Brin launch
Google; the internet service
provider that rapidly becomes the
most visited website in the world.
Pairwise testing
Introduced by David
Cohen, Siddhartha
Dalal, Jesse Parelius
and Gardner Patton in
their paper The
Combinatorial Design
Approach to Automatic
Test Generation
THE PREVENTION - ORIENTED PERIOD
Agile Manifesto
published
17 representatives from
different development
methodologies leads to
the Agile Manifesto in
which the Twelve
Principles of Agile
Software are published.
20011996
19991996

14. Selenium developed
The popular web
application test tool
Selenium is developed at
by Jason Huggins.
ISTQB founded
The International Software
Testing Qualifications
Board is founded in
Edinburgh.
2002
Test-Driven Development
In the book Test Driven Development: By
Example Kent Beck publishes the software
development technique in which a test is
written before the functionality is coded.
Schools of Software
Testing
Bret Pettichord publishes the
paper in which he classifies
software testing ideas into
five schools.
THE PREVENTION - ORIENTED PERIOD
Test
Automation
Pyramid
Published in
the book
Succeeding
with Agile by
Mike Cohn.
20092003
20042002

15. The History of Software Testing
DEBAGGING
to debug the
software
… - 1956
DEMONSTRATION
to prove that
software works
1957 - 1978
DESTRUCTION
to prove that
software
doesn’t work
1979 - 1982
EVALUATION
to measure the
quality
1983 - 1987
PREVENTION
to prevent faults
1988 - ...

16. Seven principles of Software Testing

17. 1 - Testing shows presence of defects
Testing can show the defects are present, but cannot prove that there are no defects.
Even after testing the application or product thoroughly we cannot say that the product is
100% defect free. Testing always reduces the number of undiscovered defects remaining
in the software but even if no defects are found, it is not a proof of correctness.

18. 2 - Exhaustive testing is impossible
Testing everything including all combinations of inputs and preconditions is not possible.
So, instead of doing the exhaustive testing we can use risks and priorities to focus testing efforts. For
example: In an application in one screen there are 15 input fields, each having 5 possible values, then
to test all the valid combinations you would need 30 517 578 125 (515
) tests. This is very unlikely that
the project timescales would allow for this number of tests. So, accessing and managing risk is one of
the most important activities and reason for testing in any project.

19. 3. Early testing
It is much cheaper to fix a Defect in early stages of testing.
In the software development life cycle testing activities should start as early as possible
and should be focused on defined objectives. So that any defects in the requirements or
design phase are captured in early stages.

20. 4. Defect clustering
A small number of modules contains most of the defects discovered during pre-release
testing or shows the most operational failures.
This is the application of the Pareto Principle to software testing: approximately 80% of
the problems are found in 20% of the modules.

21. 5. Pesticide paradox
If the same kinds of tests are repeated again and again, eventually the same set of test
cases will no longer be able to find any new bugs.
To overcome this “Pesticide Paradox”, it is really very important to review the test cases
regularly and new and different tests need to be written to exercise different parts of the
software or system to potentially find more defects.

22. 6. Testing is context dependent
Testing is basically context dependent.
Different kinds of sites are tested differently. For example, safety – critical software is
tested differently from an e-commerce site. All the developed software’s are not identical.
You might use a different approach, methodologies, techniques and types of testing
depending upon the application type.

23. 7. Absence – of – errors fallacy
If the system built is unusable and does not fulfil the user’s needs and expectations then
finding and fixing defects does not help.
It is possible that software which is 99% bug-free is still unusable. This can be the case if
the system is tested thoroughly for the wrong requirement. Software testing is not mere
finding defects, but also to check that software addresses the business needs.