Scribd
Upload
3 views

3.Testing Principles

Uploaded by

Arul
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
3 views

3.Testing Principles

Uploaded by

Arul
Copyright
© © All Rights Reserved
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
You are on page 1/ 21

TE ST I N G

PRIN C IP L E S
Seven Principles of Software Testing
» EXHAUSTIVE TESTING IS NOT POSSIBLE

» DEFECT CLUSTERING

» PESTICIDE PARADOX

» TESTING SHOWS A PRESENCE OF DEFECTS

» EARLY TESTING

» TESTING IS CONTEXT DEPENDENT

» ABSENCE OF ERROR - FALLACY


1. EXHAUSTIVE TESTING IS NOT
POSSIBLE

• TESTING ALL THE FUNCTIONALITIES WITH VALID AND INVALID COMBINATIONS


OF INPUT DATA DURING ACTUAL TESTING IS IMPOSSIBLE.
• THEREFORE, TESTING OF A FEW COMBINATIONS IS DONE BASED ON PRIORITY
USING DIFFERENT TECHNIQUES.
3 menus with 2
An Website has 4 pages,
options each.
n ha s 5 fie lds, 2 ty pe s of inputs each
Optio
fields.
possible values.
Each input type has 50
s for exhaustive
The total test condition
testing
W eb si te ha s 4 pa ge s, 3 menus with 2
An
options each.
pes of inputs each
Option has 5 fields, 2 ty
fields.
in pu t ty pe ha s 50 po ssible values.
Each
e tota l te st co nd ition s for exhaustive
Th
testing
2 options * 5
4 pages * 3 menus *
lues = 30,000
fields * 2 types * 50 va
tests
2. DEFECT CLUSTERING

• IN A PROJECT, A SMALL NUMBER OF MODULES CONTAIN MOST OF THE


DEFECTS DETECTED.
• THIS IS THE APPLICATION OF THE PARETO PRINCIPLE TO SOFTWARE TESTING
(80-20 RULE)
❑ 80% OF ISSUES COMES FROM 20% OF MODULES AND
❑ REMAINING 20% OF ISSUES FROM REMAINING 80% OF MODULES.
eted by 20% of your
80% of work is compl
team
ere is of te n a w id e pe rformance gap between
Th
ur to p pe rfo rm er s an d the rest of the team.
yo

st om er s on ly us e 20 % of software
80% of cu
features
d
os t us er s do n't us e po wer features as they fin
M noying
power features to be an
3. PESTICIDE PARADOX

• IF YOU EXECUTE THE SAME SET OF TEST CASES AGAIN AND AGAIN OVER THE
PERIOD OF TIME THESE SET OF TEST CASES CANNOT IDENTIFY NEW DEFECTS
IN THE SYSTEM.
• SO TO OVERCOME THIS PESTICIDE PARADOX, IT IS NECESSARY TO REVIEW
THE TEST CASES REGULARLY AND ADD OR UPDATE THEM TO FIND MORE
DEFECTS.
ep et it iv e u se of th e same pesticide
R
s during farming
mix to destroy insect
the insects
over the time lead to
in g re si st an ce to th e pesticide,
develop
er eb y m ak in g th er eby pesticides
Th
ineffective on insects
software testing
The same applies to
4. TESTING SHOWS A PRESENCE OF
DEFECTS

• TESTING TALKS ABOUT THE PRESENCE OF DEFECTS & DON’T TALK ABOUT
THE ABSENCE OF DEFECTS
• SOFTWARE TESTING CAN ENSURE THAT DEFECTS ARE PRESENT, BUT IT CAN
NOT PROVE THAT SOFTWARE IS DEFECTS FREE.
• EVEN MULTIPLE TESTING CAN NEVER ENSURE THAT SOFTWARE IS 100% BUG-
FREE.
plic at ion m ig ht se em to be error-
An ap
ugh different
free after going thro
stages of testing.
ction in the
But during the produ
vi ronm en t, th e u se r may come
en
ross an y de fe ct w hi ch did not occur
ac
during the testing.
5. EARLY TESTING

• TESTING NEEDS TO BE PERFORMED ON REQUIREMENT DOCUMENTS,


SPECIFICATION OR ANY OTHER TYPE OF DOCUMENT.
• SO THAT IF REQUIREMENTS ARE INCORRECTLY DEFINED THEN IT CAN BE FIXED
IMMEDIATELY RATHER THAN FIXING THEM IN THE DEVELOPMENT PHASE.
• THE COST INVOLVED IN FIXING SUCH DEFECTS IS VERY LESS WHEN COMPARED
TO THOSE THAT ARE FOUND DURING THE LATER STAGES OF TESTING.
m e tw o sc en ar ios, fi rst is identifying
Assu
ent in the
an incorrect requirem
g phase and the
requirement gatherin
a bug in the fully
second is identifying
ity.
developed functional
s, first is identifying
Assume two scenario
ent in the
an incorrect requirem
ir em en t g at h er in g phase and the
requ
co nd is id en ti fy in g a bug in the fully
se
ity.
developed functional
ge the incorrect
It is cheaper to chan
en t co m par ed to fi xing the fully
requirem
el op ed fu nc ti on al it y which is not
dev
working as intended
6. TESTING IS CONTEXT
DEPENDENT

• ALL THE DEVELOPED SOFTWARE’S ARE NOT IDENTICAL.


• DIFFERENT DOMAINS ARE TESTED DIFFERENTLY.
• THUS, TESTING IS PURELY BASED ON THE CONTEXT OF THE SOFTWARE.
em at a
Testing any POS syst
erent than
retail store will be diff
ine
testing an ATM mach
7. ABSENCE OF ERROR - FALLACY

• IF THE SOFTWARE IS TESTED FULLY AND NO DEFECTS ARE FOUND BEFORE


RELEASE, THEN YOU CAN CONSIDER THE SOFTWARE TO BE 99% DEFECT-FREE.
• BUT IF THE SOFTWARE IS TESTED AGAINST WRONG REQUIREMENTS, THEN IT IS
UNSTABLE.
• SO, SOFTWARE WHICH WE BUILT NOT ONLY BE A 99% BUG-FREE , BUT ALSO IT
MUST FULFIL THE BUSINESS NEEDS OTHERWISE IT WILL BECOME AN UNUSABLE
SOFTWARE.
n related to an e-
Testing an applicatio
e requirements
commerce site and th
st “S ho pp in g C ar t” functionality
agai n
w ro n gl y in terp re te d and tested.
is
n di ng m or e d ef ec ts would not help in
Fi
n into the next
moving the applicatio
tion
phase or in the produc
environment.
REFERENCES
I DEO LEC TURE BY
V

J .P R A K A S H
TA N T P RO FES S OR
ASSI S
OF TE C HN OL O GY
PSG COLLEGE

You might also like