Software Engineering TESTING AND MAINTENANCE
AnuranjanMisra
489 views
116 slides
May 20, 2024
Slide 1 of 162
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
About This Presentation
Software testing fundamentals-Internal and external views of Testing-white box testing - basis path testing-control structure testing-black box testing- Regression Testing – Unit Testing – Integration Testing – Validation Testing – System Testing and Debugging –Software Implementation Tech...
Slide Content
1
Software Engineering
KCS-601, Unit-IV
Dr APJ Abdul KalamTechnical
University, Lucknow
By
Dr AnuranjanMisraDr AnuranjanMisra
innovation
Ambassador
Ministry of Education,
Government of India
& Professor & Dean,
GNIOT, Greater
Noida
Software Engineering
KCS-601, Unit-IV
Dr APJ Abdul KalamTechnical
University, Lucknow
By
Dr AnuranjanMisraDr AnuranjanMisra
innovation
Ambassador
Ministry of Education,
Government of India
& Professor & Dean,
GNIOT, Greater
Noida
Testing Objectives
•
Testing is the process of executing a program
with the intent of finding errors.
•
A good test case is one with a high probability of
finding an as-yet undiscovered error.finding an as-yet undiscovered error.
•
A successful test is one that discovers an as-yet-
undiscovered error.
•
Testing is the process of executing a program
with the intent of finding errors.
•
A good test case is one with a high probability of
finding an as-yet undiscovered error.finding an as-yet undiscovered error.
•
A successful test is one that discovers an as-yet-
undiscovered error.
Testing Principles
•
All tests should be traceable to customer
requirements.
•
Tests should be planned before testing begins.
•
80% of all errors are in 20% of the code.
•
Testing should begin in the small and progress to
the large.
•
Exhaustive testing is not possiblefor real
programs due to combinatorial explosion of
possible test cases
•
Testing should be conducted by an independent
third party if possible.
•
All tests should be traceable to customer
requirements.
•
Tests should be planned before testing begins.
•
80% of all errors are in 20% of the code.
•
Testing should begin in the small and progress to
the large.
•
Exhaustive testing is not possiblefor real
programs due to combinatorial explosion of
possible test cases
•
Testing should be conducted by an independent
third party if possible.
Debugging vs. Testing
•
Debuggingis the process of finding errors in a
program under development that is not thought to
be correct.
•
Testingis the process of attempting to find errors
in a program that is thought to be correct.in a program that is thought to be correct.
•
Testing attempts to establish that a program
satisfies its specifications.
•
Testing can establish the presence of errors
but cannot guarantee for their absence.
•
Amount of testing performed must be balanced
against the cost of undiscovered errors.
•
Debuggingis the process of finding errors in a
program under development that is not thought to
be correct.
•
Testingis the process of attempting to find errors
in a program that is thought to be correct.in a program that is thought to be correct.
•
Testing attempts to establish that a program
satisfies its specifications.
•
Testing can establish the presence of errors
but cannot guarantee for their absence.
•
Amount of testing performed must be balanced
against the cost of undiscovered errors.
Verification and Validation
•
The distinction between the two terms is largely
to do with the role of specifications.
•
Validationis the process of checking whether the
specification captures the customer's needs. That
is, Specifications are as per customer is, Specifications are as per customer
requirements/needs.
•
Whereas, verificationis the process of checking
that the software meets the specification. That is,
software is as per specifications.
•
Testing = Validation + Verification
•
The distinction between the two terms is largely
to do with the role of specifications.
•
Validationis the process of checking whether the
specification captures the customer's needs. That
is, Specifications are as per customer is, Specifications are as per customer
requirements/needs.
•
Whereas, verificationis the process of checking
that the software meets the specification. That is,
software is as per specifications.
•
Testing = Validation + Verification
SOFTWARE TESTING FUNDAMENTALS
What is Testing?
•
Testingisaprocessofexercisingsoftwaretoverifythatit
satisfiesspecifiedrequirementsandtodetecterrors.
•
Softwaretestingisaprocessofexecutingaprogramor
•
Softwaretestingisaprocessofexecutingaprogramor
applicationwiththeintentoffindingthesoftwarebugs.
•
Itcanalsobestatedastheprocessofvalidatingand
verifyingthatasoftwareprogramorapplicationor
product:
1. Meets the business and technical requirements
that guided it’s design and development
2. Works as expected
3. Can be implemented with the same characteristic.
What is Testing?
•
Testingisaprocessofexercisingsoftwaretoverifythatit
satisfiesspecifiedrequirementsandtodetecterrors.
•
Softwaretestingisaprocessofexecutingaprogramor
•
Softwaretestingisaprocessofexecutingaprogramor
applicationwiththeintentoffindingthesoftwarebugs.
•
Itcanalsobestatedastheprocessofvalidatingand
verifyingthatasoftwareprogramorapplicationor
product:
1. Meets the business and technical requirements
that guided it’s design and development
2. Works as expected
3. Can be implemented with the same characteristic.
SoftwareTestabilityissimplyhoweasilyacomputer
programcanbetested.Thefollowingcharacteristicslead
totestablesoftware.
•
Operability
•
Observability
•
Observability
•
Controllability
•
Decomposability
•
Simplicity
•
Stability
•
Understandability
programcanbetested.Thefollowingcharacteristicslead
totestablesoftware.
•
Operability
•
Observability
•
Observability
•
Controllability
•
Decomposability
•
Simplicity
•
Stability
•
Understandability
Why is Software Testing necessary?
Softwaretestingisveryimportantbecauseofthefollowing
reasons:
1.Softwaretestingisreallyrequiredtopointoutthedefects
anderrorsthatweremadeduringthedevelopmentphases.
2.It’sessentialsinceitmakessureoftheCustomer’s
reliabilityandtheirsatisfactionintheapplication.
3.ItisveryimportanttoensuretheQualityoftheproduct.
Qualityproductdeliveredtothecustomershelpsingaining
theirconfidence.
4.Testingisrequiredforaneffectiveperformanceof
softwareapplicationorproduct.
Softwaretestingisveryimportantbecauseofthefollowing
reasons:
1.Softwaretestingisreallyrequiredtopointoutthedefects
anderrorsthatweremadeduringthedevelopmentphases.
2.It’sessentialsinceitmakessureoftheCustomer’s
reliabilityandtheirsatisfactionintheapplication.
3.ItisveryimportanttoensuretheQualityoftheproduct.
Qualityproductdeliveredtothecustomershelpsingaining
theirconfidence.
4.Testingisrequiredforaneffectiveperformanceof
softwareapplicationorproduct.
What is an error in software testing?
•
The mistake made by programmer is known as an ‘Error’.
This could happen because of the following reasons:
•
Because of some confusion in understanding the
functionality of the software
•
Because of some miscalculation of the values
•
Because of misinterpretation of any value, etc.
•
The mistake made by programmer is known as an ‘Error’.
This could happen because of the following reasons:
•
Because of some confusion in understanding the
functionality of the software
•
Because of some miscalculation of the values
•
Because of misinterpretation of any value, etc.
What is a Failure in software testing?
•
Ifundercertaincircumstancesthesedefectsgetexecuted
bythetesterduringthetestingthenitresultsintothe
failurewhichisknownassoftwarefailure.
•
Notalldefectsresultinfailures,somemaystayinactivein
thecodeandwemaynevernoticethem.Example:thecodeandwemaynevernoticethem.Example:
Defectsindeadcodewillneverresultinfailures.
Error: Human mistake that caused fault
Fault: Discrepancy in code that causes a failure.
Failure: External behavior is incorrect
•
Ifundercertaincircumstancesthesedefectsgetexecuted
bythetesterduringthetestingthenitresultsintothe
failurewhichisknownassoftwarefailure.
•
Notalldefectsresultinfailures,somemaystayinactivein
thecodeandwemaynevernoticethem.Example:thecodeandwemaynevernoticethem.Example:
Defectsindeadcodewillneverresultinfailures.
Error: Human mistake that caused fault
Fault: Discrepancy in code that causes a failure.
Failure: External behavior is incorrect
Test Characteristics
Kaner, Falk, and Nguyen [Kan93] suggest the following
attributes of a ―good‖ test:
•
A good test has a high probability of finding an error
•
A good test is not redundant
•
A good test should be ―best of breed‖
•
A good test should be neither too simple nor too complex
Kaner, Falk, and Nguyen [Kan93] suggest the following
attributes of a ―good‖ test:
•
A good test has a high probability of finding an error
•
A good test is not redundant
•
A good test should be ―best of breed‖
•
A good test should be neither too simple nor too complex
Artifacts of testing
Testcase:
Atestcaseisasetofconditionsorvariablesunderwhichatesterwill
determinewhetherasystemundertestsatisfiesrequirementsorworks
correctly.
Testplan:
ASoftwareTestPlanisadocumentdescribingthetestingscopeand
activities.Itisthebasisforformallytestinganysoftware/productina
project.
Testscript:
ATestScriptisasetofinstructions(writtenusinga
scripting/programminglanguage)thatisperformedonasystemunder
testtoverifythatthesystemperformsasexpected.Testscriptsareused
inautomatedtesting
Testcase:
Atestcaseisasetofconditionsorvariablesunderwhichatesterwill
determinewhetherasystemundertestsatisfiesrequirementsorworks
correctly.
Testplan:
ASoftwareTestPlanisadocumentdescribingthetestingscopeand
activities.Itisthebasisforformallytestinganysoftware/productina
project.
Testscript:
ATestScriptisasetofinstructions(writtenusinga
scripting/programminglanguage)thatisperformedonasystemunder
testtoverifythatthesystemperformsasexpected.Testscriptsareused
inautomatedtesting
What are the principles of testing?
There are seven principles of testing. They are as follows:
1) Testing shows presence of defects:
2) Exhaustive testing is impossible
3) Early testing: 3) Early testing:
4) Pesticide paradox
5) Testing is context depending
6) Testing is context depending
7) Absence –of –errors fallacy
There are seven principles of testing. They are as follows:
1) Testing shows presence of defects:
2) Exhaustive testing is impossible
3) Early testing: 3) Early testing:
4) Pesticide paradox
5) Testing is context depending
6) Testing is context depending
7) Absence –of –errors fallacy
Software Testing Strategy
Unit testing :Code
Integration testing : Design Integration testing : Design
Validation test : Requirements
System test : System engineering architecture
Unit testing :Code
Integration testing : Design Integration testing : Design
Validation test : Requirements
System test : System engineering architecture
•
UnitTesting–Usedtodetecterrorsfromeach
softwarecomponentindividually.
•
IntegrationTesting–Verification&program
constructionwheninteractionoccurswithin
componentoccurs.
•
SystemTesting–Elementsformingasystemis
•
SystemTesting–Elementsformingasystemis
testes.
•
ValidationTesting–S/wvalidationmeets
functional,behavioural&performance
requirements.
UnitTesting–Usedtodetecterrorsfromeach
softwarecomponentindividually.
•
IntegrationTesting–Verification&program
constructionwheninteractionoccurswithin
componentoccurs.
•
SystemTesting–Elementsformingasystemis
•
SystemTesting–Elementsformingasystemis
testes.
•
ValidationTesting–S/wvalidationmeets
functional,behavioural&performance
requirements.
INTERNAL AND EXTERNAL VIEWS OF TESTING
Testing is done by two methods
1. Black box testing
2. White box testing
Black-boxtestingalludestoteststhatareconductedattheBlack-boxtestingalludestoteststhatareconductedatthe
softwareinterface.Ablack-boxtestexaminessome
fundamentalaspectofasystemwithlittleregardforthe
internallogicalstructureofthesoftware.
White-boxtestingofsoftwareispredicatedonclose
examinationofproceduraldetail.Logicalpathsthroughthe
softwareandcollaborationsbetweencomponentsare
testedbyexercisingspecificsetsofconditionsand/orloops.
Testing is done by two methods
1. Black box testing
2. White box testing
Black-boxtestingalludestoteststhatareconductedattheBlack-boxtestingalludestoteststhatareconductedatthe
softwareinterface.Ablack-boxtestexaminessome
fundamentalaspectofasystemwithlittleregardforthe
internallogicalstructureofthesoftware.
White-boxtestingofsoftwareispredicatedonclose
examinationofproceduraldetail.Logicalpathsthroughthe
softwareandcollaborationsbetweencomponentsare
testedbyexercisingspecificsetsofconditionsand/orloops.
BLACK BOX TESTING
•
Blackboxtestingisalsoknownas functional
testingandBehavioralTesting.
•
Itisasoftwaretestingtechniquewherebythe
internalworkingsoftheitembeingtestedarenot
knownbythetester.
Inblackboxtestingthetesteronlyknowsthe
•
Inblackboxtestingthetesteronlyknowsthe
inputsandwhattheexpectedoutcomesshouldbe
andnothowtheprogramarrivesatthoseoutputs.
•
Thetesterdoesnoteverexaminethe
programmingcodeanddoesnotneedanyfurther
knowledgeoftheprogramotherthanits
specification
•
Blackboxtestingisalsoknownas functional
testingandBehavioralTesting.
•
Itisasoftwaretestingtechniquewherebythe
internalworkingsoftheitembeingtestedarenot
knownbythetester.
Inblackboxtestingthetesteronlyknowsthe
•
Inblackboxtestingthetesteronlyknowsthe
inputsandwhattheexpectedoutcomesshouldbe
andnothowtheprogramarrivesatthoseoutputs.
•
Thetesterdoesnoteverexaminethe
programmingcodeanddoesnotneedanyfurther
knowledgeoftheprogramotherthanits
specification
This method attempts to find errors in the
following categories:
•
Incorrect or missing functions
•
Interface errors
•
Errors in data structures or external database
•
Errors in data structures or external database
access
•
Behavior or performance errors
•
Initialization and termination errors
following categories:
•
Incorrect or missing functions
•
Interface errors
•
Errors in data structures or external database
•
Errors in data structures or external database
access
•
Behavior or performance errors
•
Initialization and termination errors
Advantages
•
The test is unbiased because the designer and the tester are
independent of each other.
•
The tester does not need knowledge of any specific
programming languages.
•
The test is done from the point of view of the user, not the
designer.
•
Test cases can be designed as soon as the specifications are
complete. complete.
Disadvantages
•
The test can be redundant if the software designer has already
run a test case.
•
The test cases are difficult to design.
•
Testing every possible input stream is unrealistic because it
would take a inordinate amount of time; therefore, many
program paths will go untested.
•
The test is unbiased because the designer and the tester are
independent of each other.
•
The tester does not need knowledge of any specific
programming languages.
•
The test is done from the point of view of the user, not the
designer.
•
Test cases can be designed as soon as the specifications are
complete. complete.
Disadvantages
•
The test can be redundant if the software designer has already
run a test case.
•
The test cases are difficult to design.
•
Testing every possible input stream is unrealistic because it
would take a inordinate amount of time; therefore, many
program paths will go untested.
White -Box Testing
•
White-boxtesting,sometimescalledglass-boxtesting,isatest-case
designphilosophythatusesthecontrolstructuredescribedaspartof
component-leveldesigntoderivetestcases.
•
Usingwhite-boxtestingmethods,canderivetestcasesthat
(1)Guaranteethatallindependentpathswithinamodulehavebeen
exercisedatleastonce,exercisedatleastonce,
(2)Exercisealllogicaldecisionsontheirtrueandfalsesides,
(3)Executeallloopsattheirboundariesandwithintheiroperational
bounds
(4)Exerciseinternaldatastructurestoensuretheirvalidity
Thestructuraltestingisalsocalledaswhiteboxtesting
Instructuraltestingderivationoftestcasesisaccordingtoprogram
structure.
Thebasispathtestingtechniqueisoneofanumberoftechniquesfor
controlstructuretesting.
•
White-boxtesting,sometimescalledglass-boxtesting,isatest-case
designphilosophythatusesthecontrolstructuredescribedaspartof
component-leveldesigntoderivetestcases.
•
Usingwhite-boxtestingmethods,canderivetestcasesthat
(1)Guaranteethatallindependentpathswithinamodulehavebeen
exercisedatleastonce,exercisedatleastonce,
(2)Exercisealllogicaldecisionsontheirtrueandfalsesides,
(3)Executeallloopsattheirboundariesandwithintheiroperational
bounds
(4)Exerciseinternaldatastructurestoensuretheirvalidity
Thestructuraltestingisalsocalledaswhiteboxtesting
Instructuraltestingderivationoftestcasesisaccordingtoprogram
structure.
Thebasispathtestingtechniqueisoneofanumberoftechniquesfor
controlstructuretesting.
White box testing involves the testing of the software
code for the following:
•
Internal security holes
•
Broken or poorly structured paths in the coding
processes
•
The flow of specific inputs through the code
•
Expected output
•
The functionality of conditional loops
•
Testing of each statement, object and function on
an individual basis
code for the following:
•
Internal security holes
•
Broken or poorly structured paths in the coding
processes
•
The flow of specific inputs through the code
•
Expected output
•
The functionality of conditional loops
•
Testing of each statement, object and function on
an individual basis
Advantages
•
Testingcanbecommencedatanearlierstage.Oneneed
notwaitfortheGUItobeavailable.
•
Testingismorethorough,withthepossibilityofcovering
mostpaths.
Disadvantages
•
Sincetestscanbeverycomplex,highlyskilledresources
•
Sincetestscanbeverycomplex,highlyskilledresources
arerequired,withthoroughknowledgeofprogramming
andimplementation.
•
Testscriptmaintenancecanbeaburdenifthe
implementationchangestoofrequently.
•
Sincethismethodoftestingitcloselytiedwiththe
applicationbeingtesting,toolstocatertoeverykindof
implementation/platformmaynotbereadilyavailable.
•
Testingcanbecommencedatanearlierstage.Oneneed
notwaitfortheGUItobeavailable.
•
Testingismorethorough,withthepossibilityofcovering
mostpaths.
Disadvantages
•
Sincetestscanbeverycomplex,highlyskilledresources
•
Sincetestscanbeverycomplex,highlyskilledresources
arerequired,withthoroughknowledgeofprogramming
andimplementation.
•
Testscriptmaintenancecanbeaburdenifthe
implementationchangestoofrequently.
•
Sincethismethodoftestingitcloselytiedwiththe
applicationbeingtesting,toolstocatertoeverykindof
implementation/platformmaynotbereadilyavailable.
Difference between Black box and White box testing
White box testing
1.
Basis Path Testing
•
Flow Graph Notation
•
Independent Program Paths
•
Deriving Test Cases
Graph Matrices
•
Graph Matrices
2. Control Structure Testing
•
Condition Testing
•
Data Flow Testing
•
Loop Testing
1.
Basis Path Testing
•
Flow Graph Notation
•
Independent Program Paths
•
Deriving Test Cases
Graph Matrices
•
Graph Matrices
2. Control Structure Testing
•
Condition Testing
•
Data Flow Testing
•
Loop Testing
Flow Graph Notation
•
A simple notation for the representation of control flow,
called a flow graph is introduced bellow.
•
A simple notation for the representation of control flow,
called a flow graph is introduced bellow.
•
Eachcircle,calledaflowgraphnode,represents
oneormoreproceduralstatements.
•
Asequenceofprocessboxesandadecision
diamondcanmapintoasinglenode.
•
Thearrowsontheflowgraph,called edgesor
links,representflowofcontrolandareanalogouslinks,representflowofcontrolandareanalogous
toflowchartarrows.
•
Anedgemustterminateatanode,evenifthe
nodedoesnotrepresentanyprocedural
statements.
•
Areasboundedbyedgesandnodesarecalled
regions.
Eachcircle,calledaflowgraphnode,represents
oneormoreproceduralstatements.
•
Asequenceofprocessboxesandadecision
diamondcanmapintoasinglenode.
•
Thearrowsontheflowgraph,called edgesor
links,representflowofcontrolandareanalogouslinks,representflowofcontrolandareanalogous
toflowchartarrows.
•
Anedgemustterminateatanode,evenifthe
nodedoesnotrepresentanyprocedural
statements.
•
Areasboundedbyedgesandnodesarecalled
regions.
compoundconditionoccurswhenoneormoreBooleanoperators
(logicalOR,AND,NAND,NOR)ispresentinaconditionalstatement.
ReferringtoFiguretheprogramdesignlanguage(PDL)segment
translatesintotheflowgraphshown.Notethataseparatenodeis
createdforeachoftheconditionsaandbinthestatementIFaORb.
Eachnodethatcontainsaconditioniscalledapredicatenodeandis
characterizedbytwoormoreedgesemanatingfromit
(logicalOR,AND,NAND,NOR)ispresentinaconditionalstatement.
ReferringtoFiguretheprogramdesignlanguage(PDL)segment
translatesintotheflowgraphshown.Notethataseparatenodeis
createdforeachoftheconditionsaandbinthestatementIFaORb.
Eachnodethatcontainsaconditioniscalledapredicatenodeandis
characterizedbytwoormoreedgesemanatingfromit
Independent Program Paths
Cyclomatic Complexity
•
Cyclomaticcomplexityissoftwaremetricthat
providesaquantitativemeasureofthelogical
complexityofaprogram.
•
Whenusedinthecontextofthebasispathtesting
•
Whenusedinthecontextofthebasispathtesting
method,thevaluecomputedforcyclomatic
complexitydefinesthenumberofindependent
pathsinthebasissetofaprogramandprovides
uswithanupperboundforthenumberoftests
thatmustbeconductedtoensurethatall
statementshavebeenexecutedatleastonce
Cyclomatic Complexity
•
Cyclomaticcomplexityissoftwaremetricthat
providesaquantitativemeasureofthelogical
complexityofaprogram.
•
Whenusedinthecontextofthebasispathtesting
•
Whenusedinthecontextofthebasispathtesting
method,thevaluecomputedforcyclomatic
complexitydefinesthenumberofindependent
pathsinthebasissetofaprogramandprovides
uswithanupperboundforthenumberoftests
thatmustbeconductedtoensurethatall
statementshavebeenexecutedatleastonce
Independent Program Paths
Cyclomatic Complexity
Cyclomatic Complexity
Independent Program Paths
Cyclomatic Complexity
•
Cyclomaticcomplexityissoftwaremetricthat
providesaquantitativemeasureofthelogical
complexityofaprogram.
•
Whenusedinthecontextofthebasispathtesting
•
Whenusedinthecontextofthebasispathtesting
method,thevaluecomputedforcyclomatic
complexitydefinesthenumberofindependent
pathsinthebasissetofaprogramandprovides
uswithanupperboundforthenumberoftests
thatmustbeconductedtoensurethatall
statementshavebeenexecutedatleastonce
Cyclomatic Complexity
•
Cyclomaticcomplexityissoftwaremetricthat
providesaquantitativemeasureofthelogical
complexityofaprogram.
•
Whenusedinthecontextofthebasispathtesting
•
Whenusedinthecontextofthebasispathtesting
method,thevaluecomputedforcyclomatic
complexitydefinesthenumberofindependent
pathsinthebasissetofaprogramandprovides
uswithanupperboundforthenumberoftests
thatmustbeconductedtoensurethatall
statementshavebeenexecutedatleastonce
•
Anindependentpathisanypaththroughthe
programthatintroducesatleastonenewsetof
processingstatementsoranewcondition.When
statedintermsofaflowgraph,anindependent
pathmustmovealongatleastoneedgethathas
notbeentraversedbeforethepathisdefined.For
example,asetofindependentpathsfortheflowexample,asetofindependentpathsfortheflow
graphis
•
path 1: 1-11
•
path 2: 1-2-3-4-5-10-1-11
•
path 3: 1-2-3-6-8-9-10-1-11
•
path 4: 1-2-3-6-7-9-10-1-11
Anindependentpathisanypaththroughthe
programthatintroducesatleastonenewsetof
processingstatementsoranewcondition.When
statedintermsofaflowgraph,anindependent
pathmustmovealongatleastoneedgethathas
notbeentraversedbeforethepathisdefined.For
example,asetofindependentpathsfortheflowexample,asetofindependentpathsfortheflow
graphis
•
path 1: 1-11
•
path 2: 1-2-3-4-5-10-1-11
•
path 3: 1-2-3-6-8-9-10-1-11
•
path 4: 1-2-3-6-7-9-10-1-11
Cyclomaticcomplexityhasafoundationingraphtheoryand
providesuswithextremelyusefulsoftwaremetric.
Complexityiscomputedinoneofthreeways:
1.Thenumberofregionsoftheflowgraphcorrespondtothe
cyclomaticcomplexity.
2.Cyclomaticcomplexity,V(G),foraflowgraph,G,isdefinedas2.Cyclomaticcomplexity,V(G),foraflowgraph,G,isdefinedas
V(G)=E-N+2
whereEisthenumberofflowgraphedges,Nisthenumberof
flowgraphnodes.
3.Cyclomaticcomplexity,V(G),foraflowgraph,G,isalso
definedas
V(G)=P+1
wherePisthenumberofpredicatenodescontainedintheflow
graphG.
providesuswithextremelyusefulsoftwaremetric.
Complexityiscomputedinoneofthreeways:
1.Thenumberofregionsoftheflowgraphcorrespondtothe
cyclomaticcomplexity.
2.Cyclomaticcomplexity,V(G),foraflowgraph,G,isdefinedas2.Cyclomaticcomplexity,V(G),foraflowgraph,G,isdefinedas
V(G)=E-N+2
whereEisthenumberofflowgraphedges,Nisthenumberof
flowgraphnodes.
3.Cyclomaticcomplexity,V(G),foraflowgraph,G,isalso
definedas
V(G)=P+1
wherePisthenumberofpredicatenodescontainedintheflow
graphG.
1. The flow graph has four regions.
2. V(G) = 11 edges 9 nodes + 2 = 4.
3. V(G) = 3 predicate nodes + 1 = 4.
2. V(G) = 11 edges 9 nodes + 2 = 4.
3. V(G) = 3 predicate nodes + 1 = 4.
Deriving Test Cases
Thebasispathtestingmethodcanbeappliedtoaprocedural
designortosourcecode.Inthissection,wepresentbasispath
testingasaseriesofsteps.Theprocedureaverage,depictedin
PDLinfigurebelow,willbeusedasanexampletoillustrate
eachstepinthetestcasedesignmethod.Notethataverage,
althoughanextremelysimplealgorithm,containscompound
conditionsandloopsconditionsandloops
•
Usingthedesignorcodeasafoundation,drawa
correspondingflowgraph.
•
Determinethecyclomaticcomplexityoftheresultantflowgraph
•
Determineabasissetoflinearlyindependentpaths.
•
Preparetestcasesthatwillforceexecutionofeachpathinthe
basisset.
Thebasispathtestingmethodcanbeappliedtoaprocedural
designortosourcecode.Inthissection,wepresentbasispath
testingasaseriesofsteps.Theprocedureaverage,depictedin
PDLinfigurebelow,willbeusedasanexampletoillustrate
eachstepinthetestcasedesignmethod.Notethataverage,
althoughanextremelysimplealgorithm,containscompound
conditionsandloopsconditionsandloops
•
Usingthedesignorcodeasafoundation,drawa
correspondingflowgraph.
•
Determinethecyclomaticcomplexityoftheresultantflowgraph
•
Determineabasissetoflinearlyindependentpaths.
•
Preparetestcasesthatwillforceexecutionofeachpathinthe
basisset.
Graph Matrices
•
Todevelopasoftwaretoolthatassistsinbasispath
testing,adatastructure,calledagraphmatrix,canbe
quiteuseful.
•
Agraphmatrixisasquarematrixwhosesize(i.e.,
numberofrowsandcolumns)isequaltothenumberofnumberofrowsandcolumns)isequaltothenumberof
nodesontheflowgraph.
•
Eachrowandcolumncorrespondstoanidentifiednode,
andmatrixentriescorrespondtoconnections(anedge)
betweennodes.Asimpleexampleofaflowgraphandits
correspondinggraphmatrixisshowninfigure.
•
Todevelopasoftwaretoolthatassistsinbasispath
testing,adatastructure,calledagraphmatrix,canbe
quiteuseful.
•
Agraphmatrixisasquarematrixwhosesize(i.e.,
numberofrowsandcolumns)isequaltothenumberofnumberofrowsandcolumns)isequaltothenumberof
nodesontheflowgraph.
•
Eachrowandcolumncorrespondstoanidentifiednode,
andmatrixentriescorrespondtoconnections(anedge)
betweennodes.Asimpleexampleofaflowgraphandits
correspondinggraphmatrixisshowninfigure.
CONTROL STRUCTURE TESTING
•
Condition Testing
•
Data Flow Testing
•
Loop Testing
ThebasispathtestingtechniqueisoneofanumberofThebasispathtestingtechniqueisoneofanumberof
techniquesforcontrolstructuretesting.Althoughbasispath
testingissimpleandhighlyeffective,itisnotsufficientin
itself.Othervariationsoncontrolstructuretestinghelpsin
broadeningtestingcoverageandimprovequalityofwhite-
boxtesting.
•
Condition Testing
•
Data Flow Testing
•
Loop Testing
ThebasispathtestingtechniqueisoneofanumberofThebasispathtestingtechniqueisoneofanumberof
techniquesforcontrolstructuretesting.Althoughbasispath
testingissimpleandhighlyeffective,itisnotsufficientin
itself.Othervariationsoncontrolstructuretestinghelpsin
broadeningtestingcoverageandimprovequalityofwhite-
boxtesting.
Condition Testing
Conditiontestingisatest-casedesignmethodthat
exercisesthelogicalconditionscontainedinaprogram
module.AsimpleconditionisaBooleanvariableora
relationalexpression,possiblyprecededwithoneNOT(¬)
operator.Arelationalexpressiontakestheform
E1<relational-operator>E2
whereE1andE2arearithmeticexpressionsand
<relational-operator>isoneofthefollowing:<,≤,=,≠
(nonequality),>,or≥.Acompoundconditioniscomposed
oftwoormoresimpleconditions,Booleanoperators,and
parentheses.
Conditiontestingisatest-casedesignmethodthat
exercisesthelogicalconditionscontainedinaprogram
module.AsimpleconditionisaBooleanvariableora
relationalexpression,possiblyprecededwithoneNOT(¬)
operator.Arelationalexpressiontakestheform
E1<relational-operator>E2
whereE1andE2arearithmeticexpressionsand
<relational-operator>isoneofthefollowing:<,≤,=,≠
(nonequality),>,or≥.Acompoundconditioniscomposed
oftwoormoresimpleconditions,Booleanoperators,and
parentheses.
Data Flow Testing
The data flow testing method selects test paths of a
program according to the locations of definitions and uses
of variables in the program.
For a statement with S as its statement number,
DEF(S) = {X | statement S contains a definition of X}
USE(S) = {X | statement S contains a use of X}
The data flow testing method selects test paths of a
program according to the locations of definitions and uses
of variables in the program.
For a statement with S as its statement number,
DEF(S) = {X | statement S contains a definition of X}
USE(S) = {X | statement S contains a use of X}
Loop Testing
Looptestingisawhite-boxtestingtechniquethatfocuses
exclusivelyonthevalidityofloopconstructs.Fourdifferent
classesofloops[Bei90]canbedefined: simpleloops,
concatenatedloops,nestedloops,andunstructured
loopsasshowninFigure.
Looptestingisawhite-boxtestingtechniquethatfocuses
exclusivelyonthevalidityofloopconstructs.Fourdifferent
classesofloops[Bei90]canbedefined: simpleloops,
concatenatedloops,nestedloops,andunstructured
loopsasshowninFigure.
Classes of Loops
Simple loops. The following set of tests can be applied to
simple loops, where n is the maximum number of allowable
passes through the loop.
1. Skip the loop entirely. 1. Skip the loop entirely.
2. Only one pass through the loop.
3. Two passes through the loop.
4. m passes through the loop where m < n.
5. n -1, n, n + 1 passes through the loop.
Simple loops. The following set of tests can be applied to
simple loops, where n is the maximum number of allowable
passes through the loop.
1. Skip the loop entirely. 1. Skip the loop entirely.
2. Only one pass through the loop.
3. Two passes through the loop.
4. m passes through the loop where m < n.
5. n -1, n, n + 1 passes through the loop.
Nested loops
Beizer suggests an approach that will help to reduce the
number of tests:
1.Startattheinnermostloop.Setallotherloopsto
minimumvalues.
2.Conductsimplelooptestsfortheinnermostloopwhile2.Conductsimplelooptestsfortheinnermostloopwhile
holdingtheouterloopsattheirminimumiteration
parameter(e.g.,loopcounter)values.Addothertestsfor
out-of-rangeorexcludedvalues.
3.Workoutward,conductingtestsforthenextloop,but
keepingallotherouterloopsatminimumvaluesandother
nestedloopsto―typicalvalues.
4.Continueuntilallloopshavebeentested.
Beizer suggests an approach that will help to reduce the
number of tests:
1.Startattheinnermostloop.Setallotherloopsto
minimumvalues.
2.Conductsimplelooptestsfortheinnermostloopwhile2.Conductsimplelooptestsfortheinnermostloopwhile
holdingtheouterloopsattheirminimumiteration
parameter(e.g.,loopcounter)values.Addothertestsfor
out-of-rangeorexcludedvalues.
3.Workoutward,conductingtestsforthenextloop,but
keepingallotherouterloopsatminimumvaluesandother
nestedloopsto―typicalvalues.
4.Continueuntilallloopshavebeentested.
Concatenated loops
Concatenated loops can be tested using the approach
defined for simple loops, if each of the loops is independent
of the other.
Unstructured loops Unstructured loops
Classofloopsshouldberedesignedtoreflecttheuseof
thestructuredprogrammingconstructs.
Concatenated loops can be tested using the approach
defined for simple loops, if each of the loops is independent
of the other.
Unstructured loops Unstructured loops
Classofloopsshouldberedesignedtoreflecttheuseof
thestructuredprogrammingconstructs.
Concatenated loops
Concatenated loops can be tested using the approach
defined for simple loops, if each of the loops is independent
of the other.
Unstructured loops Unstructured loops
Classofloopsshouldberedesignedtoreflecttheuseof
thestructuredprogrammingconstructs.
Concatenated loops can be tested using the approach
defined for simple loops, if each of the loops is independent
of the other.
Unstructured loops Unstructured loops
Classofloopsshouldberedesignedtoreflecttheuseof
thestructuredprogrammingconstructs.
BLACK-BOX TESTING
Black-boxtesting,alsocalledbehaviouraltesting,focuses
onthefunctionalrequirementsofthesoftware.Thatis,
black-boxtestingtechniquesenabletoderivesetsofinput
conditionsthatwillfullyexerciseallfunctionalrequirements
foraprogram.
Black-boxtestingattemptstofinderrorsinthefollowing
categories:
(1)Incorrectormissingfunctions,
(2)Interfaceerrors
(3)Errorsindatastructuresorexternaldatabaseaccess,
(4)Behaviourorperformanceerrors
(5)Initializationandterminationerrors
Black-boxtesting,alsocalledbehaviouraltesting,focuses
onthefunctionalrequirementsofthesoftware.Thatis,
black-boxtestingtechniquesenabletoderivesetsofinput
conditionsthatwillfullyexerciseallfunctionalrequirements
foraprogram.
Black-boxtestingattemptstofinderrorsinthefollowing
categories:
(1)Incorrectormissingfunctions,
(2)Interfaceerrors
(3)Errorsindatastructuresorexternaldatabaseaccess,
(4)Behaviourorperformanceerrors
(5)Initializationandterminationerrors
Types of Black box testing:
•
Random Testing
•
Equivalence class partitioning
•
Boundary value analysis
•
Graph based testing
•
Orthogonal array testing
•
Random Testing
•
Equivalence class partitioning
•
Boundary value analysis
•
Graph based testing
•
Orthogonal array testing
Random Testing
Randomtestingisablack-boxsoftwaretestingtechnique
whereprogramsaretestedbygeneratingrandom,
independentinputs.
Resultsoftheoutputarecomparedagainstsoftware
specificationstoverifythatthetestoutputispassorfail.
•
It eliminates exhaustive testing.
•
It eliminates exhaustive testing.
•
Random testing can save time and effort.
Randomtestingisablack-boxsoftwaretestingtechnique
whereprogramsaretestedbygeneratingrandom,
independentinputs.
Resultsoftheoutputarecomparedagainstsoftware
specificationstoverifythatthetestoutputispassorfail.
•
It eliminates exhaustive testing.
•
It eliminates exhaustive testing.
•
Random testing can save time and effort.
Equivalence class partitioning
•
Equivalencepartitioning(EP)isaspecification-basedor
black-boxtechnique.
•
Itcanbeappliedatanyleveloftestingandisoftena
goodtechniquetousefirst.
•
Theideabehindthistechniqueistodivide(i.e.to
•
Theideabehindthistechniqueistodivide(i.e.to
partition)asetoftestconditionsintogroupsorsetsthat
canbeconsideredthesame(i.e.thesystemshould
handlethemequivalently),hence‘equivalence
partitioning’.
•
Equivalencepartitionsarealsoknownasequivalence
classes–thetwotermsmeanexactlythesamething.
•
Equivalencepartitioning(EP)isaspecification-basedor
black-boxtechnique.
•
Itcanbeappliedatanyleveloftestingandisoftena
goodtechniquetousefirst.
•
Theideabehindthistechniqueistodivide(i.e.to
•
Theideabehindthistechniqueistodivide(i.e.to
partition)asetoftestconditionsintogroupsorsetsthat
canbeconsideredthesame(i.e.thesystemshould
handlethemequivalently),hence‘equivalence
partitioning’.
•
Equivalencepartitionsarealsoknownasequivalence
classes–thetwotermsmeanexactlythesamething.
Equivalence class partitioning
Boundary Value Analysis
Agreaternumberoferrorsoccursattheboundariesofthe
inputdomainratherthaninthe“center.”Itisforthisreason
thatboundaryvalueanalysis(BVA)hasbeendevelopedas
atestingtechnique.Boundaryvalueanalysisleadstoa
selectionoftestcasesthatexerciseboundingvalues
Boundaryvalueanalysisisatest-casedesigntechnique
thatcomplementsequivalencepartitioning.Ratherthanthatcomplementsequivalencepartitioning.Ratherthan
selectinganyelementofanequivalenceclass,BVA
Leadstotheselectionoftestcasesatthe“edges”ofthe
class.
Agreaternumberoferrorsoccursattheboundariesofthe
inputdomainratherthaninthe“center.”Itisforthisreason
thatboundaryvalueanalysis(BVA)hasbeendevelopedas
atestingtechnique.Boundaryvalueanalysisleadstoa
selectionoftestcasesthatexerciseboundingvalues
Boundaryvalueanalysisisatest-casedesigntechnique
thatcomplementsequivalencepartitioning.Ratherthanthatcomplementsequivalencepartitioning.Ratherthan
selectinganyelementofanequivalenceclass,BVA
Leadstotheselectionoftestcasesatthe“edges”ofthe
class.
Graph-Based Testing Methods
Thefirststepinblack-boxtestingistounderstandthe
objectsthataremodelledinsoftwareandtherelationships
thatconnecttheseobjects
Thefirststepinblack-boxtestingistounderstandthe
objectsthataremodelledinsoftwareandtherelationships
thatconnecttheseobjects
The symbolic representation of a graph is shown
•
Nodesarerepresentedascirclesconnectedbylinksthat
takeanumberofdifferentforms.
•
Adirectedlink(representedbyanarrow)indicatesthata
relationshipmovesinonlyonedirection.
•
Abidirectionallink,alsocalledasymmetriclink,implies
•
Abidirectionallink,alsocalledasymmetriclink,implies
thattherelationshipappliesinbothdirections.
•
Parallellinksareusedwhenanumberofdifferent
relationshipsareestablishedbetweengraphnodes.
•
Nodesarerepresentedascirclesconnectedbylinksthat
takeanumberofdifferentforms.
•
Adirectedlink(representedbyanarrow)indicatesthata
relationshipmovesinonlyonedirection.
•
Abidirectionallink,alsocalledasymmetriclink,implies
•
Abidirectionallink,alsocalledasymmetriclink,implies
thattherelationshipappliesinbothdirections.
•
Parallellinksareusedwhenanumberofdifferent
relationshipsareestablishedbetweengraphnodes.
Orthogonal Array Testing
Orthogonalarraytestingcanbeappliedtoproblemsin
whichtheinputdomainisrelativelysmallbuttoolargeto
accommodateexhaustivetesting.Theorthogonalarray
testingmethodisparticularlyusefulinfindingregion
faults—anerrorcategoryassociatedwithfaultylogicwithin
asoftwarecomponent.
Orthogonalarraytestingcanbeappliedtoproblemsin
whichtheinputdomainisrelativelysmallbuttoolargeto
accommodateexhaustivetesting.Theorthogonalarray
testingmethodisparticularlyusefulinfindingregion
faults—anerrorcategoryassociatedwithfaultylogicwithin
asoftwarecomponent.
Regression testing
•
Regressiontestingisthereexecutionofsomesubsetoftests
thathavealreadybeenconductedtoensurethatchangeshave
notpropagatedunintendedsideeffects.
•
Regressiontestingistheactivitythathelpstoensurethat
changesdonotintroduceunintendedbehaviororadditional
errors.
•
Eachnewadditionorchangetobaselinedsoftwaremaycause
problemswithfunctionsthatpreviouslyworkedflawlesslyproblemswithfunctionsthatpreviouslyworkedflawlessly
•
Regressiontestingre-executesasmallsubsetofteststhat
havealreadybeenconducted
•
Ensuresthatchangeshavenotpropagatedunintendedside
effects
•
Helpstoensurethatchangesdonotintroduceunintended
behaviororadditionalerrors
•
Maybedonemanuallyorthroughtheuseofautomated
capture/playbacktools
•
Regressiontestingisthereexecutionofsomesubsetoftests
thathavealreadybeenconductedtoensurethatchangeshave
notpropagatedunintendedsideeffects.
•
Regressiontestingistheactivitythathelpstoensurethat
changesdonotintroduceunintendedbehaviororadditional
errors.
•
Eachnewadditionorchangetobaselinedsoftwaremaycause
problemswithfunctionsthatpreviouslyworkedflawlesslyproblemswithfunctionsthatpreviouslyworkedflawlessly
•
Regressiontestingre-executesasmallsubsetofteststhat
havealreadybeenconducted
•
Ensuresthatchangeshavenotpropagatedunintendedside
effects
•
Helpstoensurethatchangesdonotintroduceunintended
behaviororadditionalerrors
•
Maybedonemanuallyorthroughtheuseofautomated
capture/playbacktools
Regression testing
Regressiontestsuitecontainsthreedifferentclassesof
testcases
•
Arepresentativesampleofteststhatwillexerciseall
softwarefunctions
•
Additionalteststhatfocusonsoftwarefunctionsthatare
likelytobeaffectedbythechange
•
Teststhatfocusontheactualsoftwarecomponentsthat
havebeenchanged
•
Therefore,theregressiontestsuiteshouldbedesignedto
includeonlythoseteststhataddressoneormoreclasses
oferrorsineachofthemajorprogramfunctions.Itis
impracticalandinefficienttoreexecuteeverytestfor
everyprogramfunctiononceachangehasoccurred.
Regressiontestsuitecontainsthreedifferentclassesof
testcases
•
Arepresentativesampleofteststhatwillexerciseall
softwarefunctions
•
Additionalteststhatfocusonsoftwarefunctionsthatare
likelytobeaffectedbythechange
•
Teststhatfocusontheactualsoftwarecomponentsthat
havebeenchanged
•
Therefore,theregressiontestsuiteshouldbedesignedto
includeonlythoseteststhataddressoneormoreclasses
oferrorsineachofthemajorprogramfunctions.Itis
impracticalandinefficienttoreexecuteeverytestfor
everyprogramfunctiononceachangehasoccurred.
Unit Testing
•
Unittestingfocusesverificationeffortonthesmallestunit
ofsoftwaredesign—thesoftwarecomponentormodule.
Usingthecomponent-leveldesigndescriptionasaguide,
importantcontrolpathsaretestedtouncovererrorswithin
theboundaryofthemodule.
•
Theunittestfocusesontheinternalprocessinglogicand
datastructureswithintheboundariesofacomponent.
Thistypeoftestingcanbeconductedinparallelfor
multiplecomponents.
•
Unittestingfocusesverificationeffortonthesmallestunit
ofsoftwaredesign—thesoftwarecomponentormodule.
Usingthecomponent-leveldesigndescriptionasaguide,
importantcontrolpathsaretestedtouncovererrorswithin
theboundaryofthemodule.
•
Theunittestfocusesontheinternalprocessinglogicand
datastructureswithintheboundariesofacomponent.
Thistypeoftestingcanbeconductedinparallelfor
multiplecomponents.
Unit-test considerations
•
Themoduleinterfaceistestedtoensurethatinformation
properlyflowsintoandoutoftheprogramunitundertest.
•
Localdatastructuresareexaminedtoensurethatdatastored
temporarilymaintainsitsintegrityduringallstepsinan
algorithm‘sexecution.
•
Allindependentpathsthroughthecontrolstructureare
exercisedtoensurethatallstatementsinamodulehavebeenexercisedtoensurethatallstatementsinamodulehavebeen
executedatleastonce.
•
Boundaryconditionsaretestedtoensurethatthemodule
operatesproperlyatboundariesestablishedtolimitorrestrict
processing.Andfinally,allerror-handlingpathsaretested.
•
Selectivetestingofexecutionpathsisanessentialtaskduring
theunittest.Testcasesshouldbedesignedtouncovererrors
duetoerroneouscomputations,incorrectcomparisons,or
impropercontrolflow.
•
Themoduleinterfaceistestedtoensurethatinformation
properlyflowsintoandoutoftheprogramunitundertest.
•
Localdatastructuresareexaminedtoensurethatdatastored
temporarilymaintainsitsintegrityduringallstepsinan
algorithm‘sexecution.
•
Allindependentpathsthroughthecontrolstructureare
exercisedtoensurethatallstatementsinamodulehavebeenexercisedtoensurethatallstatementsinamodulehavebeen
executedatleastonce.
•
Boundaryconditionsaretestedtoensurethatthemodule
operatesproperlyatboundariesestablishedtolimitorrestrict
processing.Andfinally,allerror-handlingpathsaretested.
•
Selectivetestingofexecutionpathsisanessentialtaskduring
theunittest.Testcasesshouldbedesignedtouncovererrors
duetoerroneouscomputations,incorrectcomparisons,or
impropercontrolflow.
Unit-test procedures
•
Unittestingisnormallyconsideredasanadjuncttothecodingstep.
•
Thedesignofunittestscanoccurbeforecodingbeginsorafter
sourcecodehasbeengenerated.
•
Areviewofdesigninformationprovidesguidanceforestablishingtest
casesthatarelikelytouncovererrors.
•
Acomponentisnotastand-aloneprogram;driverand/orstub
softwaremustoftenbedevelopedforeachunittest.
•
TheunittestenvironmentisillustratedinFigure.Inmostapplications
adriverisnothingmorethana―mainprogram‖thatacceptstestadriverisnothingmorethana―mainprogram‖thatacceptstest
casedata,passessuchdatatothecomponent(tobetested),and
printsrelevantresults.
•
Astubor―dummysubprogram‖usesthesubordinatemodule‘s
interface,maydominimaldatamanipulation,printsverificationof
entry,andreturnscontroltothemoduleundergoingtesting.
•
Unittestingissimplifiedwhenacomponentwithhighcohesionis
designed.
•
Whenonlyonefunctionisaddressedbyacomponent,thenumberof
testcasesisreducedanderrorscanbemoreeasilypredictedand
uncovered.
•
Unittestingisnormallyconsideredasanadjuncttothecodingstep.
•
Thedesignofunittestscanoccurbeforecodingbeginsorafter
sourcecodehasbeengenerated.
•
Areviewofdesigninformationprovidesguidanceforestablishingtest
casesthatarelikelytouncovererrors.
•
Acomponentisnotastand-aloneprogram;driverand/orstub
softwaremustoftenbedevelopedforeachunittest.
•
TheunittestenvironmentisillustratedinFigure.Inmostapplications
adriverisnothingmorethana―mainprogram‖thatacceptstestadriverisnothingmorethana―mainprogram‖thatacceptstest
casedata,passessuchdatatothecomponent(tobetested),and
printsrelevantresults.
•
Astubor―dummysubprogram‖usesthesubordinatemodule‘s
interface,maydominimaldatamanipulation,printsverificationof
entry,andreturnscontroltothemoduleundergoingtesting.
•
Unittestingissimplifiedwhenacomponentwithhighcohesionis
designed.
•
Whenonlyonefunctionisaddressedbyacomponent,thenumberof
testcasesisreducedanderrorscanbemoreeasilypredictedand
uncovered.
Integration Testing
•
Integrationtestingisasystematictechniqueforconstructing
thesoftwarearchitecturewhileatthesametimeconducting
teststouncovererrorsassociatedwithinterfacing.The
objectiveistotakeunit-testedcomponentsandbuildaprogram
structurethathasbeendictatedbydesign.
•
Thereisoftenatendencytoattemptnonincremental
integration;thatis,toconstructtheprogramusinga―bigbang
approach.Allcomponentsarecombinedinadvance.Theentireapproach.Allcomponentsarecombinedinadvance.Theentire
programistestedasawhole.Asetoferrorsisencountered.
Correctionisdifficultbecauseisolationofcausesis
complicatedbythevastexpanseoftheentireprogram.Once
theseerrorsarecorrected,newonesappearandtheprocess
continuesinaseeminglyendlessloop.
•
Theprogramisconstructedandtestedinsmallincrements,
whereerrorsareeasiertoisolateandcorrect;interfacesare
morelikelytobetestedcompletely;andasystematictest
approachmaybeapplied.
•
Integrationtestingisasystematictechniqueforconstructing
thesoftwarearchitecturewhileatthesametimeconducting
teststouncovererrorsassociatedwithinterfacing.The
objectiveistotakeunit-testedcomponentsandbuildaprogram
structurethathasbeendictatedbydesign.
•
Thereisoftenatendencytoattemptnonincremental
integration;thatis,toconstructtheprogramusinga―bigbang
approach.Allcomponentsarecombinedinadvance.Theentireapproach.Allcomponentsarecombinedinadvance.Theentire
programistestedasawhole.Asetoferrorsisencountered.
Correctionisdifficultbecauseisolationofcausesis
complicatedbythevastexpanseoftheentireprogram.Once
theseerrorsarecorrected,newonesappearandtheprocess
continuesinaseeminglyendlessloop.
•
Theprogramisconstructedandtestedinsmallincrements,
whereerrorsareeasiertoisolateandcorrect;interfacesare
morelikelytobetestedcompletely;andasystematictest
approachmaybeapplied.
Top-down integration
•
Top-downintegrationtestingisanincrementalapproach
toconstructionofthesoftwarearchitecture.
•
Modulesareintegratedbymovingdownwardthroughthe
controlhierarchy,beginningwiththemaincontrolmodule
(mainprogram).
•
Modulessubordinate(andultimatelysubordinate)tothe
maincontrolmoduleareincorporatedintothestructurein
eitheradepth-firstorbreadth-firstmanner.
•
Depth-firstintegrationintegratesallcomponentsona
majorcontrolpathoftheprogramstructure.
•
Selectionofamajorpathisarbitraryanddependson
application-specificcharacteristics
•
Top-downintegrationtestingisanincrementalapproach
toconstructionofthesoftwarearchitecture.
•
Modulesareintegratedbymovingdownwardthroughthe
controlhierarchy,beginningwiththemaincontrolmodule
(mainprogram).
•
Modulessubordinate(andultimatelysubordinate)tothe
maincontrolmoduleareincorporatedintothestructurein
eitheradepth-firstorbreadth-firstmanner.
•
Depth-firstintegrationintegratesallcomponentsona
majorcontrolpathoftheprogramstructure.
•
Selectionofamajorpathisarbitraryanddependson
application-specificcharacteristics
•
Breadth-first integration incorporates all components
directly subordinate at each level, moving across the
structure horizontally.
•
The integration process is performed in a series of five
steps:
Breadth-first integration incorporates all components
directly subordinate at each level, moving across the
structure horizontally.
•
The integration process is performed in a series of five
steps:
Top-down integration
1.Themaincontrolmoduleisusedasatestdriverand
stubsaresubstitutedforallcomponentsdirectly
subordinatetothemaincontrolmodule.
2.Dependingontheintegrationapproachselected(i.e.,
depthorbreadthfirst),subordinatestubsarereplacedone
atatimewithactualcomponents.
3.Testsareconductedaseachcomponentisintegrated.
4.Oncompletionofeachsetoftests,anotherstubis
replacedwiththerealcomponent.
5.Regressiontestingmaybeconductedtoensurethatnew
errorshavenotbeenintroduced.
Thetop-downintegrationstrategyverifiesmajorcontrolor
decisionpointsearlyinthetestprocess.
1.Themaincontrolmoduleisusedasatestdriverand
stubsaresubstitutedforallcomponentsdirectly
subordinatetothemaincontrolmodule.
2.Dependingontheintegrationapproachselected(i.e.,
depthorbreadthfirst),subordinatestubsarereplacedone
atatimewithactualcomponents.
3.Testsareconductedaseachcomponentisintegrated.
4.Oncompletionofeachsetoftests,anotherstubis
replacedwiththerealcomponent.
5.Regressiontestingmaybeconductedtoensurethatnew
errorshavenotbeenintroduced.
Thetop-downintegrationstrategyverifiesmajorcontrolor
decisionpointsearlyinthetestprocess.
Bottom-up integration:
Bottom-upintegrationtesting,asitsnameimplies,begins
constructionandtestingwithatomicmodules(i.e.,components
atthelowestlevelsintheprogramstructure).Because
componentsareintegratedfromthebottomup,thefunctionality
providedbycomponentssubordinatetoagivenlevelisalways
availableandtheneedforstubsiseliminated.
Abottom-upintegrationstrategymaybeimplementedwiththe
followingsteps:followingsteps:
1.Low-levelcomponentsarecombinedintoclusters(sometimes
calledbuilds)thatperformaspecificsoftwaresubfunction.
2.Adriver(acontrolprogramfortesting)iswrittentocoordinate
testcaseinputandoutput.
3.Theclusteristested.
4.Driversareremovedandclustersarecombinedmoving
upwardintheprogramstructure.
Bottom-upintegrationtesting,asitsnameimplies,begins
constructionandtestingwithatomicmodules(i.e.,components
atthelowestlevelsintheprogramstructure).Because
componentsareintegratedfromthebottomup,thefunctionality
providedbycomponentssubordinatetoagivenlevelisalways
availableandtheneedforstubsiseliminated.
Abottom-upintegrationstrategymaybeimplementedwiththe
followingsteps:followingsteps:
1.Low-levelcomponentsarecombinedintoclusters(sometimes
calledbuilds)thatperformaspecificsoftwaresubfunction.
2.Adriver(acontrolprogramfortesting)iswrittentocoordinate
testcaseinputandoutput.
3.Theclusteristested.
4.Driversareremovedandclustersarecombinedmoving
upwardintheprogramstructure.
Integration test approaches
There are four types of integration testing approaches.
Those approaches are the following
1. Big-Bang Integration Testing
Itisthesimplestintegrationtestingapproach,whereallthe
modulesarecombiningandverifyingthefunctionalityaftermodulesarecombiningandverifyingthefunctionalityafter
thecompletionofindividualmoduletesting.Insimple
words,allthemodulesofthesystemaresimplyput
togetherandtested.Thisapproachispracticableonlyfor
verysmallsystems.Ifonceanerrorisfoundduringthe
integrationtesting,itisverydifficulttolocalizetheerroras
theerrormaypotentiallybelongtoanyofthemodules
beingintegrated.So,debuggingerrorsreportedduringbig
bangintegrationtestingareveryexpensivetofix.
There are four types of integration testing approaches.
Those approaches are the following
1. Big-Bang Integration Testing
Itisthesimplestintegrationtestingapproach,whereallthe
modulesarecombiningandverifyingthefunctionalityaftermodulesarecombiningandverifyingthefunctionalityafter
thecompletionofindividualmoduletesting.Insimple
words,allthemodulesofthesystemaresimplyput
togetherandtested.Thisapproachispracticableonlyfor
verysmallsystems.Ifonceanerrorisfoundduringthe
integrationtesting,itisverydifficulttolocalizetheerroras
theerrormaypotentiallybelongtoanyofthemodules
beingintegrated.So,debuggingerrorsreportedduringbig
bangintegrationtestingareveryexpensivetofix.
Bottom-Up Integration Testing
Inbottom-uptesting,eachmoduleatlowerlevelsistestedwith
highermodulesuntilallmodulesaretested.Theprimary
purposeofthisintegrationtestingis,eachsubsystemistotest
theinterfacesamongvariousmodulesmakingupthe
subsystem.Thisintegrationtestingusestestdriverstodriveand
passappropriatedatatothelowerlevelmodules.
Top-Down Integration Testing
Top-downintegrationtestingtechniqueusedinordertosimulate
thebehaviourofthelower-levelmodulesthatarenotyet
integrated.Inthisintegrationtesting,testingtakesplacefromtop
tobottom.Firsthigh-levelmodulesaretestedandthenlow-level
modulesandfinallyintegratingthelow-levelmodulestoahigh
leveltoensurethesystemisworkingasintended
Inbottom-uptesting,eachmoduleatlowerlevelsistestedwith
highermodulesuntilallmodulesaretested.Theprimary
purposeofthisintegrationtestingis,eachsubsystemistotest
theinterfacesamongvariousmodulesmakingupthe
subsystem.Thisintegrationtestingusestestdriverstodriveand
passappropriatedatatothelowerlevelmodules.
Top-Down Integration Testing
Top-downintegrationtestingtechniqueusedinordertosimulate
thebehaviourofthelower-levelmodulesthatarenotyet
integrated.Inthisintegrationtesting,testingtakesplacefromtop
tobottom.Firsthigh-levelmodulesaretestedandthenlow-level
modulesandfinallyintegratingthelow-levelmodulestoahigh
leveltoensurethesystemisworkingasintended
Mixed Integration Testing
Amixedintegrationtestingisalsocalledsandwiched
integrationtesting.Amixedintegrationtestingfollowsa
combinationoftopdownandbottom-uptesting
approaches.Intop-downapproach,testingcanstartonly
afterthetop-levelmodulehavebeencodedandunittested.afterthetop-levelmodulehavebeencodedandunittested.
Inbottom-upapproach,testingcanstartonlyafterthe
bottomlevelmodulesareready.Thissandwichormixed
approachovercomesthisshortcomingofthetop-downand
bottom-upapproaches.Amixedintegrationtestingisalso
calledsandwichedintegrationtesting.
Amixedintegrationtestingisalsocalledsandwiched
integrationtesting.Amixedintegrationtestingfollowsa
combinationoftopdownandbottom-uptesting
approaches.Intop-downapproach,testingcanstartonly
afterthetop-levelmodulehavebeencodedandunittested.afterthetop-levelmodulehavebeencodedandunittested.
Inbottom-upapproach,testingcanstartonlyafterthe
bottomlevelmodulesareready.Thissandwichormixed
approachovercomesthisshortcomingofthetop-downand
bottom-upapproaches.Amixedintegrationtestingisalso
calledsandwichedintegrationtesting.
VALIDATION TESTING
•
Validationtestingbeginsattheculminationofintegration
testing,whenindividualcomponentshavebeenexercised,
thesoftwareiscompletelyassembledasapackage,and
interfacingerrorshavebeenuncoveredandcorrected.
•
Atthevalidationorsystemlevel,thedistinctionbetween
conventionalsoftware,object-orientedsoftware,and
WebAppsdisappears.Testingfocusesonuser-visible
actionsanduser-recognizableoutputfromthesystem.
•
IfaSoftwareRequirementsSpecificationhasbeen
developed,itdescribesalluser-visibleattributesofthe
softwareandcontainsaValidationCriteriasectionthat
formsthebasisforavalidation-testingapproach
•
Validationtestingbeginsattheculminationofintegration
testing,whenindividualcomponentshavebeenexercised,
thesoftwareiscompletelyassembledasapackage,and
interfacingerrorshavebeenuncoveredandcorrected.
•
Atthevalidationorsystemlevel,thedistinctionbetween
conventionalsoftware,object-orientedsoftware,and
WebAppsdisappears.Testingfocusesonuser-visible
actionsanduser-recognizableoutputfromthesystem.
•
IfaSoftwareRequirementsSpecificationhasbeen
developed,itdescribesalluser-visibleattributesofthe
softwareandcontainsaValidationCriteriasectionthat
formsthebasisforavalidation-testingapproach
Software validation is achieved through a series of tests that
demonstrate conformity with requirements.
•
Atestplanoutlinestheclassesofteststobeconducted,anda
testproceduredefinesspecifictestcasesthataredesignedto
ensurethatallfunctionalrequirementsaresatisfied,all
behavioralcharacteristicsareachieved,allcontentisaccurate
andproperlypresented,allperformancerequirementsare
attained,documentationiscorrect,andusabilityandotherattained,documentationiscorrect,andusabilityandother
requirementsaremet(e.g.,trans-portability,compatibility,error
recovery,maintainability).
•
Aftereachvalidationtestcasehasbeenconducted,oneoftwo
possibleconditionsexists:(1)Thefunctionorperformance
characteristicconformstospecificationandisacceptedor(2)a
deviationfromspecificationisuncoveredandadeficiencylistis
created.Deviationsorerrorsdiscoveredatthisstageinaproject
canrarelybecorrectedpriortoscheduleddelivery.
demonstrate conformity with requirements.
•
Atestplanoutlinestheclassesofteststobeconducted,anda
testproceduredefinesspecifictestcasesthataredesignedto
ensurethatallfunctionalrequirementsaresatisfied,all
behavioralcharacteristicsareachieved,allcontentisaccurate
andproperlypresented,allperformancerequirementsare
attained,documentationiscorrect,andusabilityandotherattained,documentationiscorrect,andusabilityandother
requirementsaremet(e.g.,trans-portability,compatibility,error
recovery,maintainability).
•
Aftereachvalidationtestcasehasbeenconducted,oneoftwo
possibleconditionsexists:(1)Thefunctionorperformance
characteristicconformstospecificationandisacceptedor(2)a
deviationfromspecificationisuncoveredandadeficiencylistis
created.Deviationsorerrorsdiscoveredatthisstageinaproject
canrarelybecorrectedpriortoscheduleddelivery.
Configuration Review
Animportantelementofthevalidationprocessisa
configurationreview.Theintentofthereviewistoensurethat
allelementsofthesoftwareconfigurationhavebeenproperly
developed,arecataloged,andhavethenecessarydetailto
bolsterthesupportactivities.Theconfigurationreview,
sometimescalledanaudit.
AlphaandBetaTestingAlphaandBetaTesting
Mostsoftwareproductbuildersuseaprocesscalledalphaand
betatestingtouncovererrorsthatonlytheenduserseemsable
tofind.
AlphaTesting
Thealphatestisconductedatthedeveloper‘ssitebya
representativegroupofendusers.Thesoftwareisusedina
naturalsettingwiththedeveloper―lookingovertheshoulder‖of
theusersandrecordingerrorsandusageproblems.Alphatests
areconductedinacontrolledenvironment.
Animportantelementofthevalidationprocessisa
configurationreview.Theintentofthereviewistoensurethat
allelementsofthesoftwareconfigurationhavebeenproperly
developed,arecataloged,andhavethenecessarydetailto
bolsterthesupportactivities.Theconfigurationreview,
sometimescalledanaudit.
AlphaandBetaTestingAlphaandBetaTesting
Mostsoftwareproductbuildersuseaprocesscalledalphaand
betatestingtouncovererrorsthatonlytheenduserseemsable
tofind.
AlphaTesting
Thealphatestisconductedatthedeveloper‘ssitebya
representativegroupofendusers.Thesoftwareisusedina
naturalsettingwiththedeveloper―lookingovertheshoulder‖of
theusersandrecordingerrorsandusageproblems.Alphatests
areconductedinacontrolledenvironment.
Beta Testing
•
Thebetatestisconductedatoneormoreend-usersites.
Unlikealphatesting,thedevelopergenerallyisnotpresent.
Therefore,thebetatestisa“live”applicationofthesoftware
inanenvironmentthatcannotbecontrolledbythedeveloper.
Thecustomerrecordsallproblems(realorimagined)thatare
encounteredduringbetatestingandreportsthesetotheencounteredduringbetatestingandreportsthesetothe
developeratregularintervals.Asaresultofproblemsreported
duringbetatests,youmakemodificationsandthenpreparefor
releaseofthesoftwareproducttotheentirecustomerbase.
•
Avariationonbetatesting,called customeracceptance
testing,issometimesperformedwhencustomsoftwareis
deliveredtoacustomerundercontract.Thecustomerperforms
aseriesofspecifictestsinanattempttouncovererrorsbefore
acceptingthesoftwarefromthedeveloper
•
Thebetatestisconductedatoneormoreend-usersites.
Unlikealphatesting,thedevelopergenerallyisnotpresent.
Therefore,thebetatestisa“live”applicationofthesoftware
inanenvironmentthatcannotbecontrolledbythedeveloper.
Thecustomerrecordsallproblems(realorimagined)thatare
encounteredduringbetatestingandreportsthesetotheencounteredduringbetatestingandreportsthesetothe
developeratregularintervals.Asaresultofproblemsreported
duringbetatests,youmakemodificationsandthenpreparefor
releaseofthesoftwareproducttotheentirecustomerbase.
•
Avariationonbetatesting,called customeracceptance
testing,issometimesperformedwhencustomsoftwareis
deliveredtoacustomerundercontract.Thecustomerperforms
aseriesofspecifictestsinanattempttouncovererrorsbefore
acceptingthesoftwarefromthedeveloper
SYSTEM TESTING
System testing is actually a series of different tests whose
primary purpose is to fully exercise the computer-based
system.
Various types of system tests are
•
Recovery Testing
•
Security Testing
•
Stress Testing
•
Performance Testing
•
Deployment Testing
System testing is actually a series of different tests whose
primary purpose is to fully exercise the computer-based
system.
Various types of system tests are
•
Recovery Testing
•
Security Testing
•
Stress Testing
•
Performance Testing
•
Deployment Testing
Recovery Testing
Recoverytestingisasystemtestthatforcesthesoftwaretofail
inavarietyofwaysandverifiesthatrecoveryisproperly
performed.Ifrecoveryisautomatic(performedbythesystem
itself),reinitialization,checkpointingmechanisms,datarecovery,
andrestartareevaluatedforcorrectness.
SecurityTestingSecurityTesting
•
Securitytestingattemptstoverifythatprotectionmechanisms
builtintoasystem,infact,protectitfromimproperpenetration.
•
Duringsecuritytesting,thetesterplaystherole(s)ofthe
individualwhodesirestopenetratethesystem.
•
Theroleofthesystemdesigneristomakepenetrationcost
morethanthevalueoftheinformationthatwillbeobtained.
Recoverytestingisasystemtestthatforcesthesoftwaretofail
inavarietyofwaysandverifiesthatrecoveryisproperly
performed.Ifrecoveryisautomatic(performedbythesystem
itself),reinitialization,checkpointingmechanisms,datarecovery,
andrestartareevaluatedforcorrectness.
SecurityTestingSecurityTesting
•
Securitytestingattemptstoverifythatprotectionmechanisms
builtintoasystem,infact,protectitfromimproperpenetration.
•
Duringsecuritytesting,thetesterplaystherole(s)ofthe
individualwhodesirestopenetratethesystem.
•
Theroleofthesystemdesigneristomakepenetrationcost
morethanthevalueoftheinformationthatwillbeobtained.
Stress Testing
•
Stresstestsaredesignedtoconfrontprogramswithabnormal
situations.
•
Stresstestingexecutesasysteminamannerthatdemands
resourcesinabnormalquantity,frequency,orvolume.
•
Avariationofstresstestingisatechniquecalledsensitivity
testing.
•
Sensitivitytestingattemptstouncoverdatacombinationswithin
validinputclassesthatmaycauseinstabilityorimproper
processing.processing.
PerformanceTesting
•
Performancetestingisdesignedtotesttherun-time
performanceofsoftwarewithinthecontextofanintegrated
system.
•
Performancetestsareoftencoupledwithstresstestingand
usuallyrequirebothhardwareandsoftwareinstrumentation.
Thatis,itisoftennecessarytomeasureresourceutilization
•
Stresstestsaredesignedtoconfrontprogramswithabnormal
situations.
•
Stresstestingexecutesasysteminamannerthatdemands
resourcesinabnormalquantity,frequency,orvolume.
•
Avariationofstresstestingisatechniquecalledsensitivity
testing.
•
Sensitivitytestingattemptstouncoverdatacombinationswithin
validinputclassesthatmaycauseinstabilityorimproper
processing.processing.
PerformanceTesting
•
Performancetestingisdesignedtotesttherun-time
performanceofsoftwarewithinthecontextofanintegrated
system.
•
Performancetestsareoftencoupledwithstresstestingand
usuallyrequirebothhardwareandsoftwareinstrumentation.
Thatis,itisoftennecessarytomeasureresourceutilization
DeploymentTesting
Deploymenttesting,sometimescalledconfiguration
testing,exercisesthesoftwareineachenvironmentin
whichitistooperate.Inaddition,deploymenttesting
examinesallinstallationproceduresandspecialized
installationsoftware(e.g.,―installers‖)thatwillbeusedby
customers,andalldocumentationthatwillbeusedtocustomers,andalldocumentationthatwillbeusedto
introducethesoftwaretoendusers.
DEBUGGING
Debuggingoccursasaconsequenceofsuccessfultesting.
Thatis,whenatestcaseuncoversanerror,debuggingis
theprocessthatresultsintheremovaloftheerror.
Deploymenttesting,sometimescalledconfiguration
testing,exercisesthesoftwareineachenvironmentin
whichitistooperate.Inaddition,deploymenttesting
examinesallinstallationproceduresandspecialized
installationsoftware(e.g.,―installers‖)thatwillbeusedby
customers,andalldocumentationthatwillbeusedtocustomers,andalldocumentationthatwillbeusedto
introducethesoftwaretoendusers.
DEBUGGING
Debuggingoccursasaconsequenceofsuccessfultesting.
Thatis,whenatestcaseuncoversanerror,debuggingis
theprocessthatresultsintheremovaloftheerror.
The Debugging process
Thedebuggingprocessbeginswiththeexecutionofatest
case.Resultsareassessedandalackofcorrespondence
betweenexpectedandactualperformanceisencountered.
ThedebuggingprocesswillusuallyhaveoneoftwoThedebuggingprocesswillusuallyhaveoneoftwo
outcomes:
(1)Thecausewillbefoundandcorrectedor
(2)Thecausewillnotbefound.Inthelattercase,the
personperformingdebuggingmaysuspectacause,design
atestcasetohelpvalidatethatsuspicion,andworktoward
errorcorrectioninaniterativefashion
Thedebuggingprocessbeginswiththeexecutionofatest
case.Resultsareassessedandalackofcorrespondence
betweenexpectedandactualperformanceisencountered.
ThedebuggingprocesswillusuallyhaveoneoftwoThedebuggingprocesswillusuallyhaveoneoftwo
outcomes:
(1)Thecausewillbefoundandcorrectedor
(2)Thecausewillnotbefound.Inthelattercase,the
personperformingdebuggingmaysuspectacause,design
atestcasetohelpvalidatethatsuspicion,andworktoward
errorcorrectioninaniterativefashion
Why is debugging so difficult?
1.Thesymptomandthecausemaybegeographicallyremote.
2.Thesymptommaydisappear(temporarily)whenanothererror
iscorrected.
3.Thesymptommayactuallybecausedbynonerrors(e.g.,
round-offinaccuracies).
4.Thesymptommaybecausedbyhumanerrorthatisnoteasily
traced.
5.Thesymptommaybearesultoftimingproblems,ratherthan5.Thesymptommaybearesultoftimingproblems,ratherthan
processingproblems.
6.Itmaybedifficulttoaccuratelyreproduceinputconditions
(e.g.,areal-timeapplicationinwhichinputorderingis
indeterminate).
7.Thesymptommaybeintermittent.Thisisparticularlycommon
inembeddedsystemsthatcouplehardwareandsoftware
inextricably.
8.Thesymptommaybeduetocausesthataredistributed
acrossanumberoftasksrunningondifferentprocessors.
1.Thesymptomandthecausemaybegeographicallyremote.
2.Thesymptommaydisappear(temporarily)whenanothererror
iscorrected.
3.Thesymptommayactuallybecausedbynonerrors(e.g.,
round-offinaccuracies).
4.Thesymptommaybecausedbyhumanerrorthatisnoteasily
traced.
5.Thesymptommaybearesultoftimingproblems,ratherthan5.Thesymptommaybearesultoftimingproblems,ratherthan
processingproblems.
6.Itmaybedifficulttoaccuratelyreproduceinputconditions
(e.g.,areal-timeapplicationinwhichinputorderingis
indeterminate).
7.Thesymptommaybeintermittent.Thisisparticularlycommon
inembeddedsystemsthatcouplehardwareandsoftware
inextricably.
8.Thesymptommaybeduetocausesthataredistributed
acrossanumberoftasksrunningondifferentprocessors.
Debugging Strategies
In general, three debugging strategies have been proposed
(1) brute force,
(2) backtracking, and
(3) cause elimination.
•
Each of these strategies can be conducted manually, but
modern debugging tools can make the process much modern debugging tools can make the process much
more effective.
Debugging tactics.
•
The brute force category of debugging is probably the
most common and least efficient method for isolating the
cause of a software error.
In general, three debugging strategies have been proposed
(1) brute force,
(2) backtracking, and
(3) cause elimination.
•
Each of these strategies can be conducted manually, but
modern debugging tools can make the process much modern debugging tools can make the process much
more effective.
Debugging tactics.
•
The brute force category of debugging is probably the
most common and least efficient method for isolating the
cause of a software error.
Backtrackingisafairlycommondebuggingapproachthatcan
beusedsuccessfullyinsmallprograms.Beginningatthesite
whereasymptomhasbeenuncovered,thesourcecodeis
tracedbackward(manually)untilthecauseisfound.
Unfortunately,asthenumberofsourcelinesincreases,the
numberofpotentialbackwardpathsmaybecomeunmanageably
large.
Thethirdapproachtodebugging—causeelimination—isThethirdapproachtodebugging—causeelimination—is
manifestedbyinductionordeductionandintroducestheconcept
ofbinarypartitioning.
Automateddebugging:
•
Eachofthesedebuggingapproachescanbesupplemented
withdebuggingtools.
•
Awidevarietyofdebuggingcompilers,dynamicdebugging
aids(―tracers‖),automatictest-casegenerators,andcross-
referencemappingtoolsareavailable.
beusedsuccessfullyinsmallprograms.Beginningatthesite
whereasymptomhasbeenuncovered,thesourcecodeis
tracedbackward(manually)untilthecauseisfound.
Unfortunately,asthenumberofsourcelinesincreases,the
numberofpotentialbackwardpathsmaybecomeunmanageably
large.
Thethirdapproachtodebugging—causeelimination—isThethirdapproachtodebugging—causeelimination—is
manifestedbyinductionordeductionandintroducestheconcept
ofbinarypartitioning.
Automateddebugging:
•
Eachofthesedebuggingapproachescanbesupplemented
withdebuggingtools.
•
Awidevarietyofdebuggingcompilers,dynamicdebugging
aids(―tracers‖),automatictest-casegenerators,andcross-
referencemappingtoolsareavailable.
Correcting the Error
Once a bug has been found, it must be corrected.
Van Vleck suggests three simple questions that you should
ask before making the ―correction‖ that removes the
cause of a bug:
•
Is the cause of the bug reproduced in another part of the
•
Is the cause of the bug reproduced in another part of the
program?
•
What ―next bug‖ might be introduced by the fix I‘m about
to make?
•
What could we have done to prevent this bug in the first
place?
Once a bug has been found, it must be corrected.
Van Vleck suggests three simple questions that you should
ask before making the ―correction‖ that removes the
cause of a bug:
•
Is the cause of the bug reproduced in another part of the
•
Is the cause of the bug reproduced in another part of the
program?
•
What ―next bug‖ might be introduced by the fix I‘m about
to make?
•
What could we have done to prevent this bug in the first
place?
Correcting the Error
Once a bug has been found, it must be corrected.
Van Vleck suggests three simple questions that you should
ask before making the ―correction‖ that removes the
cause of a bug:
•
Is the cause of the bug reproduced in another part of the
•
Is the cause of the bug reproduced in another part of the
program?
•
What ―next bug‖ might be introduced by the fix I‘m about
to make?
•
What could we have done to prevent this bug in the first
place?
Once a bug has been found, it must be corrected.
Van Vleck suggests three simple questions that you should
ask before making the ―correction‖ that removes the
cause of a bug:
•
Is the cause of the bug reproduced in another part of the
•
Is the cause of the bug reproduced in another part of the
program?
•
What ―next bug‖ might be introduced by the fix I‘m about
to make?
•
What could we have done to prevent this bug in the first
place?
Software Implementation Techniques
Afterdetailedsystemdesignwegetasystemdesignwhichcanbe
transformedintoimplementationmodel.Thegoalcodingisto
implementthedesigninthebestpossiblemanner.Codingaffectsboth
testingandmaintenanceverydeeply.Thecodingshouldbedonein.
suchamannerthattheinsteadofgettingthejobofprogrammer
simplifiedthetaskoftestingandmaintenancephaseshouldget
simplified.
Various objectives of coding are –Various objectives of coding are –
1. Programs developed in coding should be readable.
2. They should execute efficiently.
3. The program should utilize less amount of memory.
4. The programs should not be lengthy
If the objectives are clearly specified before the programmers then
while coding they try to achieve the specified objectives. To achieve
these objectives some programming principles must be followed.
Afterdetailedsystemdesignwegetasystemdesignwhichcanbe
transformedintoimplementationmodel.Thegoalcodingisto
implementthedesigninthebestpossiblemanner.Codingaffectsboth
testingandmaintenanceverydeeply.Thecodingshouldbedonein.
suchamannerthattheinsteadofgettingthejobofprogrammer
simplifiedthetaskoftestingandmaintenancephaseshouldget
simplified.
Various objectives of coding are –Various objectives of coding are –
1. Programs developed in coding should be readable.
2. They should execute efficiently.
3. The program should utilize less amount of memory.
4. The programs should not be lengthy
If the objectives are clearly specified before the programmers then
while coding they try to achieve the specified objectives. To achieve
these objectives some programming principles must be followed.
Coding Practices
There are some commonly used programming practices that help in
avoiding the common errors. These are enlisted below –
1. Control construct
The single entry and single exit constructs need to be used. The
standard control constructs must be used instead of using wide variety
of controls.
2. Use of gotos
Thegotostatementsmaketheprogramunstructuredanditalso
imposesoverheadoncompilationprocess.Henceavoiduseofgoto
statementsasfaraspossibleandanotheralternativemustbethought
of.
3. Information hiding
Informationhidingshouldbesupportedasfaraspossible.Inthatcase
onlyaccessfunctionstothedatastructuresmustbemadevisibleand
theinformationpresentinitmustbehidden.
There are some commonly used programming practices that help in
avoiding the common errors. These are enlisted below –
1. Control construct
The single entry and single exit constructs need to be used. The
standard control constructs must be used instead of using wide variety
of controls.
2. Use of gotos
Thegotostatementsmaketheprogramunstructuredanditalso
imposesoverheadoncompilationprocess.Henceavoiduseofgoto
statementsasfaraspossibleandanotheralternativemustbethought
of.
3. Information hiding
Informationhidingshouldbesupportedasfaraspossible.Inthatcase
onlyaccessfunctionstothedatastructuresmustbemadevisibleand
theinformationpresentinitmustbehidden.
4.Nesting
Nestingmeansdefiningonestructureinsideanother.Ifthenesting
istoodeepthenitbecomeshardtounderstandthecode.Hence
asfaraspossible-avoiddeepnestingofthecode.
5.Userdefineddatatypes
Modernprogramminglanguagesallowtheusertousedefined
datatypesastheenumeratedtypes.Useofuserdefineddata
typesenhancesthereadabilityofthecode.typesenhancesthereadabilityofthecode.
6.Modulesize
Thereisnostandardruleaboutthesizeofthemodulebutthe
largesizeofthemodulewillnotbefunctionallycohesive.
7.Moduleinterface
Complexmoduleinterfacemustbecarefullyexamined.Asimple
ruleofthumbisthatthemoduleinterfacewithmorethanfive
parametersmustbebrokenintomultiplemoduleswithsimple
interface.
Nestingmeansdefiningonestructureinsideanother.Ifthenesting
istoodeepthenitbecomeshardtounderstandthecode.Hence
asfaraspossible-avoiddeepnestingofthecode.
5.Userdefineddatatypes
Modernprogramminglanguagesallowtheusertousedefined
datatypesastheenumeratedtypes.Useofuserdefineddata
typesenhancesthereadabilityofthecode.typesenhancesthereadabilityofthecode.
6.Modulesize
Thereisnostandardruleaboutthesizeofthemodulebutthe
largesizeofthemodulewillnotbefunctionallycohesive.
7.Moduleinterface
Complexmoduleinterfacemustbecarefullyexamined.Asimple
ruleofthumbisthatthemoduleinterfacewithmorethanfive
parametersmustbebrokenintomultiplemoduleswithsimple
interface.
8.Sideeffects
Avoidobscuresideeffects.Ifsomepartofthecodeischanged
randomlythenitwillcausesomesideeffect.Forexampleif
numberofparameterspassedtothefunctionischangedthenit
willbedifficulttounderstandthepurposeofthatfunction.
9.Robustness
Theprogramissaidtorobustifitdoessomethingeventhough
someunexceptionalconditionoccurs.Insuchsituationsthe
programsdonotcrashbutitexitsgracefully.
10.Switchcasewithdefaults10.Switchcasewithdefaults
Thechoicebeingpassedtotheswitchcasestatementmayhave
someunpredictablevalue,andthenthedefaultcasewillhelpto
executetheswitchcasestatementwithoutanyproblem.Henceit
isagoodpracticetoalwayshavedefaultcaseintheswitch
statement.
11.Emptycatchblock
Iftheexceptioniscaughtbutifthereisnoactionthenitisnota
goodpractice.Thereforetakesomedefaultactionevenifitisjust
writingsomeprintstatement,whenevertheexceptioniscaught
Avoidobscuresideeffects.Ifsomepartofthecodeischanged
randomlythenitwillcausesomesideeffect.Forexampleif
numberofparameterspassedtothefunctionischangedthenit
willbedifficulttounderstandthepurposeofthatfunction.
9.Robustness
Theprogramissaidtorobustifitdoessomethingeventhough
someunexceptionalconditionoccurs.Insuchsituationsthe
programsdonotcrashbutitexitsgracefully.
10.Switchcasewithdefaults10.Switchcasewithdefaults
Thechoicebeingpassedtotheswitchcasestatementmayhave
someunpredictablevalue,andthenthedefaultcasewillhelpto
executetheswitchcasestatementwithoutanyproblem.Henceit
isagoodpracticetoalwayshavedefaultcaseintheswitch
statement.
11.Emptycatchblock
Iftheexceptioniscaughtbutifthereisnoactionthenitisnota
goodpractice.Thereforetakesomedefaultactionevenifitisjust
writingsomeprintstatement,whenevertheexceptioniscaught
12.Emptyifandwhilestatements
Intheifandwhilestatementssomeconditionsarechecked.
Henceifwewritesomeemptyblockoncheckingthese
conditionsthenthosechecksareprovedtobeuseless
checks.Suchuselesschecksshouldbeavoided.
13.Checkforreadreturn
Manytimesthereturnvaluesthatweobtainfromtheread
functionsarenotcheckedbecauseweblindlybelievethatfunctionsarenotcheckedbecauseweblindlybelievethat
thedesiredresultispresentinthecorrespondingvariable
whenthereadfunctionisperformed.Butthismaycause
someseriouserrors.hencethereturnvaluemustbe
checkedforthereadoperation.
14.ReturnfromFinallyBlock
Thereturnvaluemustcomefromfinallyblockwheneveritis
possible.Thishelpsindistinguishingthedatavaluesthatare
returningfromthetry-catchstatements
Intheifandwhilestatementssomeconditionsarechecked.
Henceifwewritesomeemptyblockoncheckingthese
conditionsthenthosechecksareprovedtobeuseless
checks.Suchuselesschecksshouldbeavoided.
13.Checkforreadreturn
Manytimesthereturnvaluesthatweobtainfromtheread
functionsarenotcheckedbecauseweblindlybelievethatfunctionsarenotcheckedbecauseweblindlybelievethat
thedesiredresultispresentinthecorrespondingvariable
whenthereadfunctionisperformed.Butthismaycause
someseriouserrors.hencethereturnvaluemustbe
checkedforthereadoperation.
14.ReturnfromFinallyBlock
Thereturnvaluemustcomefromfinallyblockwheneveritis
possible.Thishelpsindistinguishingthedatavaluesthatare
returningfromthetry-catchstatements
15.TrustedDatasources
Countercheckshouldbemadebeforeaccessingtheinput
data.Forexamplewhilereadingthedatafromthefileone
mustcheckwhetherthedataaccessedisNULLornot.
16.CorrelatedParameters
Manyoftenthereoccursco-relationbetweenthedataitems.
Itisagoodpracticetochecktheseco-relationsbefore
performinganyoperationonthosedataitems.
17.ExceptionsHandling
Ifduetosomeinputconditioniftheprogramdoesnotfollow
themainpathandfollowsanexceptionalpath.Insucha
situation,anexceptionalpathmaygetfollowed.Inorderto
makethesoftwaremorereliable,itnecessarytowritethe
codeforexecution.
Countercheckshouldbemadebeforeaccessingtheinput
data.Forexamplewhilereadingthedatafromthefileone
mustcheckwhetherthedataaccessedisNULLornot.
16.CorrelatedParameters
Manyoftenthereoccursco-relationbetweenthedataitems.
Itisagoodpracticetochecktheseco-relationsbefore
performinganyoperationonthosedataitems.
17.ExceptionsHandling
Ifduetosomeinputconditioniftheprogramdoesnotfollow
themainpathandfollowsanexceptionalpath.Insucha
situation,anexceptionalpathmaygetfollowed.Inorderto
makethesoftwaremorereliable,itnecessarytowritethe
codeforexecution.
Coding Standards
Any good software development approach suggests to adhere to
some well-defined standards or rules for coding. These rules are
called coding standards.
1. Naming Conventions
1.
Followingaresomecommonlyusednamingconventionsinthe
coding
2.
Packagenameandvariablenamesshouldbeinlowercase.
3.
Variablenamesmustnotbeginwithnumbers.
3.
Variablenamesmustnotbeginwithnumbers.
4.
Thetypenameshouldbenounanditshouldstartwithcapital
letter.
5.
Constantsmustbeinuppercase(ForexamplePI,SIZE)
6.
Methodnamemustbegiveninlowercase.
7.
Thevariableswithlargescopemusthavelongname.For
examplecount_total,sum,Variableswithshortscopemust
haveshortname.Forexamplei,j.
8.
TheprefixismustbeusedforBooleantypeofvariables.For
exampleisEmptyorisFull
Any good software development approach suggests to adhere to
some well-defined standards or rules for coding. These rules are
called coding standards.
1. Naming Conventions
1.
Followingaresomecommonlyusednamingconventionsinthe
coding
2.
Packagenameandvariablenamesshouldbeinlowercase.
3.
Variablenamesmustnotbeginwithnumbers.
3.
Variablenamesmustnotbeginwithnumbers.
4.
Thetypenameshouldbenounanditshouldstartwithcapital
letter.
5.
Constantsmustbeinuppercase(ForexamplePI,SIZE)
6.
Methodnamemustbegiveninlowercase.
7.
Thevariableswithlargescopemusthavelongname.For
examplecount_total,sum,Variableswithshortscopemust
haveshortname.Forexamplei,j.
8.
TheprefixismustbeusedforBooleantypeofvariables.For
exampleisEmptyorisFull
2. Files
Readermustgetanideaaboutthepurposeofthefilebyitsname.
InsomeprogramminglanguagelikeJava–
ThefileextensionmustbeJava.
Thenameofthefileandtheclassdefinedinthefilemusthavethe
same
Linelengthinthefilemustbelimitedto80characters.
3.Commenting/Layout
Commentsarenon-executablepartofthecode.Butitisvery
importantbecauseitenhancesthereadabilityofthecode.The
purposeofthecodeistoexplainthelogicoftheprogram.
Singlelinecommentsmustbegivenby//
Forthenamesofthevariablescommentsmustbegiven.
Ablackofcommentmustbeenclosedwithin/*and*/.
Readermustgetanideaaboutthepurposeofthefilebyitsname.
InsomeprogramminglanguagelikeJava–
ThefileextensionmustbeJava.
Thenameofthefileandtheclassdefinedinthefilemusthavethe
same
Linelengthinthefilemustbelimitedto80characters.
3.Commenting/Layout
Commentsarenon-executablepartofthecode.Butitisvery
importantbecauseitenhancesthereadabilityofthecode.The
purposeofthecodeistoexplainthelogicoftheprogram.
Singlelinecommentsmustbegivenby//
Forthenamesofthevariablescommentsmustbegiven.
Ablackofcommentmustbeenclosedwithin/*and*/.
4. Statements
•
Therearesomeguidelinesaboutthedeclarationand
executablestatements.
•
Declaresomerelatedvariablesonsamelineandunrelated
variablesonanotherline.
•
Classvariableshouldneverbedeclaredpublic.
•
Classvariableshouldneverbedeclaredpublic.
•
Makeuseofonlyloopcontrolwithintheforloop.
•
Avoidmakeuseofbreakandcontinuestatementsinthe
loop.
•
Avoidcomplexconditionalexpressions.Makeuseof
temporaryvariablesinstead.
•
Avoidtheuseofdo...whilestatement.
•
Therearesomeguidelinesaboutthedeclarationand
executablestatements.
•
Declaresomerelatedvariablesonsamelineandunrelated
variablesonanotherline.
•
Classvariableshouldneverbedeclaredpublic.
•
Classvariableshouldneverbedeclaredpublic.
•
Makeuseofonlyloopcontrolwithintheforloop.
•
Avoidmakeuseofbreakandcontinuestatementsinthe
loop.
•
Avoidcomplexconditionalexpressions.Makeuseof
temporaryvariablesinstead.
•
Avoidtheuseofdo...whilestatement.
Code refactoring
•
Coderefactoringistheprocessofrestructuringexisting
computercode–changingthefactoring–withoutchanging
itsexternalbehavior.Refactoringimprovesnonfunctional
attributesofthesoftware.Advantagesincludeimproved
codereadabilityandreducedcomplexitytoimprovesource
codemaintainability,andcreateamoreexpressiveinternalcodemaintainability,andcreateamoreexpressiveinternal
architectureorobjectmodeltoimproveextensibility.
•
Bycontinuouslyimprovingthedesignofcode,wemakeit
easierandeasiertoworkwith.Thisisinsharpcontrastto
whattypicallyhappens:littlerefactoringandagreatdealof
attentionpaidtoexpedientlyaddingnewfeatures.Ifyouget
intothehygienichabitofrefactoringcontinuously,you'llfind
thatitiseasiertoextendandmaintaincode.
•
Coderefactoringistheprocessofrestructuringexisting
computercode–changingthefactoring–withoutchanging
itsexternalbehavior.Refactoringimprovesnonfunctional
attributesofthesoftware.Advantagesincludeimproved
codereadabilityandreducedcomplexitytoimprovesource
codemaintainability,andcreateamoreexpressiveinternalcodemaintainability,andcreateamoreexpressiveinternal
architectureorobjectmodeltoimproveextensibility.
•
Bycontinuouslyimprovingthedesignofcode,wemakeit
easierandeasiertoworkwith.Thisisinsharpcontrastto
whattypicallyhappens:littlerefactoringandagreatdealof
attentionpaidtoexpedientlyaddingnewfeatures.Ifyouget
intothehygienichabitofrefactoringcontinuously,you'llfind
thatitiseasiertoextendandmaintaincode.
There are two general categories of benefits to the activity of
refactoring.
1.
Maintainability.Itiseasiertofixbugsbecausethe
sourcecodeiseasytoreadandtheintentofitsauthoris
easytograsp.Thismightbeachievedbyreducinglarge
monolithicroutinesintoasetofindividuallyconcise,well-
named,single-purposemethods.Itmightbeachievedbynamed,single-purposemethods.Itmightbeachievedby
movingamethodtoamoreappropriateclass,orby
removingmisleadingcomments.
2.Extensibility.Itiseasiertoextendthecapabilitiesofthe
applicationifitusesrecognizabledesignpatterns,andit
providessomeflexibilitywherenonebeforemayhave
existed.
refactoring.
1.
Maintainability.Itiseasiertofixbugsbecausethe
sourcecodeiseasytoreadandtheintentofitsauthoris
easytograsp.Thismightbeachievedbyreducinglarge
monolithicroutinesintoasetofindividuallyconcise,well-
named,single-purposemethods.Itmightbeachievedbynamed,single-purposemethods.Itmightbeachievedby
movingamethodtoamoreappropriateclass,orby
removingmisleadingcomments.
2.Extensibility.Itiseasiertoextendthecapabilitiesofthe
applicationifitusesrecognizabledesignpatterns,andit
providessomeflexibilitywherenonebeforemayhave
existed.
Refactoring is needed due to various reasons. They are as follows:
•
LackofModularity–Existingfeatureofoneapplicationcan’tbe
usedinanotherapplicationduetoitstightcouplingwiththe
applicationcomponents.
•
LackofReusableComponents –Thereareinstancesofcode
duplicityandpotentialreusablecomponentsdependencyon
applicationcode.
•
LackofPluggableComponents–Existingcomponentsarenot
•
LackofPluggableComponents–Existingcomponentsarenot
easilyreplaceableduetoitsapplicationcodetightlycoupledwith
thecomponents.
•
Service Oriented Architecture –Scope for SOA components
where each component can work as a service and reusable.
•
Code Redundancy –Application has lots of dead code and
duplicate code.
•
Lack of Layered Architecture –Any change in one layer causes
changes in all other layers.
•
LackofModularity–Existingfeatureofoneapplicationcan’tbe
usedinanotherapplicationduetoitstightcouplingwiththe
applicationcomponents.
•
LackofReusableComponents –Thereareinstancesofcode
duplicityandpotentialreusablecomponentsdependencyon
applicationcode.
•
LackofPluggableComponents–Existingcomponentsarenot
•
LackofPluggableComponents–Existingcomponentsarenot
easilyreplaceableduetoitsapplicationcodetightlycoupledwith
thecomponents.
•
Service Oriented Architecture –Scope for SOA components
where each component can work as a service and reusable.
•
Code Redundancy –Application has lots of dead code and
duplicate code.
•
Lack of Layered Architecture –Any change in one layer causes
changes in all other layers.
•
PoorCodingStyle –Codingstandardshasnotbeen
followedproperlywhichincludesimpropernamesto
objects/methods,accessingthefieldswithoutgetter/setters.
•
IllogicalMethodsComposition–Illogicalgroupingof
methodsinoneclass.
•
ImproperPackaging –Artifactsareplacedinthe
applicationcodewhichcanbekeptatotherlocations;
forcingdevelopertochangethejarsineachoftheforcingdevelopertochangethejarsineachofthe
applicationmanuallyinsteadofupdatingitatacentered
location.
•
UseofOldVersionofThirdPartyApplication/Jars –
Applicationisusingolderversionofsoftware’sinsteadof
usinglatestversionandhencenewfeaturescan’tbeused
andexploredintheapplication.
PoorCodingStyle –Codingstandardshasnotbeen
followedproperlywhichincludesimpropernamesto
objects/methods,accessingthefieldswithoutgetter/setters.
•
IllogicalMethodsComposition–Illogicalgroupingof
methodsinoneclass.
•
ImproperPackaging –Artifactsareplacedinthe
applicationcodewhichcanbekeptatotherlocations;
forcingdevelopertochangethejarsineachoftheforcingdevelopertochangethejarsineachofthe
applicationmanuallyinsteadofupdatingitatacentered
location.
•
UseofOldVersionofThirdPartyApplication/Jars –
Applicationisusingolderversionofsoftware’sinsteadof
usinglatestversionandhencenewfeaturescan’tbeused
andexploredintheapplication.
Steps for Refactoring:
1.Writingunittestcases–Testcasesshouldbewrittentotestthe
applicationbehaviorandensurethatitisunchangedafterevery
cycleofrefactoring.
2.Identifyingthetaskforrefactoring–Identifythesetoftasksfor
performingtherefactoring.
3.Findtheproblem–Findoutifthereisanyissuewiththecurrent
pieceofcodeandifyesspecifywhatistheproblem?
4.Evaluate/Analyzetheproblem–Afterfindingoutthepotential4.Evaluate/Analyzetheproblem–Afterfindingoutthepotential
problemevaluateitagainsttherisksinvolvedandthebenefits.
5.Designsolution–Findoutwhatwillbetheresultantcodeafter
refactoringofthecode.Designsolutionwhichleadsfromcurrent
statetothetargetstate.
6.Modifythecode–Refactorthecodewithoutchangingtheouter
behaviorofthecode.
7.Testrefactoredcodeiffailsrollbacktothelastsmallerchange
andrepeattherefactoringinadifferentway.
8.Repeatabovecycleuntilthecurrentcodemovestothetarget
state.
1.Writingunittestcases–Testcasesshouldbewrittentotestthe
applicationbehaviorandensurethatitisunchangedafterevery
cycleofrefactoring.
2.Identifyingthetaskforrefactoring–Identifythesetoftasksfor
performingtherefactoring.
3.Findtheproblem–Findoutifthereisanyissuewiththecurrent
pieceofcodeandifyesspecifywhatistheproblem?
4.Evaluate/Analyzetheproblem–Afterfindingoutthepotential4.Evaluate/Analyzetheproblem–Afterfindingoutthepotential
problemevaluateitagainsttherisksinvolvedandthebenefits.
5.Designsolution–Findoutwhatwillbetheresultantcodeafter
refactoringofthecode.Designsolutionwhichleadsfromcurrent
statetothetargetstate.
6.Modifythecode–Refactorthecodewithoutchangingtheouter
behaviorofthecode.
7.Testrefactoredcodeiffailsrollbacktothelastsmallerchange
andrepeattherefactoringinadifferentway.
8.Repeatabovecycleuntilthecurrentcodemovestothetarget
state.
Risks Involved in Refactoring
•
Ifthereisarequirementforcodechangethenrefactoring
occurs.Themainriskofrefactoringisthatexistingworking
codemaybreakduetothechangesbeingmade.Thisisthe
mainreasonwhymostoftenrefactoringisnotdone.In
ordertomitigateoravoidthisriskfollowingtworulesmust
befollowed:befollowed:
•
Rule1:Re-factorinsmallsteps.
•
Rule2:Fortestingtheexistingfunctionalitiesmakeuseof
testscripts.
•
Byfollowingthesetworulesthebugsintherefactoringcan
beeasilyidentifiedandcorrected.Ineachrefactoringonly
smallchangeismadebuttheseriesofrefactoringmakesa
significanttransformationintheprogramstructure
•
Ifthereisarequirementforcodechangethenrefactoring
occurs.Themainriskofrefactoringisthatexistingworking
codemaybreakduetothechangesbeingmade.Thisisthe
mainreasonwhymostoftenrefactoringisnotdone.In
ordertomitigateoravoidthisriskfollowingtworulesmust
befollowed:befollowed:
•
Rule1:Re-factorinsmallsteps.
•
Rule2:Fortestingtheexistingfunctionalitiesmakeuseof
testscripts.
•
Byfollowingthesetworulesthebugsintherefactoringcan
beeasilyidentifiedandcorrected.Ineachrefactoringonly
smallchangeismadebuttheseriesofrefactoringmakesa
significanttransformationintheprogramstructure
Key Benefits from Refactoring
•
Improves software expendability
•
Reduces maintenance cost
•
Provides standardized code
•
Architecture improvement without impacting software
behavior behavior
•
Provides more readable and modular code
•
Refactored modular component increases potential
reusability.
•
Improves software expendability
•
Reduces maintenance cost
•
Provides standardized code
•
Architecture improvement without impacting software
behavior behavior
•
Provides more readable and modular code
•
Refactored modular component increases potential
reusability.
Software maintenance
•
“Themodificationofasoftwareproductafterdeliverytocorrect
faults,toimproveperformanceorotherattributes,ortoadaptthe
producttoamodifiedenvironment.”
•
Modifyingaprogramafterithasbeenputintouse,afterdelivery
tocustomer.
•
Maintenancedoesnotnormallyinvolvemajorchangestothe
system’sarchitecture
•
Maintenanceisoftencontractedout/outsourced
•
Maintenanceisoftencontractedout/outsourced
Therearenumberofreasons,whymodificationsarerequired,
someofthemarebrieflymentionedbelow:
•
Market Conditions
•
Client Requirements
•
Host Modifications
•
Organization Changes
•
“Themodificationofasoftwareproductafterdeliverytocorrect
faults,toimproveperformanceorotherattributes,ortoadaptthe
producttoamodifiedenvironment.”
•
Modifyingaprogramafterithasbeenputintouse,afterdelivery
tocustomer.
•
Maintenancedoesnotnormallyinvolvemajorchangestothe
system’sarchitecture
•
Maintenanceisoftencontractedout/outsourced
•
Maintenanceisoftencontractedout/outsourced
Therearenumberofreasons,whymodificationsarerequired,
someofthemarebrieflymentionedbelow:
•
Market Conditions
•
Client Requirements
•
Host Modifications
•
Organization Changes
Types of software maintenance
Corrective maintenance
•
Impracticaltoexhaustivelytestalargesoftwaresystem.
Thereforereasonabletoassumethatanylargesystemwill
haveerrors.haveerrors.
•
Testingshouldbethoroughforcommoncases,soerrors
likelytobeobscure.
•
Theprocessofreceivingreportsofsucherrors,diagnosing
theproblem,andfixingitiscalled"correctivemaintenance"
Corrective maintenance
•
Impracticaltoexhaustivelytestalargesoftwaresystem.
Thereforereasonabletoassumethatanylargesystemwill
haveerrors.haveerrors.
•
Testingshouldbethoroughforcommoncases,soerrors
likelytobeobscure.
•
Theprocessofreceivingreportsofsucherrors,diagnosing
theproblem,andfixingitiscalled"correctivemaintenance"
Adaptive maintenance
•
Systemsdon'tfunctioninisolation.
•
Typicallytheymayinteractwithoperatingsystems,
DBMS's,GUI's,networkprotocols,otherexternalsoftware
packages,andvarioushardwareplatforms
•
IntheITindustryanyorallofthesemaychangeovera
•
IntheITindustryanyorallofthesemaychangeovera
veryshortperiod(typicallysixmonths)
•
Theprocessofassessingtheeffectsofsuch
"environmentalchanges"onasoftwaresystem,andthen
modifyingthesystemtocopewiththosechangesisknown
as"adaptivemaintenance
•
Systemsdon'tfunctioninisolation.
•
Typicallytheymayinteractwithoperatingsystems,
DBMS's,GUI's,networkprotocols,otherexternalsoftware
packages,andvarioushardwareplatforms
•
IntheITindustryanyorallofthesemaychangeovera
•
IntheITindustryanyorallofthesemaychangeovera
veryshortperiod(typicallysixmonths)
•
Theprocessofassessingtheeffectsofsuch
"environmentalchanges"onasoftwaresystem,andthen
modifyingthesystemtocopewiththosechangesisknown
as"adaptivemaintenance
Perfective maintenance
•
Users and marketers are never satisfied
•
Even if a system is wildly successful, someone will want
new or enhanced features added to it
•
Sometimes there will also be impetus to alter the way a
certain component of the system works, or its interface certain component of the system works, or its interface
•
The process of receiving suggestions and requests for such
enhancements or modifications, evaluating
•
Users and marketers are never satisfied
•
Even if a system is wildly successful, someone will want
new or enhanced features added to it
•
Sometimes there will also be impetus to alter the way a
certain component of the system works, or its interface certain component of the system works, or its interface
•
The process of receiving suggestions and requests for such
enhancements or modifications, evaluating
Preventativemaintenance
•
Sometimeschangesareneededforentirelyinternal
reasons
•
Suchchangeshavenodirectdiscernibleeffectontheuser,
butlaythegroundworkforeasiermaintenanceinthefuture
•
Alternatively,suchchangesmayimprovereliability,or
•
Alternatively,suchchangesmayimprovereliability,or
provideabetterbasisforfuturedevelopment
•
Theprocessofplanningsuchcodereorganizations,
implementingthem,andtestingtoensurethattheyhaveno
adverseimpactisknownas"preventativemaintenance"
•
Sometimeschangesareneededforentirelyinternal
reasons
•
Suchchangeshavenodirectdiscernibleeffectontheuser,
butlaythegroundworkforeasiermaintenanceinthefuture
•
Alternatively,suchchangesmayimprovereliability,or
•
Alternatively,suchchangesmayimprovereliability,or
provideabetterbasisforfuturedevelopment
•
Theprocessofplanningsuchcodereorganizations,
implementingthem,andtestingtoensurethattheyhaveno
adverseimpactisknownas"preventativemaintenance"
CostofMaintenance
Reportssuggestthatthecostofmaintenanceishigh.A
studyonestimatingsoftwaremaintenancefoundthatthe
costofmaintenanceisashighas67%ofthecostofentire
softwareprocesscycle.Onanaverage,thecostofsoftware
maintenanceismorethan50%ofallSDLCphases.
Reportssuggestthatthecostofmaintenanceishigh.A
studyonestimatingsoftwaremaintenancefoundthatthe
costofmaintenanceisashighas67%ofthecostofentire
softwareprocesscycle.Onanaverage,thecostofsoftware
maintenanceismorethan50%ofallSDLCphases.
Typical problems with maintenance
•
Inadequatedocumentationofsoftwareevolution
•
Inadequatedocumentationofsoftwaredesignandstructure
•
Lossof"cultural"knowledgeofsoftwareduetostaff
turnover
•
Lackofallowanceforchangeinoriginalsoftwaredesign
•
Lackofallowanceforchangeinoriginalsoftwaredesign
•
Maintenanceisunglamorousandmaybeviewedasa
"punishmenttask"
Software-endfactorsaffectingMaintenanceCost
•
StructureofSoftwareProgram
•
ProgrammingLanguage
•
Dependenceonexternalenvironment
•
Staffreliabilityandavailability
•
Inadequatedocumentationofsoftwareevolution
•
Inadequatedocumentationofsoftwaredesignandstructure
•
Lossof"cultural"knowledgeofsoftwareduetostaff
turnover
•
Lackofallowanceforchangeinoriginalsoftwaredesign
•
Lackofallowanceforchangeinoriginalsoftwaredesign
•
Maintenanceisunglamorousandmaybeviewedasa
"punishmenttask"
Software-endfactorsaffectingMaintenanceCost
•
StructureofSoftwareProgram
•
ProgrammingLanguage
•
Dependenceonexternalenvironment
•
Staffreliabilityandavailability
Maintenance Activities
IEEEprovidesaframeworkforsequentialmaintenance
processactivities.Itcanbeusediniterativemannerandcan
beextendedsothatcustomizeditemsandprocessescanbe
included.
IEEEprovidesaframeworkforsequentialmaintenance
processactivities.Itcanbeusediniterativemannerandcan
beextendedsothatcustomizeditemsandprocessescanbe
included.
•
Identification&Tracing-Itinvolvesactivitiespertainingto
identificationofrequirementofmodificationormaintenance.Itis
generatedbyuserorsystemmayitselfreportvialogsorerror
messages.Here,themaintenancetypeisclassifiedalso.
•
Analysis-Themodificationisanalyzedforitsimpactonthe
systemincludingsafetyandsecurityimplications.Ifprobable
impactissevere,alternativesolutionislookedfor.Asetof
requiredmodificationsisthenmaterializedintorequirement
specifications.Thecostofmodification/maintenanceisanalyzedspecifications.Thecostofmodification/maintenanceisanalyzed
andestimationisconcluded.
•
Design-Newmodules,whichneedtobereplacedormodified,
aredesignedagainstrequirementspecificationssetinthe
previousstage.Testcasesarecreatedforvalidationand
verification.
•
Implementation-Thenewmodulesarecodedwiththehelpof
structureddesigncreatedinthedesignstep.Everyprogrammer
isexpectedtodounittestinginparallel.
Identification&Tracing-Itinvolvesactivitiespertainingto
identificationofrequirementofmodificationormaintenance.Itis
generatedbyuserorsystemmayitselfreportvialogsorerror
messages.Here,themaintenancetypeisclassifiedalso.
•
Analysis-Themodificationisanalyzedforitsimpactonthe
systemincludingsafetyandsecurityimplications.Ifprobable
impactissevere,alternativesolutionislookedfor.Asetof
requiredmodificationsisthenmaterializedintorequirement
specifications.Thecostofmodification/maintenanceisanalyzedspecifications.Thecostofmodification/maintenanceisanalyzed
andestimationisconcluded.
•
Design-Newmodules,whichneedtobereplacedormodified,
aredesignedagainstrequirementspecificationssetinthe
previousstage.Testcasesarecreatedforvalidationand
verification.
•
Implementation-Thenewmodulesarecodedwiththehelpof
structureddesigncreatedinthedesignstep.Everyprogrammer
isexpectedtodounittestinginparallel.
•
SystemTesting-Integrationtestingisdoneamongnewly
createdmodules.Integrationtestingisalsocarriedoutbetween
newmodulesandthesystem.Finallythesystemistestedasa
whole,followingregressivetestingprocedures.
•
AcceptanceTesting-Aftertestingthesysteminternally,itis
testedforacceptancewiththehelpofusers.Ifatthisstate,user
complaintssomeissuestheyareaddressedornotedtoaddress
innextiteration.
•
Delivery-Afteracceptancetest,thesystemisdeployedallover
•
Delivery-Afteracceptancetest,thesystemisdeployedallover
theorganizationeitherbysmallupdatepackageorfresh
installationofthesystem.Thefinaltestingtakesplaceatclient
endafterthesoftwareisdelivered.
Trainingfacilityisprovidedifrequired,inadditiontothehardcopy
ofusermanual.
•
Maintenancemanagement -Configurationmanagementisan
essentialpartofsystemmaintenance.Itisaidedwithversion
controltoolstocontrolversions,semi-versionorpatch
management.
SystemTesting-Integrationtestingisdoneamongnewly
createdmodules.Integrationtestingisalsocarriedoutbetween
newmodulesandthesystem.Finallythesystemistestedasa
whole,followingregressivetestingprocedures.
•
AcceptanceTesting-Aftertestingthesysteminternally,itis
testedforacceptancewiththehelpofusers.Ifatthisstate,user
complaintssomeissuestheyareaddressedornotedtoaddress
innextiteration.
•
Delivery-Afteracceptancetest,thesystemisdeployedallover
•
Delivery-Afteracceptancetest,thesystemisdeployedallover
theorganizationeitherbysmallupdatepackageorfresh
installationofthesystem.Thefinaltestingtakesplaceatclient
endafterthesoftwareisdelivered.
Trainingfacilityisprovidedifrequired,inadditiontothehardcopy
ofusermanual.
•
Maintenancemanagement -Configurationmanagementisan
essentialpartofsystemmaintenance.Itisaidedwithversion
controltoolstocontrolversions,semi-versionorpatch
management.
Reengineering:
•
The process typically encompasses a combination of other processes
such as reverse engineering, re-documentation, restructuring, translation,
and forward engineering.
•
For example, initially Unix was developed in assembly language. When
language C came into existence, Unix was re-engineered in C, because
working in assembly language was difficult.
•
Other than this, sometimes programmers notice that few parts of
software need more maintenance than others and they also need re-
engineering. engineering.
•
The process typically encompasses a combination of other processes
such as reverse engineering, re-documentation, restructuring, translation,
and forward engineering.
•
For example, initially Unix was developed in assembly language. When
language C came into existence, Unix was re-engineered in C, because
working in assembly language was difficult.
•
Other than this, sometimes programmers notice that few parts of
software need more maintenance than others and they also need re-
engineering. engineering.
Business Process Reengineering (BPR)
Alsoknownasprocessinnovationandcoreprocessredesign-
attemptstorestructureorobliterateunproductivemanagement
layers,wipeoutredundancies,andremodelprocesses
differently.Businessprocessre-engineeringreferstothe
analysis,controlanddevelopmentofacompany’ssystemsand
workflow
Alsoknownasprocessinnovationandcoreprocessredesign-
attemptstorestructureorobliterateunproductivemanagement
layers,wipeoutredundancies,andremodelprocesses
differently.Businessprocessre-engineeringreferstothe
analysis,controlanddevelopmentofacompany’ssystemsand
workflow
Define Objectives and Framework:
•
Firstofall,theobjectiveofre-engineeringmustbedefinedinthe
quantitativeandqualitativeterms.Theobjectivesaretheend
resultsthatthemanagementdesiresafterthereengineering.
•
Oncetheobjectivesaredefined,theneedforchangeshouldbe
wellcommunicatedtotheemployeesbecause,thesuccessof
BPRdependsonthereadinessoftheemployeestoacceptthe
change.
IdentifyCustomerNeeds:
•
While,redesigningthebusinessprocesstheneedsofthe
customersmustbetakenintopriorconsideration.Theprocesscustomersmustbetakenintopriorconsideration.Theprocess
shallberedesignedinsuchawaythatitclearlyprovidesthe
addedvaluetothecustomer.Onemusttakethefollowing
parametersintotheconsideration:
•
Customer’sexpectedutilitiesinproductandservices
•
Customerrequirements,buyinghabitsandconsuming
tendencies.
•
Customerproblemsandexpectationsabouttheproductor
service.
•
Firstofall,theobjectiveofre-engineeringmustbedefinedinthe
quantitativeandqualitativeterms.Theobjectivesaretheend
resultsthatthemanagementdesiresafterthereengineering.
•
Oncetheobjectivesaredefined,theneedforchangeshouldbe
wellcommunicatedtotheemployeesbecause,thesuccessof
BPRdependsonthereadinessoftheemployeestoacceptthe
change.
IdentifyCustomerNeeds:
•
While,redesigningthebusinessprocesstheneedsofthe
customersmustbetakenintopriorconsideration.Theprocesscustomersmustbetakenintopriorconsideration.Theprocess
shallberedesignedinsuchawaythatitclearlyprovidesthe
addedvaluetothecustomer.Onemusttakethefollowing
parametersintotheconsideration:
•
Customer’sexpectedutilitiesinproductandservices
•
Customerrequirements,buyinghabitsandconsuming
tendencies.
•
Customerproblemsandexpectationsabouttheproductor
service.
StudytheExistingProcess:
Beforedecidingonthechangestobemadeintheexistingbusiness
process,onemustanalyzeitcarefully.
Theexistingprocessprovidesabaseforthenewprocessandhence
“what”and“why”ofthenewprocesscanbewelldesignedbystudying
therightandwrongsoftheexistingbusinessplan.
FormulateaRedesignBusinessPlan :
Oncetheexistingbusinessprocessisstudiedthoroughly,therequiredOncetheexistingbusinessprocessisstudiedthoroughly,therequired
changesarewrittendownonapieceofpaperandisconvertedintoan
idealre-designprocess.Here,allthechangesarechalkeddown,andthe
bestamongallthealternativesisselected.
ImplementtheRedesign:
Finally,thechangesareimplementedintotheredesignplantoachieve
thedramaticimprovements.Itistheresponsibilityofboththe
managementandthedesignertooperationalisethenewprocessand
gainthesupportofall.Thus,thebusinessprocessreengineeringis
collectionofinterrelatedtasksoractivitiesdesignedtoaccomplishthe
specifiedoutcome.
Beforedecidingonthechangestobemadeintheexistingbusiness
process,onemustanalyzeitcarefully.
Theexistingprocessprovidesabaseforthenewprocessandhence
“what”and“why”ofthenewprocesscanbewelldesignedbystudying
therightandwrongsoftheexistingbusinessplan.
FormulateaRedesignBusinessPlan :
Oncetheexistingbusinessprocessisstudiedthoroughly,therequiredOncetheexistingbusinessprocessisstudiedthoroughly,therequired
changesarewrittendownonapieceofpaperandisconvertedintoan
idealre-designprocess.Here,allthechangesarechalkeddown,andthe
bestamongallthealternativesisselected.
ImplementtheRedesign:
Finally,thechangesareimplementedintotheredesignplantoachieve
thedramaticimprovements.Itistheresponsibilityofboththe
managementandthedesignertooperationalisethenewprocessand
gainthesupportofall.Thus,thebusinessprocessreengineeringis
collectionofinterrelatedtasksoractivitiesdesignedtoaccomplishthe
specifiedoutcome.
Re-Engineering Process
•
Decide what to re-engineer. Is it whole software or a part of
it?
•
Perform Reverse Engineering, in order to obtain
specifications of existing software.
•
Restructure Program if required. For example, changing
function-oriented programs into object-oriented programs. function-oriented programs into object-oriented programs.
•
Re-structure data as required.
•
Apply Forward engineering concepts in order to get re-
engineered software.
.
•
Decide what to re-engineer. Is it whole software or a part of
it?
•
Perform Reverse Engineering, in order to obtain
specifications of existing software.
•
Restructure Program if required. For example, changing
function-oriented programs into object-oriented programs. function-oriented programs into object-oriented programs.
•
Re-structure data as required.
•
Apply Forward engineering concepts in order to get re-
engineered software.
.
Reengineering process model .
Code restructuring
•
Source code is analyzed and violations of structured
programming practices are noted and repaired
•
Revised code needs to be reviewed and tested
Data restructuring Data restructuring
•
Usually requires full reverse engineering
•
Current data architecture is dissected
•
Data models are defined
•
Existing data structures are reviewed for quality
•
Source code is analyzed and violations of structured
programming practices are noted and repaired
•
Revised code needs to be reviewed and tested
Data restructuring Data restructuring
•
Usually requires full reverse engineering
•
Current data architecture is dissected
•
Data models are defined
•
Existing data structures are reviewed for quality
Reverse Engineering
•
Itisaprocesstoachievesystemspecificationby
thoroughlyanalyzing,understandingtheexistingsystem.
ThisprocesscanbeseenasreverseSDLCmodel,i.e.we
trytogethigherabstractionlevelbyanalyzinglower
abstractionlevels.
•
Anexistingsystemispreviouslyimplementeddesign,
aboutwhichweknownothing.Designersthendoreverse
engineeringbylookingatthecodeandtrytogetthe
design.
•
Withdesigninhand,theytrytoconcludethe
specifications.Thus,goinginreversefromcodetosystem
specification.
•
Itisaprocesstoachievesystemspecificationby
thoroughlyanalyzing,understandingtheexistingsystem.
ThisprocesscanbeseenasreverseSDLCmodel,i.e.we
trytogethigherabstractionlevelbyanalyzinglower
abstractionlevels.
•
Anexistingsystemispreviouslyimplementeddesign,
aboutwhichweknownothing.Designersthendoreverse
engineeringbylookingatthecodeandtrytogetthe
design.
•
Withdesigninhand,theytrytoconcludethe
specifications.Thus,goinginreversefromcodetosystem
specification.
Forward Engineering
•
Forwardengineeringisaprocessofobtainingdesired
softwarefromthespecificationsinhandwhichwere
broughtdownbymeansofreverseengineering.It
assumesthattherewassomesoftwareengineering
alreadydoneinthepast.
•
Forwardengineeringissameassoftwareengineering
processwithonlyonedifference–itiscarriedoutalways
afterreverseengineering.
•
Inforwardengineering,onetakesasetofprimitivesof
interest,buildsthemintoaworkingsystem,andthen
observeswhatthesystemcanandcannotdo.
•
Forwardengineeringisaprocessofobtainingdesired
softwarefromthespecificationsinhandwhichwere
broughtdownbymeansofreverseengineering.It
assumesthattherewassomesoftwareengineering
alreadydoneinthepast.
•
Forwardengineeringissameassoftwareengineering
processwithonlyonedifference–itiscarriedoutalways
afterreverseengineering.
•
Inforwardengineering,onetakesasetofprimitivesof
interest,buildsthemintoaworkingsystem,andthen
observeswhatthesystemcanandcannotdo.
DifferencebetweenForwardEngineering
andReverseEngineering
•
Goal:Thegoalofforwardengineeringistodevelopnew
softwarefromscratch,whilethegoalofreverseengineeringis
toanalyzeandunderstandanexistingsoftwaresystem.
•
Process:Forwardengineeringinvolvesdesigningand
implementinganewsoftwaresystembasedonrequirementsimplementinganewsoftwaresystembasedonrequirements
andspecifications.Reverseengineeringinvolvesanalyzingan
existingsoftwaresystemtounderstanditsdesign,structure,
andbehavior.
•
ToolsandTechniques:Forwardengineeringofteninvolvesthe
useofsoftwaredevelopmenttools,suchasIDEs,code
generators,andtestingframeworks.Reverseengineeringoften
involvestheuseofreverseengineeringtools,suchas
decompilers,disassemblers,andcodeanalyzers.
andReverseEngineering
•
Goal:Thegoalofforwardengineeringistodevelopnew
softwarefromscratch,whilethegoalofreverseengineeringis
toanalyzeandunderstandanexistingsoftwaresystem.
•
Process:Forwardengineeringinvolvesdesigningand
implementinganewsoftwaresystembasedonrequirementsimplementinganewsoftwaresystembasedonrequirements
andspecifications.Reverseengineeringinvolvesanalyzingan
existingsoftwaresystemtounderstanditsdesign,structure,
andbehavior.
•
ToolsandTechniques:Forwardengineeringofteninvolvesthe
useofsoftwaredevelopmenttools,suchasIDEs,code
generators,andtestingframeworks.Reverseengineeringoften
involvestheuseofreverseengineeringtools,suchas
decompilers,disassemblers,andcodeanalyzers.
DifferencebetweenForward
EngineeringandReverseEngineering
•
Focus:Forwardengineeringfocusesonthecreationof
newcodeandfunctionality,whilereverseengineering
focusesonunderstandinganddocumentingexistingcode
andfunctionality.
•
Output:Theoutputofforwardengineeringisanew
softwaresystem,whiletheoutputofreverseengineeringis
documentationofanexistingsoftwaresystem,suchasa
UMLdiagram,flowchart,orsoftwarespecification.
EngineeringandReverseEngineering
•
Focus:Forwardengineeringfocusesonthecreationof
newcodeandfunctionality,whilereverseengineering
focusesonunderstandinganddocumentingexistingcode
andfunctionality.
•
Output:Theoutputofforwardengineeringisanew
softwaresystem,whiletheoutputofreverseengineeringis
documentationofanexistingsoftwaresystem,suchasa
UMLdiagram,flowchart,orsoftwarespecification.
Software Reviews
•
A review is any activity in which a work product is
exposed to reviewers to examine and give
feedback.
•
Purpose is to find defects (errors) before they are
passed on to another software engineering passed on to another software engineering
activity or released to the customer.
•
Software engineers (and others) conduct formal
technical reviews (FTR)
•
Using formal technical reviews is an effective
means for improving software quality.
•
A review is any activity in which a work product is
exposed to reviewers to examine and give
feedback.
•
Purpose is to find defects (errors) before they are
passed on to another software engineering passed on to another software engineering
activity or released to the customer.
•
Software engineers (and others) conduct formal
technical reviews (FTR)
•
Using formal technical reviews is an effective
means for improving software quality.
Review Roles
•
Presenter (designer/producer).
•
Coordinator
•
Recorder
•
records events of meeting
•
records events of meeting
•
builds paper trail
•
Reviewers
•
maintenance experts
•
standards bearer
•
user representative
•
others
•
Presenter (designer/producer).
•
Coordinator
•
Recorder
•
records events of meeting
•
records events of meeting
•
builds paper trail
•
Reviewers
•
maintenance experts
•
standards bearer
•
user representative
•
others
Formal Technical Reviews
•
Involves 3 to 5 people (including reviewers)
•
Advance preparation (no more than 2 hours per
person) required
•
Duration of review meeting should be less than 2
•
Duration of review meeting should be less than 2
hours
•
Focus of review is on a discrete work product
•
Review leader organizes the review meeting at
the producer's request.
•
Involves 3 to 5 people (including reviewers)
•
Advance preparation (no more than 2 hours per
person) required
•
Duration of review meeting should be less than 2
•
Duration of review meeting should be less than 2
hours
•
Focus of review is on a discrete work product
•
Review leader organizes the review meeting at
the producer's request.
Formal Technical Reviews
•
Reviewers ask questions that enable the producer to
discover his or her own error (the product is under
review not the producer)
•
Producer of the work product walks the reviewers
through the productthrough the product
•
Recorder writes down any significant issues raised
during the review
•
Reviewers decide to accept or reject the work product
or to go for additional reviews of the product.
All work products and components like SRS, schedules,
design documents, code, test plans, test cases, and
defect reports should be reviewed.
•
Reviewers ask questions that enable the producer to
discover his or her own error (the product is under
review not the producer)
•
Producer of the work product walks the reviewers
through the productthrough the product
•
Recorder writes down any significant issues raised
during the review
•
Reviewers decide to accept or reject the work product
or to go for additional reviews of the product.
All work products and components like SRS, schedules,
design documents, code, test plans, test cases, and
defect reports should be reviewed.
Why Reviews?
•
To improve the quality.
•
Catch 80% of all errors if done properly.
•
Catch both coding and design errors.
•
Enforce the spirit of any organization standards.
•
Training and insurance.
•
Training and insurance.
•
Useful not only for finding and eliminating defects, but
also for gaining consensus among the project team,
securing approval from stakeholders, and aiding in
professional development for team members.
•
Help find defects soon after they are injected making
them cost less to fix than they would cost if they were
found in test.
•
To improve the quality.
•
Catch 80% of all errors if done properly.
•
Catch both coding and design errors.
•
Enforce the spirit of any organization standards.
•
Training and insurance.
•
Training and insurance.
•
Useful not only for finding and eliminating defects, but
also for gaining consensus among the project team,
securing approval from stakeholders, and aiding in
professional development for team members.
•
Help find defects soon after they are injected making
them cost less to fix than they would cost if they were
found in test.
Types of Review:
Inspections
•
Inspectionsare moderated meetings in which
reviewers list all issues and defects they have
found in the document and log them so that they
can be addressed by the author.can be addressed by the author.
•
The goal of the inspection is to repair the defects
so that everyone on the inspection team can
approve the work product.
•
Commonly inspected work products include
software requirements specifications and test
plans.
Inspections
•
Inspectionsare moderated meetings in which
reviewers list all issues and defects they have
found in the document and log them so that they
can be addressed by the author.can be addressed by the author.
•
The goal of the inspection is to repair the defects
so that everyone on the inspection team can
approve the work product.
•
Commonly inspected work products include
software requirements specifications and test
plans.
Types of Review:
Inspections
•
Running an inspection meeting:
1.
A work product is selected for review and a team is gathered
for an inspection meeting to review the work product.
2.
A moderator is chosen to moderate the meeting.
3.
Each inspector prepares for the meeting by reading the work
product and noting each defect.product and noting each defect.
4.
In an inspection, a defect is any part of the work product that
will keep an inspector from approving it.
5.
Discussion is focused on each defect, and coming up with a
specific resolution.
•
Job of the inspection team is not just identify the problems;
but also come up with the solutions.
6.
The moderator compiles all of the defect resolutions into an
inspection log
Inspections
•
Running an inspection meeting:
1.
A work product is selected for review and a team is gathered
for an inspection meeting to review the work product.
2.
A moderator is chosen to moderate the meeting.
3.
Each inspector prepares for the meeting by reading the work
product and noting each defect.product and noting each defect.
4.
In an inspection, a defect is any part of the work product that
will keep an inspector from approving it.
5.
Discussion is focused on each defect, and coming up with a
specific resolution.
•
Job of the inspection team is not just identify the problems;
but also come up with the solutions.
6.
The moderator compiles all of the defect resolutions into an
inspection log
Inspection Log Example
Types of Review:
Deskchecks
•
A deskcheckis a simple review in which the
author of a work product distributes it to one
or more reviewers.
The author sends a copy of the work product
•
The author sends a copy of the work product
to selected project team members. The team
members read it, and then write up defects
and comments to send back to the author.
Deskchecks
•
A deskcheckis a simple review in which the
author of a work product distributes it to one
or more reviewers.
The author sends a copy of the work product
•
The author sends a copy of the work product
to selected project team members. The team
members read it, and then write up defects
and comments to send back to the author.
Types of Review:
Deskchecks
•
Unlike an inspection, a deskcheckdoes not
produce written logs which can be archived with
the document for later reference.
•
Deskcheckscan be used as predecessors to
•
Deskcheckscan be used as predecessors to
inspections.
•
In many cases, having an author of a work
product pass his work to a peer for an informal
review will significantly reduce the amount of effort
involved in the inspection.
Deskchecks
•
Unlike an inspection, a deskcheckdoes not
produce written logs which can be archived with
the document for later reference.
•
Deskcheckscan be used as predecessors to
•
Deskcheckscan be used as predecessors to
inspections.
•
In many cases, having an author of a work
product pass his work to a peer for an informal
review will significantly reduce the amount of effort
involved in the inspection.
Types of Review:
Walkthroughs
•
A walkthrough is an informal way of presenting a
technical document in a meeting.
•
Unlike other kinds of reviews, the author runs the
walkthrough: calling the meeting, inviting the
reviewers, soliciting comments and ensuring that reviewers, soliciting comments and ensuring that
everyone present understands the work product.
•
After the meeting, the author should follow up with
individual attendees who may have had additional
information or insights.
•
The document should then be corrected to reflect
any issues that were raised.
Walkthroughs
•
A walkthrough is an informal way of presenting a
technical document in a meeting.
•
Unlike other kinds of reviews, the author runs the
walkthrough: calling the meeting, inviting the
reviewers, soliciting comments and ensuring that reviewers, soliciting comments and ensuring that
everyone present understands the work product.
•
After the meeting, the author should follow up with
individual attendees who may have had additional
information or insights.
•
The document should then be corrected to reflect
any issues that were raised.
Types of Review:
Code Review
•
A code review is a special kind of inspection in which
the team examines a sample of code and fixes any
defects in it.
•
In a code review, a defect is a block of code
•
which does not properly implement its requirements.
•
which does not function as the programmer intended.
•
which is not incorrect but could be improved . For
example, it could be made more readable or its
performance could be improved
Code Review
•
A code review is a special kind of inspection in which
the team examines a sample of code and fixes any
defects in it.
•
In a code review, a defect is a block of code
•
which does not properly implement its requirements.
•
which does not function as the programmer intended.
•
which is not incorrect but could be improved . For
example, it could be made more readable or its
performance could be improved
Types of Review:
Code Review
•
It’s important to review the code which is most
likely to have defects.
•
Good candidates for code review include:
•
A portion of the software that only one person has the
expertise to maintain.expertise to maintain.
•
Code that implements a highly abstract or tricky algorithm
•
An object, library or API that is particularly difficult to work
with.
•
Code written by inexperienced persons, or entirely new type
of code, or code written in an unfamiliar language
•
Code which employs a new programming technique
•
An area of the code that will be especially catastrophic if there
are defects
Code Review
•
It’s important to review the code which is most
likely to have defects.
•
Good candidates for code review include:
•
A portion of the software that only one person has the
expertise to maintain.expertise to maintain.
•
Code that implements a highly abstract or tricky algorithm
•
An object, library or API that is particularly difficult to work
with.
•
Code written by inexperienced persons, or entirely new type
of code, or code written in an unfamiliar language
•
Code which employs a new programming technique
•
An area of the code that will be especially catastrophic if there
are defects
Types of Review:
Pair Programming
•
Pair programming is a technique in which two
programmers work simultaneously at a single
computer and continuously review each others’
work.
Although many programmers were introduced to
•
Although many programmers were introduced to
pair programming, it is a practice that can be
valuable in any development environment.
•
Pair programming improves the organization by
ensuring that at least two programmers are able to
maintain any piece of the software.
Pair Programming
•
Pair programming is a technique in which two
programmers work simultaneously at a single
computer and continuously review each others’
work.
Although many programmers were introduced to
•
Although many programmers were introduced to
pair programming, it is a practice that can be
valuable in any development environment.
•
Pair programming improves the organization by
ensuring that at least two programmers are able to
maintain any piece of the software.
Types of Review:
Pair Programming
•
Pair programming works best if the pairs are
constantly rotated. Prefer to pair a junior person
with a senior for knowledge sharing.
•
The project manager should not try to force pair
programming on the team; it helps to introduce the programming on the team; it helps to introduce the
change slowly, and where it will meet the least
resistance.
•
It is difficult to implement pair programming in an
organization where programmers do not share the
same nine-to-five work schedule.
•
Some people do not work well in pairs, and some
pairs do not work well together.
Pair Programming
•
Pair programming works best if the pairs are
constantly rotated. Prefer to pair a junior person
with a senior for knowledge sharing.
•
The project manager should not try to force pair
programming on the team; it helps to introduce the programming on the team; it helps to introduce the
change slowly, and where it will meet the least
resistance.
•
It is difficult to implement pair programming in an
organization where programmers do not share the
same nine-to-five work schedule.
•
Some people do not work well in pairs, and some
pairs do not work well together.
Relative Cost of Defect Removal
Relative Cost of Defect Removal
Defect Amplification Model
Defect Prevention/ Removal
•
S/w contains 200K lines
•
Inspection time = 7053 Hrs.
•
Defects prevented = 3112
•
Programmer cost = 40.00 per hr.
•
Total cost of defect prevention = 7053 x 40.00
•
Total cost of defect prevention = 7053 x 40.00
= 282120.00
•
Cost per defect prevention = 2120/3112
= 91.00
•
S/w contains 200K lines
•
Inspection time = 7053 Hrs.
•
Defects prevented = 3112
•
Programmer cost = 40.00 per hr.
•
Total cost of defect prevention = 7053 x 40.00
•
Total cost of defect prevention = 7053 x 40.00
= 282120.00
•
Cost per defect prevention = 2120/3112
= 91.00
Defect Removal
•
Defect escaped into product = 1 per 1K
•
Total defects escaped = 200K/1000
= 200
Cost of removal of single defect = 25000
•
Cost of removal of single defect = 25000
•
Total defect removal cost = 25000 x 200
= 5000000
•
Ratio of defect removal to prevention = 18
•
Defect escaped into product = 1 per 1K
•
Total defects escaped = 200K/1000
= 200
Cost of removal of single defect = 25000
•
Cost of removal of single defect = 25000
•
Total defect removal cost = 25000 x 200
= 5000000
•
Ratio of defect removal to prevention = 18
Formality and Timing
•
Formal review presentations
•
resemble conference presentations.
•
Informal presentations
•
less detailed, but equally correct.less detailed, but equally correct.
•
Early Reviews
•
tend to be informal
•
may not have enough information
•
Later Reviews
•
tend to be more formal
•
Feedback may come too late to avoid rework
•
Formal review presentations
•
resemble conference presentations.
•
Informal presentations
•
less detailed, but equally correct.less detailed, but equally correct.
•
Early Reviews
•
tend to be informal
•
may not have enough information
•
Later Reviews
•
tend to be more formal
•
Feedback may come too late to avoid rework
Formality and Timing
•
Analysis is complete.
•
Design is complete.
•
After first compilation.
•
After first test run.
•
After first test run.
•
After all test runs.
•
Any time you complete an activity that produce a
complete work product.
•
Analysis is complete.
•
Design is complete.
•
After first compilation.
•
After first test run.
•
After first test run.
•
After all test runs.
•
Any time you complete an activity that produce a
complete work product.
Review Guidelines
•
Keep it short (< 30 minutes).
•
Don’t schedule two in a row.
•
Don’t review product fragments.
•
Use standards to avoid style disagreements.
•
Use standards to avoid style disagreements.
•
Let the coordinator run the meeting and
maintain order.
•
Keep it short (< 30 minutes).
•
Don’t schedule two in a row.
•
Don’t review product fragments.
•
Use standards to avoid style disagreements.
•
Use standards to avoid style disagreements.
•
Let the coordinator run the meeting and
maintain order.
Scope Creep Effect
Scope Creep
Scope Creep
•
After the programming has started, users and
stakeholders make changes.
•
Each change is easy to describe, so it sounds
“small” and the programmers agree to it.“small” and the programmers agree to it.
•
Eventually, the project slows to a crawl
•
It’s 90% done –with 90% left to go
•
The programmers know that if they had been
told from the beginning what to build, they
could have built it quickly from the start.
•
After the programming has started, users and
stakeholders make changes.
•
Each change is easy to describe, so it sounds
“small” and the programmers agree to it.“small” and the programmers agree to it.
•
Eventually, the project slows to a crawl
•
It’s 90% done –with 90% left to go
•
The programmers know that if they had been
told from the beginning what to build, they
could have built it quickly from the start.
Categories
TechnologyDownload
Download Slideshow Get the original presentation fileQuick Actions
Statistics
- Views 489
- Slides 116
- Age 560 days
Related Slideshows
11
8-top-ai-courses-for-customer-support-representatives-in-2025.pptx
JeroenErne2
44 views
10
7-essential-ai-courses-for-call-center-supervisors-in-2025.pptx
JeroenErne2
45 views
13
25-essential-ai-courses-for-user-support-specialists-in-2025.pptx
JeroenErne2
36 views
11
8-essential-ai-courses-for-insurance-customer-service-representatives-in-2025.pptx
JeroenErne2
33 views
21
Know for Certain
DaveSinNM
19 views
17
PPT OPD LES 3ertt4t4tqqqe23e3e3rq2qq232.pptx
novasedanayoga46
23 views