Scribd
Upload
12 views21 pages

3.Testing Principles

Uploaded by

Arul
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PPTX, PDF, TXT or read online on Scribd
12 views21 pages

3.Testing Principles

Uploaded by

Arul
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
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