Module IV (1).pptx for software emgineee

2
Module IV :Software Reliability, Testing
and Maintenance
S. No Topic
1. Failure and Faults
2 Reliability Models: Basic Model,
Logarithmic Poisson Model
3 Software process
4 Functional testing: Boundary value
analysis, Equivalence class testing,
Decision table testing, Cause effect
graphing Structural testing: path testing
5 Data flow and mutation testing, unit
testing, integration and system testing,
Debugging, Testing Tools, & Standards.
6 Management of maintenance,
Maintenance Process, Maintenance
Models, Reverse Engineering, Software
REengineering

Software Reliability
Basic Concepts
There are three phases in the life of any hardware component i.e.,
burn-in, useful life & wear-out.
In burn-in phase, failure rate is quite high initially, and it starts
decreasing gradually as the time progresses.
During useful life period, failure rate is approximately constant.
Failure rate increase in wear-out phase due to wearing out/aging of
components. The best period is useful life period. The shape of this
curve is like a “bath tub” and that is why it is known as bath tub
curve. The “bath tub curve” is given in Fig.7.1.
2

Fig. 7.1: Bath tub curve of hardware reliability.
3

Fig. 7.2: Software reliability curve (failure rate versus time)
We do not have wear out phase in software. The expected curve for
software is given in fig. 7.2.
4

Software may be retired only if it becomes obsolete. Some of
contributing factors are given below:
✓ change in environment
✓ change in infrastructure/technology
✓ major change in requirements
✓ increase in complexity
✓ extremely difficult to maintain
✓ deterioration in structure of the code
✓ slow execution speed
✓ poor graphical user interfaces
5

What is Software Reliability?
“Software reliability means operational reliability. Who cares how
many bugs are in the program?
As per IEEE standard: “Software reliability is defined as the ability of
a system or component to perform its required functions under
stated conditions for a specified period of time”.
6

Software reliability is also defined as the probability that a software
system fulfills its assigned task in a given environment for a
predefined number of input cases, assuming that the hardware and
the inputs are free of error.
“It is the probability of a failure free operation of a program for a
specified time in a specified environment”.
7

▪ Failures and Faults
A fault is the defect in the program that, when executed under
particular conditions, causes a failure.
The execution time for a program is the time that is actually spent by
a processor in executing the instructions of that program. The
second kind of time is calendar time. It is the familiar time that we
normally experience.
8

There are four general ways of characterising failure occurrences in
time:
1. time of failure,
2. time interval between failures,
3. cumulative failure experienced up to a given time,
4. failures experienced in a time interval.
9

Failure Number Failure Time (sec) Failure interval (sec)
1 8 8
2 18 10
3 25 7
4 36 11
5 45 9
6 57 12
7 71 14
8 86 15
9 104 18
10 124 20
11 143 19
12 169 26
13 197 28
14 222 25
15 250 28
10
Table 7.1: Time based failure specification

Time (sec) Cumulative Failures Failure in interval (30 sec)
30 3 3
60 6 3
90 8 2
120 9 1
150 11 2
180 12 1
210 13 1
240 14 1
11
Table 7.2: Failure based failure specification

12
Value of
random
variable
(failures in time
period)
Probability
Elapsed time tA = 1 hr Elapsed time tB = 5 hr
0 0.10 0.01
1 0.18 0.02
2 0.22 0.03
3 0.16 0.04
4 0.11 0.05
5 0.08 0.07
6 0.05 0.09
7 0.04 0.12
8 0.03 0.16
9 0.02 0.13
Table 7.3: Probability distribution at times tA and tB

Value of
random
variable
(failures in time
period)
Probability
Elapsed time tA = 1 hr Elapsed time tB = 5 hr
10 0.01 0.10
11 0 0.07
12 0 0.05
13 0 0.03
14 0 0.02
15 0 0.01
Mean failures 3.04 7.77
13
Table 7.3: Probability distribution at times tA and tB

A random process whose probability distribution varies with time to
time is called non-homogeneous. Most failure processes during test
fit this situation. Fig. 7.3 illustrates the mean value and the related
failure intensity functions at time tA and tB. Note that the mean
failures experienced increases from 3.04 to 7.77 between these two
points, while the failure intensity decreases.
Failure behavior is affected by two principal factors:
✓the number of faults in the software being executed.
✓the execution environment or the operational profile of
execution.
14

Fig. 7.3: Mean Value & failure intensity functions.
15

Environment
The environment is described by the operational profile. The
proportion of runs of various types may vary, depending on the
functional environment. Examples of a run type might be:
1. a particular transaction in an airline reservation system or a
business data processing system,
2. a specific cycle in a closed loop control system (for
example, in a chemical process industry),
3. a particular service performed by an operating system for a
user.
16

The run types required of the program by the environment can be
viewed as being selected randomly. Thus, we define the operational
profile as the set of run types that the program can execute along
with possibilities with which they will occur. In fig. 7.4, we show two
of many possible input states A and B, with their probabilities of
occurrence.
The part of the operational profile for just these two states is shown
in fig. 7.5. A realistic operational profile is illustrated in fig.7.6.
17

Fig. 7.4: Input Space
18

Fig. 7.5: Portion of operational profile
19

Fig. 7.6: Operational profile
20

Fig. 7.7: Reliability and failure intensity
Fig.7.7 shows how failure intensity and reliability typically vary
during a test period, as faults are removed.
21

Uses of Reliability Studies
There are at least four other ways in which software reliability
measures can be of great value to the software engineer, manager
or user.
1. you can use software reliability measures to evaluate software
engineering technology quantitatively.
22
2. software
evaluating
project.
reliability measures offer you the possibility of
development status during the test phases of a

3. one can use software reliability measures to monitor the
operational performance of software and to control new features
added and design changes made to the software.
4. a quantitative understanding of software quality and the various
factors influencing it and affected by it enriches into the
software product and the software development process.
23

Software Quality
Different people understand different meanings of quality like:
❖ conformance to requirements
❖ fitness for the purpose
❖ level of satisfaction
24

Fig 7.8: Software quality attributes
26

1 Reliability The extent to which a software performs its
intended functions without failure.
2 Correctness The extent to which a software
meets its specifications.
3 Consistency
& precision
The extent to which a software is consistent and
give results with precision.
4 Robustness The extent to which a software
tolerates the unexpected problems.
5 Simplicity The extent to which a software is simple
in its operations.
6 Traceability The extent to which an error is traceable in order
to fix it.
7 Usability The extent of effort required to learn, operate
and understand the functions of the software
27

8 Accuracy Meeting specifications with precision.
9 Clarity &
Accuracy of
documentatio
n
The extent to which documents are clearly &
accurately written.
10 Conformity
of
operational
environment
The extent to which a software is in
conformity of operational environment.
11 Completeness The extent to which a software has specified functions.
12 Efficiency The amount of computing resources and code
required by software to perform a function.
13 Testability The effort required to test a software to ensure that
it performs its intended functions.
14 Maintainability The effort required to locate and fix an error
during maintenance phase.
28

29
15 Modularity It is the extent of ease to implement, test, debug
and maintain the software.
16 Readability The extent to which a software is readable in order
to understand.
17 Adaptability The extent to which a software is adaptable to
new platforms & technologies.
18 Modifiability The effort required to modify a software
during maintenance phase.
19 Expandability The extent to which a software is expandable
without undesirable side effects.
20 Portability The effort required to transfer a program from
one platform to another platform.
Table 7.4: Software quality attributes

Fig 7.9: Software quality factors
30
▪ McCall Software Quality Model

to the operation of a product are
31
combined. The factors are:
▪ Correctness
▪ Efficiency
▪ Integrity
▪ Reliability
▪ Usability
i. Product Operation
Factors which are related
These five factors are related to operational performance,
convenience, ease of usage and its correctness. These factors play
a very significant role in building customer’s satisfaction.

ii. Product Revision
The factors which are required for testing & maintenance are
combined and are given below:
▪ Maintainability
▪ Flexibility
▪ Testability
These factors pertain to the testing & maintainability of software.
They give us idea about ease of maintenance, flexibility and testing
effort. Hence, they are combined under the umbrella of product
revision.
32

iii. Product Transition
We may have to transfer a product from one platform to an other
platform or from one technology to another technology. The factors
related to such a transfer are combined and given below:
▪ Portability
▪ Reusability
▪ Interoperability
33

Most of the quality factors are explained in table 7.4. The remaining
factors are given in table 7.5.
34
Sr.No. Quality Factors Purpose
1 Integrity The extent to which access to software or data
by the unauthorized persons can be controlled.
2 Flexibility The effort required to modify an operational program.
3 Reusability The extent to which a program can be reused
in other applications.
4 Interoperability The effort required to couple one system
with another.
Table 7.5: Remaining quality factors (other are in table 7.4)

Fig 7.10: McCall’s quality model
35
Quality criteria

Table 7.5(a):
Relation
between quality
factors and
quality criteria
36

1 Operability The ease of operation of the software.
2 Training The ease with which new users can
use the system.
3 Communicativeness The ease with which inputs and outputs can
be assimilated.
4 I/O volume It is related to the I/O volume.
5 I/O rate It is the indication of I/O rate.
6 Access control The provisions for control and protection
of the software and data.
7 Access audit The ease with which software and data can be
checked for compliance with standards or other
requirements.
8 Storage efficiency The run time storage requirements of the software.
9 Execution efficiency The run-time efficiency of the software.
37

10 Traceability The ability
requirements
.
to link software components to
11 Completeness The degree to which a full implementation
of the required functionality has been
achieved.
12 Accuracy The precision of computations and output.
13 Error tolerance The degree to which continuity of operation is
ensured under adverse conditions.
14 Consistency The use of uniform design and
implementation techniques and notations
throughout a project.
15 Simplicity The ease with which the software can be understood.
16 Conciseness The compactness of the source code, in terms of
lines of code.
17 Instrumentation The degree to which the software
provides for measurements of its use or
identification of errors.
38

39
18 Expandability The degree to which storage
requirements or software functions can be
expanded.
19 Generability The breadth of the potential application of
software components.
20 Self-
descriptivenes
s
The degree to which the documents
are self explanatory.
21 Modularity The provision of highly independent modules.
22 Machine
independenc
e
The degree to which software is dependent on
its associated hardware.
23 Software
system
independence
The degree to which software is independent of
its environment.
24 Communicatio
n
commonality
The degree to which standard protocols
and interfaces are used.
25 Data commonality The use of standard data representations.
Table 7.5 (b): Software quality criteria

▪ Boehm Software Quality Model
40
Fig.7.11: The Boehm software quality model

41
ISO 9126
▪ Functionality
▪ Reliability
▪ Usability
▪ Efficiency
▪ Maintainability
▪ Portability

Characteristi
c/
Attribute
Short Description of the Characteristics and
the concerns Addressed by Attributes
Functionality Characteristics relating to achievement of the
basic purpose for which the software
is being engineered
• Suitability The presence and appropriateness of a set of functions
for specified tasks
• Accuracy The provision of right or agreed results or effects
• Interoperability Software’s ability to interact with specified systems
• Security Ability to prevent unauthorized access, whether
accidental or deliberate, to program and data.
Reliability Characteristics relating to capability of software to
maintain its level of performance under stated conditions
for a stated period of time
• Maturity Attributes of software that bear on the frequency of
failure by faults in the software
42

• Fault tolerance Ability to maintain a specified level of performance in
cases of software faults or unexpected inputs
• Recoverability Capability and effort needed to reestablish level of
performance and recover affected data after possible
failure.
Usability Characteristics relating to the effort needed for use, and on
the individual assessment of such use, by a stated implied
set of users.
• Understandability The effort required for a user to recognize the
logical concept and its applicability.
• Learnability The effort required for a user to learn its
application, operation, input and output.
• Operability The ease of operation and control by users.
Efficiency Characteristic related to the relationship between the level
of performance of the software and the amount of
resources used, under stated conditions.
43

• Time behavior The speed of response and processing
times and throughout rates in performing its
function.
• Resour
ce
behavio
r
The amount of resources used and the duration of
such use in performing its function.
Maintainability Characteristics related to the effort needed to make
modifications, including corrections, improvements or
adaptation of software to changes in environment,
requirements and functions specifications.
• Analyzability The effort needed for diagnosis of deficiencies or
causes of failures, or for identification of parts to be
modified.
• Changeability The effort needed for modification, fault removal or
for environmental change.
• Stability The risk of unexpected effect of modifications.
• Testability The effort needed for validating the modified software. 44

45
Portability Characteristics related to the ability to transfer the
software from one organization or hardware or software
environment to another.
• Adaptability The opportunity for its adaptation to different specified
environments.
• Installability The effort needed to install the software in a
specified environment.
• Conformance The extent to which it adheres to
standards or conventions relating to portability.
• Replaceability The opportunity and effort of using it in the place of
other software in a particular environment.
Table 7.6: Software quality characteristics and attributes – The ISO 9126
view

Fig.7.12: ISO 9126 quality model
46

Example- 7.1
Assume that a program will experience 200 failures in infinite time. It has
now experienced 100. The initial failure intensity was 20 failures/CPU hr.
(i) Determine the current failure intensity.
(ii) Find the decrement of failure intensity per failure.
(iii)Calculate the failures experienced and failure intensity after 20 and 100
CPU hrs. of execution.
(iv)Compute addition failures and additional execution time required to
reach the failure intensity objective of 5 failures/CPU hr.
Use the basic execution time model for the above mentioned calculations.
Software
Reliability
53

Example- 7.2
Assume that the initial failure intensity is 20 failures/CPU hr. The failure
intensity decay parameter is 0.02/failures. We have experienced 100
failures up to this time.
(i) Determine the current failure intensity.
(ii) Calculate the decrement of failure intensity per failure.
(iii)Find the failures experienced and failure intensity after 20 and 100 CPU
hrs. of execution.
(iv)Compute the additional failures and additional execution time required to
reach the failure intensity objective of 2 failures/CPU hr.
Use Logarithmic Poisson execution time model for the above mentioned
calculations.
62

Solution
0  20 failures/CPU hr.
 100 failures
  0.02/ failures
(i) Current failure intensity:
()  0 exp()
= 20 exp (-0.02 x 100)
= 2.7 failures/CPU hr.
63

(ii) Decrement of failure intensity per failure can be calculated as:
d
d
 θλ
0

() 
1
Ln  1
= -.02 x 2.7 = -.054/CPU hr.
(iii) (a) Failures experienced & failure intensity after 20 CPU hr:
Ln(200.0220 1) 109 failures
64
0.02
1


()  0 /0 1
 (20)/(20.0220 1)  2.22 failures /CPU hr.
(b) Failures experienced & failure intensity after 100 CPU hr:
0

() 
1
Ln  1
Ln(200.021001) 186 failures
65
0.02
1

()  0 /0 1
 (20)/(20.021001)  0.4878 failures /CPU hr.

2
 F 0.02
 
1
Ln
P

1
Ln
2.7
15 failures
(iv) Additional failures  required to reach the failure intensity
objective of 2 failures/CPU hr.
2.7
66
1
0.02 2
1 1 1
  6.5 CPU hr.
 
P
1 1
 F
 

Example- 7.3
The following parameters for basic and logarithmic Poisson models are
given:
(a) Determine the addition failures and additional execution time required to
reach the failure intensity objective of 5 failures/CPU hr. for both models.
(b) Repeat this for an objective function of 0.5 failure/CPU hr. Assume that
we start with the initial failure intensity only.
67
Basic execution time model Logarithmic
Poisson execution
time model
 10 failures/CPU hr
o
  30 failures/CPU hr
o
V 100 failures
o
  0.25/failure

Solution
(a) (i) Basic execution time model
Software
Reliability
0
P F

 
V0
(   )
0

P
  Ln
0 F
V0
P
10
68

100
(10 5)  50 failures
(Present failure intensity) in this case is same as (initial
failure intensity).
Now,

Software
Reliability
(ii) Logarithmic execution time model
10 5

100
Ln
10
 6.93 CPU hr.
F

P
  Ln

1
0.025 5

1
Ln
30
 71.67 Failures
69
P
1
 F
1 1

 
0.025 5 30

1
Ln
1

1
 6.66 CPU hr.

Software
Reliability
Logarithmic model has calculated more failures in almost some duration of
execution time initially.
(b) Failure intensity objective F = 0.5 failures/CPU hr.
(i) Basic execution time model
P

    F 
0

100
(10  0.5)  95 failures
10

70
V0 P
  Ln
0 F
V0
10 0.05

100
Ln
10
 30 CPU/hr

Software
Reliability
F
  Ln

P
1
θ
0.025 0.5

1
L
n
30
164 failures
(ii) Logarithmic execution time model
71

F P
 

1
θ 
1 1
0.025 0.5 30

1 1

1
 78.66 CPU/hr

▪ Calendar Time Component
The calendar time component is based on a debugging process
model. This model takes into account:
1. resources used in operating the program for a given
execution time and processing an associated quantity of
failure.
2. resources quantities available, and
3. the degree to which a resource can be utilized (due to
bottlenecks) during the period in which it is limiting.
Table 7.7 will help in visualizing these different aspects of the
resources, and the parameters that result.
72
Software
Reliability

Software
Reliability
73
Usage
parameters
requirements
per
Planned parameters
Resource CPU hr Failure Quantitie
s
available
Utilisation
Failure
identification
personnel
I µI PI 1
Failure
correction
personnel
0 µf Pf Pf
Computer time c µc Pc Pc
Fig. : Calendar time component resources and parameters
Resource usage

SoftwareReliability
74
S
o
f
t
w
a
r
e
E
n
g
i
n
e
e
r
i
n
g
(
3
r
d
e
d
.
)
,
B
y
K
.
K
A
g
g
a
r
w
a
l
&
Y
o
g
e
s
h
S
i
n
g
h
,
C
o
p
y
r
i
g
h
t
©
N
e
w
XC  c c
X f  f 
XI  I  I 
Hence, to be more precise, we have
(for computer time)
(for failure correction)
(for failure identification)
dxT / d r  r

Software
Reliability
75
Calendar time to execution time relationship
dt / d  (1/ Pr pr )dxT / d
dt / d  (r  r) / Pr pr

Software
Reliability
Fig.7.20: Instantaneous calendar time to execution time ratio
76

Software
Reliability
Fig.7.21: Calendar time to execution time ratio for different
limiting resources
77

Example- 7.4
A team run test cases for 10 CPU hrs and identifies 25 failures. The effort
required per hour of execution time is 5 person hr. Each failure requires 2
hr. on an average to verify and determine its nature. Calculate the failure
identification effort required.
Software
Reliability
78

Solution
As we know, resource usage is:
Xr r  r 
Software
Reliability
79
θr 15 person hr.
 10 CPU hrs.
Here
Hence,
  25 failures
r  2 hrs./failure
Xr = 5 (10) + 2 (25)
= 50 + 50 = 100 person hr.

Example- 7.5
Initial failure intensity (0 ) for a given software is 20 failures/CPU hr. The
failure intensity objective (F ) of 1 failure/CPU hr. is to be achieved.
Assume the following resource usage parameters.
Software
Reliability
80
Resource Usage Per hour Per failure
Failure identification effort 2 Person hr. 1 Person hr.
Failure Correction effort 0 5 Person hr.
Computer time 1.5 CPU hr. 1 CPU hr.

(a)What resources must be expended to achieve the reliability
improvement? Use the logarithmic Poisson execution time model with a
failure intensity decay parameter of 0.025/failure.
(b)If the failure intensity objective is cut to half, what is the effect on
requirement of resources ?
Software
Reliability
81

Solution
Software
Reliability
(a)
F
  Ln

P
1

0.025 1

1
Ln
20
119 failures
82
P
1
 F
1 1

 
0.025 1 20 0.025

1 1

1

1
1 0.05 38 CPU hrs.

Software
Reliability
83
Hence X1  1 θ1
= 1 (119) + 2 (38) = 195 Person hrs.
XF  F
= 5 (119) = 595 Person hrs.
XC  cθc
= 1 (119) + (1.5) (38) = 176 CPU hr.

Software
Reliability
84
(b) F  0.5 failures/CPU hr.
0.025 0.5
 
1
Ln
20
148 failures
0.025 0.5 20
 
1 1

1
 78 CPU hr.
So, XI = 1 (148) + 2 (78) = 304 Person hrs.
XF = 5 (148) = 740 Person hrs.
XC = 1 (148) + (1.5)(78) = 265 CPU hrs.

Hence, if we cut failure intensity objective to half, resources requirements
are not doubled but they are some what less. Note that is
approximately doubled but increases logarithmically. Thus, the resources
increase will be between a logarithmic increase and a linear increase for
changes in failure intensity objective.
Software
Reliability
85


Example- 7.6
A program is expected to have 500 faults. It is also assumed that one fault
may lead to one failure only. The initial failure intensity was 2 failures/CPU
hr. The program was to be released with a failure intensity objective of 5
failures/100 CPU hr. Calculated the number of failure experienced before
release.
Software
Reliability
86

Solution
The number of failure experienced during testing can be calculated using
the equation mentioned below:
Software
Reliability
P F
87
0
 
V0
   
V0  500 because one fault leads to one failure
0  2 failures/CPU hr.
F  5 failures/100 CPU hr.
 0.05 failures/CPU hr.
Here

Software
Reliability
So
2
88
 
500
2  0.05
= 487 failures
Hence 13 faults are expected to remain at the release instant of
the software.

• What is Testing?
Many people understand many definitions of testing :
1. Testing is the process of demonstrating that errors are not present.
2. The purpose of testing is to show that a program performs its intended
functions correctly.
3. Testing is the process of establishing confidence that a program does
what it is supposed to do.
These definitions are incorrect.
Software Testing
2

A more appropriate definition is:
“Testing is the process of executing a program with
the intent of finding errors.”
Software Testing
3

Software Testing
• Why should We Test ?
Although software testing is itself an expensive activity, yet launching of
software without testing may lead to cost potentially much higher than that
of testing, specially in systems where human safety is involved.
In the software life cycle the earlier the errors are discovered and removed,
the lower is the cost of their removal.
4

Software Testing
• Who should Do the Testing ?
o Testing requires the developers to find errors from their software.
o It is difficult for software developer to point out errors from own
creations.
o Many organisations have made a distinction between development
and testing phase by making different people responsible for each
phase.
5

Software Testing
• What should We Test ?
6
We should test the program’s responses to every possible input. It means,
we should test for all valid and invalid inputs. Suppose a program requires
two 8 bit integers as inputs. Total possible combinations are 28x28. If only
one second it required to execute one set of inputs, it may take 18 hours to
test all combinations. Practically, inputs are more than two and size is also
more than 8 bits. We have also not considered invalid inputs where so
many combinations are possible. Hence, complete testing is just not
possible, although, we may wish to do so.

Software Testing
Some Terminologies
➢ Error, Mistake, Bug, Fault and Failure
People make errors. A good synonym is mistake. This may be a syntax
error or misunderstanding of specifications. Sometimes, there are logical
errors.
When developers make mistakes while coding, we call these mistakes
“bugs”.
A fault is the representation of an error, where representation is the mode
of expression, such as narrative text, data flow diagrams, ER diagrams,
source code etc. Defect is a good synonym for fault.
A failure occurs when a fault executes. A particular fault may cause
different failures, depending on how it has been exercised.
9

Software Testing
➢ Test, Test Case and Test Suite
Test and Test case terms are used interchangeably. In practice, both are
same and are treated as synonyms. Test case describes an input
description and an expected output description.
10
Test Case ID
Section-I
(Before Execution)
Section-II
(After Execution)
Purpose : Execution History:
Pre condition: (If any) Result:
Inputs: If fails, any possible reason (Optional);
Expected Outputs: Any other observation:
Post conditions: Any suggestion:
Written by: Run by:
Date: Date:
Fig. 2: Test case template
The set of test cases is called a test suite. Hence any combination of test
cases may generate a test suite.

Software Testing
➢ Verification and Validation
Verification is the process of evaluating a system or component to
determine whether the products of a given development phase satisfy the
conditions imposed at the start of that phase.
Validation is the process of evaluating a system or component during or at
11
the end of development process to determine whether it satisfies the
specified requirements .
Testing= Verification+Validation

Software Testing
➢ Alpha, Beta and Acceptance Testing
The term Acceptance Testing is used when the software is developed for
a specific customer. A series of tests are conducted to enable the customer
to validate all requirements. These tests are conducted by the end user /
customer and may range from adhoc tests to well planned systematic
series of tests.
The terms alpha and beta testing are used when the software is developed
as a product for anonymous customers.
Alpha Tests are conducted at the developer’s site by some potential
customers. These tests are conducted in a controlled environment. Alpha
testing may be started when formal testing process is near completion.
Beta Tests are conducted by the customers / end users at their sites.
Unlike alpha testing, developer is not present here. Beta testing is
conducted in a real environment that cannot be controlled by the developer.
12

Software Testing
Input test
data
System
under
test
Output
test data
Input
domain
Output
domain
Functional Testing
13
Fig. 3: Black box testing

Software Testing
Fig.4: Input domain for program having two input variables
Boundary Value Analysis
Consider a program with two input variables x and y. These input variables
have specified boundaries as:
a ≤ x ≤ b
c ≤ y ≤ d
Input domain
d
y
c
a b
x
14

Software Testing
The boundary value analysis test cases for our program with two inputs
variables (x and y) that may have any value from 100 to 300 are: (200,100),
(200,101), (200,200), (200,299), (200,300), (100,200), (101,200), (299,200) and
(300,200). This input domain is shown in Fig. 8.5. Each dot represent a test case
and inner rectangle is the domain of legitimate inputs. Thus, for a program of n
variables, boundary value analysis yield 4n + 1 test cases.
Input domain
400
300
y 200
100
0 100 200 300 400
x
Fig. 5: Input domain of two variables x and y with
boundaries [100,300] each
15

Software Testing
Example- 8.I
Consider a program for the determination of the nature of roots of a
quadratic equation. Its input is a triple of positive integers (say a,b,c) and
values may be from interval [0,100]. The program output may have one of
the following words.
[Not a quadratic equation; Real roots; Imaginary roots; Equal roots]
Design the boundary value test cases.
16

Software Testing
Solution
Quadratic equation will be of type:
ax2+bx+c=0
Roots are real if (b2-4ac)>0
Roots are imaginary if (b2-4ac)<0
Roots are equal if (b2-4ac)=0
Equation is not quadratic if a=0
17

Software Testing
The boundary value test cases are :
18
Test Case a b c Expected output
1 0 50 50 Not Quadratic
2 1 50 50 Real Roots
3 50 50 50 Imaginary Roots
9 50 100 50 Equal Roots

Software Testing
Example – 8.2
Consider a program for determining the Previous date. Its input is a triple of
day, month and year with the values in the range
1 ≤ month ≤ 12
1 ≤ day ≤ 31
1900 ≤ year ≤ 2025
The possible outputs would be Previous date or invalid input date. Design the
boundary value test cases.
19

Software Testing
Solution
The Previous date program takes a date as input and checks it for validity.
If valid, it returns the previous date as its output.
With single fault assumption theory, 4n+1 test cases can be designed and
which are equal to 13.
20

Software Testing
The boundary value test cases are:
21
Test Case Month Day Year Expected output
1 6 15 1900 14 June, 1900
2 6 15 1901 14 June, 1901
3 6 15 1962 14 June, 1962
4 6 15 2024 14 June, 2024
5 6 15 2025 14 June, 2025
6 6 1 1962 31 May, 1962
7 6 2 1962 1 June, 1962
8 6 30 1962 29 June, 1962
9 6 31 1962 Invalid date
10 1 15 1962 14 January, 1962
11 2 15 1962 14 February, 1962
12 11 15 1962 14 November, 1962
13 12 15 1962 14 December, 1962

Software Testing
Example – 8.3
Consider a simple program to classify a triangle. Its inputs is a triple of
positive integers (say x, y, z) and the date type for input parameters ensures
that these will be integers greater than 0 and less than or equal to 100. The
program output may be one of the following words:
[Scalene; Isosceles; Equilateral; Not a triangle]
Design the boundary value test cases.
22

Software Testing
Solution
The boundary value test cases are shown below:
23
Test case x y z Expected Output
1 50 50 1 Isosceles
2 50 50 2 Isosceles
3 50 50 50 Equilateral
4 50 50 99 Isosceles
5 50 50 100 Not a triangle
6 50 1 50 Isosceles
7 50 2 50 Isosceles

Robustness testing
It is nothing but the extension of boundary value analysis. Here, we would
like to see, what happens when the extreme values are exceeded with a
value slightly greater than the maximum, and a value slightly less than
minimum. It means, we want to go outside the legitimate boundary of input
domain. This extended form of boundary value analysis is called
robustness testing and shown in Fig. 6
There are four additional test cases which are outside the legitimate input
domain. Hence total test cases in robustness testing are 6n+1, where n is
the number of input variables. So, 13 test cases are:
(200,99), (200,100), (200,101), (200,200), (200,299), (200,300)
(200,301), (99,200), (100,200), (101,200), (299,200), (300,200), (301,200)
Software Testing
24

Software Testing
Fig. 8.6: Robustness test cases for two variables x
and y with range [100,300] each
y
400
300
200
100
0 100 200 300
x
400
25

Worst-case testing
If we reject “single fault” assumption theory of reliability and may like to see
what happens when more than one variable has an extreme value. In
electronic circuits analysis, this is called “worst case analysis”. It is more
thorough in the sense that boundary value test cases are a proper subset
of worst case test cases. It requires more effort. Worst case testing for a
function of n variables generate 5n test cases as opposed to 4n+1 test
cases for boundary value analysis. Our two variables example will have
52=25 test cases and are given in table 1.
Software Testing
26

Software Testing
Test case
number
Inputs Test case
number
Inputs
x y x y
1 100 100 14 200 299
2 100 101 15 200 300
3 100 200 16 299 100
4 100 299 17 299 101
5 100 300 18 299 200
6 101 100 19 299 299
7 101 101 20 299 300
8 101 200 21 300 100
9 101 299 22 300 101
10 101 300 23 300 200
11 200 100 24 300 299
12 200 101 25 300 300
13 200 200 --
27
Table 1: Worst cases test inputs for two variables example

Software Testing
Example - 8.4
Consider the program for the determination of nature of roots of a quadratic
equation as explained in example 8.1. Design the Robust test case and worst
test cases for this program.
28

Software Testing
Solution
Robust test cases are 6n+1. Hence, in 3 variable input cases total number
of test cases are 19 as given on next slide:
29

30
So
ftw
a
r
eT
estin
g
Test case a b c Expected Output
1 -1 50 50 Invalid input`
2 0 50 50 Not quadratic equation
3 1 50 50 Real roots
4 50 50 50 Imaginary roots
7 101 50 50 Invalid input
8 50 -1 50 Invalid input
12 50 100 50 Equal roots
14 50 50 -1 Invalid input

Software Testing
In case of worst test case total test cases are 5n. Hence, 125 test cases will be
generated in worst test cases. The worst test cases are given below:
31

Software Testing
Test Case A b c Expected output
27 1 0 1 Imaginary
28 1 0 50 Imaginary
29 1 0 99 Imaginary
30 1 0 100 Imaginary
31 1 1 0 Real Roots
32

Software Testing
Test Case A b C Expected output
32 1 1 1 Imaginary
33 1 1 50 Imaginary
34 1 1 99 Imaginary
44` 1 99 99 Real Roots
33

Software Testing
50 1 100 100 Real Roots
52 50 0 1 Imaginary
57 50 1 1 Imaginary
34

35
Software Testing
75 50 100 100 Imaginary
77 99 0 1 Imaginary
82 99 1 1 Imaginary

36
Software Testing
100 99 100 100 Imaginary

37
Software Testing
105 100 0 100 Imaginary
110 100 1 100 Imaginary
111 100 50 0 Real Roots
112 100 50 1 Real Roots
113 100 50 50 Imaginary
114 100 50 99 Imaginary
115 100 50 100 Imaginary
116 100 99 0 Real Roots
117 100 99 1 Real Roots
118 100 99 50 Imaginary

Software Testing
119 100 99 99 Imaginary
120 100 99 100 Imaginary
121 100 100 0 Real Roots
122 100 100 1 Real Roots
123 100 100 50 Imaginary
124 100 100 99 Imaginary
125 100 100 100 Imaginary
38

Software Testing
Example – 8.5
Consider the program for the determination of previous date in a calendar as
explained in example 8.2. Design the robust and worst test cases for this
program.
39

Software Testing
Solution
Robust test cases are 6n+1. Hence total 19 robust test cases are designed
and are given on next slide.
40

41
So
ftw
a
r
eT
estin
g
Test case Month Day Year Expected Output
1 6 15 1899 Invalid date (outside range)
2 6 15 1900 14 June, 1900
3 6 15 1901 14 June, 1901
4 6 15 1962 14 June, 1962
5 6 15 2024 14 June, 2024
6 6 15 2025 14 June, 2025
7 6 15 2026 Invalid date (outside range)
9 6 1 1962 31 May, 1962
10 6 2 1962 1 June, 1962
11 6 30 1962 29 June, 1962
15 1 15 1962 14 January, 1962
16 2 15 1962 14 February, 1962
17 11 15 1962 14 November, 1962
18 12 15 1962 14 December, 1962

Software Testing
In case of worst test case total test cases are 5n. Hence, 125 test cases will be
generated in worst test cases. The worst test cases are given below:
1 1 1 1900 31 December, 1899
2 1 1 1901 31 December, 1900
3 1 1 1962 31 December, 1961
4 1 1 2024 31 December, 2023
5 1 1 2025 31 December, 2024
6 1 2 1900 1 January, 1900
7 1 2 1901 1 January, 1901
8 1 2 1962 1 January, 1962
9 1 2 2024 1 January, 2024
10 1 2 2025 1 January, 2025
11 1 15 1900 14 January, 1900
12 1 15 1901 14 January, 1901
13 1 15 1962 14 January, 1962
14 1 15 2024 14 January, 2024
42

Software Testing
15 1 15 2025 14 January, 2025
16 1 30 1900 29 January, 1900
17 1 30 1901 29 January, 1901
18 1 30 1962 29 January, 1962
19 1 30 2024 29 January, 2024
20 1 30 2025 29 January, 2025
21 1 31 1900 30 January, 1900
22 1 31 1901 30 January, 1901
23 1 31 1962 30 January, 1962
24 1 31 2024 30 January, 2024
25 1 31 2025 30 January, 2025
26 2 1 1900 31 January, 1900
27 2 1 1901 31 January, 1901
28 2 1 1962 31 January, 1962
29 2 1 2024 31 January, 2024
30 2 1 2025 31 January, 2025
31 2 2 1900 1 February, 1900
43

Software Testing
32 2 2 1901 1 February, 1901
33 2 2 1962 1 February, 1962
34 2 2 2024 1 February, 2024
35 2 2 2025 1 February, 2025
36 2 15 1900 14 February, 1900
37 2 15 1901 14 February, 1901
38 2 15 1962 14 February, 1962
39 2 15 2024 14 February, 2024
40 2 15 2025 14 February, 2025
44

Software Testing
51 6 1 1900 31 May, 1900
52 6 1 1901 31 May, 1901
53 6 1 1962 31 May, 1962
54 6 1 2024 31 May, 2024
55 6 1 2025 31 May, 2025
56 6 2 1900 1 June, 1900
57 6 2 1901 1 June, 1901
58 6 2 1962 1 June, 1962
59 6 2 2024 1 June, 2024
60 6 2 2025 1 June, 2025
61 6 15 1900 14 June, 1900
62 6 15 1901 14 June, 1901
63 6 15 1962 14 June, 1962
64 6 15 2024 14 June, 2024
65 6 15 2025 14 June, 2025
45

Software Testing
66 6 30 1900 29 June, 1900
67 6 30 1901 29 June, 1901
68 6 30 1962 29 June, 1962
69 6 30 2024 29 June, 2024
70 6 30 2025 29 June, 2025
76 11 1 1900 31 October, 1900
77 11 1 1901 31 October, 1901
78 11 1 1962 31 October, 1962
79 11 1 2024 31 October, 2024
80 11 1 2025 31 October, 2025
81 11 2 1900 1 November, 1900
82 11 2 1901 1 November, 1901
46

Software Testing
83 11 2 1962 1 November, 1962
84 11 2 2024 1 November, 2024
85 11 2 2025 1 November, 2025
86 11 15 1900 14 November, 1900
87 11 15 1901 14 November, 1901
88 11 15 1962 14 November, 1962
89 11 15 2024 14 November, 2024
90 11 15 2025 14 November, 2025
91 11 30 1900 29 November, 1900
92 11 30 1901 29 November, 1901
93 11 30 1962 29 November, 1962
94 11 30 2024 29 November, 2024
95 11 30 2025 29 November, 2025
47

Software Testing
101 12 1 1900 30 November, 1900
102 12 1 1901 30 November, 1901
103 12 1 1962 30 November, 1962
104 12 1 2024 30 November, 2024
105 12 1 2025 30 November, 2025
106 12 2 1900 1 December, 1900
107 12 2 1901 1 December, 1901
108 12 2 1962 1 December, 1962
109 12 2 2024 1 December, 2024
110 12 2 2025 1 December, 2025
111 12 15 1900 14 December, 1900
112 12 15 1901 14 December, 1901
113 12 15 1962 14 December, 1962
114 12 15 2024 14 December, 2024
115 12 15 2025 14 December, 2025
116 12 30 1900 29 December, 1900
117 12 30 1901 29 December, 1901
118 12 30 1962 29 December, 1962
48

Software Testing
119 12 30 2024 29 December, 2024
120 12 30 2025 29 December, 2025
121 12 31 1900 30 December, 1900
122 12 31 1901 30 December, 1901
123 12 31 1962 30 December, 1962
124 12 31 2024 30 December, 2024
125 12 31 2025 30 December, 2025
49

Software Testing
Example – 8.6
Consider the triangle problem as given in example 8.3. Generate robust and
worst test cases for this problem.
50

Software Testing
Solution
Robust test cases are given on next slide.
51

52
So
ftw
a
r
eT
estin
g
` x y z Expected Output
1 50 50 0 Invalid input`
2 50 50 1 Isosceles
3 50 50 2 Isosceles
9 50 1 50 Isosceles

Software Testing
Worst test cases are 125 and are given below:
Test Case x y z Expected output
1 1 1 1 Equilateral
7 1 2 2 Isosceles
53

Software Testing
27 2 1 2 Isosceles
31 2 2 1 Isosceles
54

Software Testing
45 2 99 100 Scalene
55

Software Testing
49 2 100 50 Scalene
53 50 1 2 Isosceles
58 50 2 2 Isosceles
56

Software Testing
Test Case A B C Expected output
70 50 99 100 Scalene
74 50 100 99 Scalene
75 50 100 100 Isosceles
57

Software Testing
85 99 2 100 Scalene
90 99 50 100 Scalene
97 99 100 2 Scalene
98 99 100 50 Scalene
100 99 100 100 Isosceles
58

Software Testing
105 100 1 100 Isosceles
109 100 2 99 Scalene
110 100 2 100 Isosceles
114 100 50 99 Scalene
115 100 50 100 Isosceles
117 100 99 2 Scalene
118 100 99 50 Scalene
59

Software Testing
119 100 99 99 Isosceles
120 100 99 100 Isosceles
121 100 100 1 Isosceles
122 100 100 2 Isosceles
123 100 100 50 Isosceles
124 100 100 99 Isosceles
60

Software Testing
equivalence classes such
61
that one can reasonably assume,
absolutely sure, that the test of a representative value of each
but not be
class is
equivalent to a test of any other value.
Two steps are required to implementing this method:
Equivalence Class Testing
In this method, input domain of a program is partitioned into a finite number of
1. The equivalence classes are identified by taking each input condition and
partitioning it into valid and invalid classes. For example, if an input
condition specifies a range of values from 1 to 999, we identify one valid
equivalence class [1<item<999]; and two invalid equivalence classes
[item<1] and [item>999].
2. Generate the test cases using the equivalence classes identified in the
previous step. This is performed by writing test cases covering all the valid
equivalence classes. Then a test case is written for each invalid equivalence
class so that no test contains more than one invalid class. This is to ensure
that no two invalid classes mask each other.

Software Testing
Input domain Output domain
Fig. 7: Equivalence partitioning
Most of the time, equivalence class testing defines classes of the input domain.
However, equivalence classes should also be defined for output domain.
Hence, we should design equivalence classes based on input and output
domain.
System
under test
Outputs
62
Valid
inputs
Invalid input

Software Testing
Example 8.7
Consider the program for the determination of nature of roots of a quadratic
equation as explained in example 8.1. Identify the equivalence class test
cases for output and input domains.
63

Software Testing
Solution
Output domain equivalence class test cases can be identified as follows:
O1={<a,b,c>:Not a quadratic equation if a = 0}
O1={<a,b,c>:Real roots if (b2-4ac)>0}
O1={<a,b,c>:Imaginary roots if (b2-4ac)<0}
O1={<a,b,c>:Equal roots if (b2-4ac)=0}`
The number of test cases can be derived form above relations and
shown below:
64
Test case a b c Expected output
1 0 50 50 Not a quadratic equation
4 50 100 50 Equal roots

Software Testing
We may have another set of test cases based on input domain.
I1= {a: a = 0}
I2= {a: a < 0}
I3= {a: 1 ≤ a ≤ 100}
I4= {a: a > 100}
I5= {b: 0 ≤ b ≤ 100}
I6= {b: b < 0}
I7= {b: b > 100}
I8= {c: 0 ≤ c ≤ 100}
I9= {c: c < 0}
I10={c: c > 100}
65

Software Testing
1 0 50 50 Not a quadratic equation
2 -1 50 50 Invalid input
4 101 50 50 invalid input
6 50 -1 50 invalid input
9 50 50 -1 invalid input
66
Here test cases 5 and 8 are redundant test cases. If we choose any value other
than nominal, we may not have redundant test cases. Hence total test cases are
10+4=14 for this problem.

Software Testing
Example 8.8
Consider the program for determining the previous date in a calendar as
explained in example 8.3. Identify the equivalence class test cases for output
& input domains.
67

Software Testing
Solution
Output domain equivalence class are:
O1={<D,M,Y>: Previous date if all are valid inputs}
O1={<D,M,Y>: Invalid date if any input makes the date invalid}
68
Test case M D Y Expected output
1 6 15 1962 14 June, 1962

Software Testing
We may have another set of test cases which are based on input domain.
I1={month: 1 ≤ m ≤ 12}
I2={month: m < 1}
I3={month: m > 12}
I4={day: 1 ≤ D ≤ 31}
I5={day: D < 1}
I6={day: D > 31}
I7={year: 1900 ≤ Y ≤ 2025}
I8={year: Y < 1900}
I9={year: Y > 2025}
69

Software Testing
Test Case M D Y Expected output
1 6 15 1962 14 June, 1962
2 -1 15 1962 Invalid input
4 6 15 1962 14 June, 1962
5 6 -1 1962 invalid input
7 6 15 1962 14 June, 1962
8 6 15 1899 invalid input (Value out of range)
9 6 15 2026 invalid input (Value out of range)
70
Inputs domain test cases are :

Example – 8.9
Consider the triangle problem specified in a example 8.3. Identify the
equivalence class test cases for output and input domain.
Software Testing
71

Solution
Output domain equivalence classes are:
O1={<x,y,z>: Equilateral triangle with sides x,y,z}
O1={<x,y,z>: Isosceles triangle with sides x,y,z}
O1={<x,y,z>: Scalene triangle with sides x,y,z}
O1={<x,y,z>: Not a triangle with sides x,y,z}
The test cases are:
Software Testing
3 100 99 50 Scalene
72

Software Testing
Input domain based classes are:
I1={x: x < 1}
I2={x: x > 100}
I3={x: 1 ≤ x ≤ 100}
I4={y: y < 1}
I5={y: y > 100}
I6={y: 1 ≤ y ≤ 100}
I7={z: z < 1}
I8={z: z > 100}
I9={z: 1 ≤ z ≤ 100}
73

Software Testing
Some inputs domain test cases can be obtained using the relationship amongst x,y
and z.
I10={< x,y,z >: x = y = z}
I11={< x,y,z >: x = y, x ≠ z}
I12={< x,y,z >: x = z, x ≠ y}
I13={< x,y,z >: y = z, x ≠ y}
I14={< x,y,z >: x ≠ y, x ≠ z, y ≠ z}
I15={< x,y,z >: x = y + z}
I16={< x,y,z >: x > y +z}
I17={< x,y,z >: y = x +z}
I18={< x,y,z >: y > x + z}
I19={< x,y,z >: z = x + y}
I20={< x,y,z >: z > x +y}
74

Software Testing
Test cases derived from input domain are:
75

Software Testing
14 100 99 50 Scalene
76

Software Testing
Decision Table Based Testing
77
Conditi
on
Stub
Entry
True False
C1
True
F
alse
True False
C2
C3
True False True False True False ---
Actio
n
Stub
a1
a
2
a
3
a
X X X
X X X
X X
X X X
Table 2: Decision table terminology

Software Testing
Test case design
78
C1:x,y,z are sides of a triangle?
C2:x
= y?
C3:x
= z?
C4:y
= z?
N Y
-- Y N
-- Y N Y N
-- Y N Y N Y N Y N
a1: Not a triangle
a2: Scalene
a3:
Isosceles
a4:
X
X
X X X
X
X X X
Table 3: Decision table for triangle problem

Software Testing
Table 4: Modified decision table
79
Conditions
C1 : x < y + z ?
F T T T T T T T T T T
C2 : y < x + z ? -- F T T T T T T T T T
C3 : z < x + y ? -- -- F T T T T T T T T
C4 : x = y ? -- -- -- T T T T F F F F
C5 : x = z ? -- -- -- T T F F T T F F
C6 : y = z ? -- -- -- T F T F T F T F
a1 : Not a triangle X X X
a2 : Scalene X
a3 : Isosceles X X X
a4 : Equilateral X
a5 : Impossible X X X

Software Testing
Example 8.10
Consider the triangle program specified in example 8.3. Identify the
test cases using the decision table of Table 4.
80

Software Testing
4 5 5 5 Equilateral
5 ? ? ? Impossible
6 ? ? ? Impossible
7 2 2 3 Isosceles
8 ? ? ? Impossible
9 2 3 2 Isosceles
10 3 2 2 Isosceles
11 3 4 5 Scalene
81
Solution
There are eleven functional test cases, three to fail triangle property, three
impossible cases, one each to get equilateral, scalene triangle cases, and
three to get on isosceles triangle. The test cases are given in Table 5.
Test cases of triangle problem using decision table

Software Testing
Example 8.11
Consider a program for the determination of Previous date. Its input is a triple of day,
month and year with the values in the range
1 ≤ month ≤ 12
1 ≤ day ≤ 31
1900 ≤ year ≤ 2025
The possible outputs are “Previous date” and “Invalid date”. Design the test cases
using decision table based testing.
82

83
Software Testing
Solution
The input domain can be divided into following classes:
I1= {M1: month has 30 days}
I2= {M2: month has 31 days except March, August and January}
I3= {M3: month is March}
I4= {M4: month is August}
I5= {M5: month is January}
I6= {M6: month is February}
I7= {D1: day = 1}
I8= {D2: 2 ≤ day ≤ 28}
I9= {D3: day = 29}
I10={D4: day = 30}
I11={D5: day = 31}
I12={Y1: year is a leap year}
I13={Y2: year is a common year}

84
Software Testing
The decision table is given below:
Sr.No. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
C1: Months in M1 M1 M1 M1 M1 M1 M1 M1 M1 M1 M2 M2 M2 M2 M2
C2: days in D1 D1 D2 D2 D3 D3 D4 D4 D5 D5 D1 D1 D2 D2 D3
C3: year in Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1 Y2 Y1
a1: Impossible X X
a2: Decrement day X X X X X X X X X
a3: Reset day to 31 X X
a5: Reset day to 29
a6: Reset day to 28
a7: decrement month X X X X
a8: Reset month to December
a9: Decrement year

Software Testing
Sr.No. 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30
a1: Impossible
a2: Decrement day X X X X X X X X X X X X X
a3: Reset day to 31
a4: Reset day to 30
a5: Reset day to 29 X
a6: Reset day to 28 X
a7: decrement month X X
a9: Decrement year
85

Software Testing
Sr.No. 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45
a1: Impossible
a2: Decrement day X X X X X X X X X X X
a3: Reset day to 31 X X X X
a4: Reset day to 30
a5: Reset day to 29
a6: Reset day to 28
a8: Reset month to December X X
a9: Decrement year X X
86

Software Testing
Sr.No. 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60
a1: Impossible X X X X X
a2: Decrement day X X X X X X X X
a4: Reset day to 30
a5: Reset day to 29
a6: Reset day to 28
a9: Decrement year
87

Software Testing
Test case Month Day Year Expected output
1 June 1 1964 31 May, 1964
2 June 1 1962 31 May, 1962
3 June 15 1964 14 June, 1964
4 June 15 1962 14 June, 1962
5 June 29 1964 28 June, 1964
6 June 29 1962 28 June, 1962
7 June 30 1964 29 June, 1964
8 June 30 1962 29 June, 1962
9 June 31 1964 Impossible
10 June 31 1962 Impossible
11 May 1 1964 30 April, 1964
12 May 1 1962 30 April, 1962
13 May 15 1964 14 May, 1964
14 May 15 1962 14 May, 1962
15 May 29 1964 28 May, 1964
88

Software Testing
16 May 29 1962 28 May, 1962
17 May 30 1964 29 May, 1964
18 May 30 1962 29 May, 1962
19 May 31 1964 30 May, 1964
20 May 31 1962 30 May, 1962
21 March 1 1964 29 February, 1964
22 March 1 1962 28 February, 1962
23 March 15 1964 14 March, 1964
24 March 15 1962 14 March, 1962
25 March 29 1964 28 March, 1964
26 March 29 1962 28 March, 1962
27 March 30 1964 29 March, 1964
28 March 30 1962 29 March, 1962
29 March 31 1964 30 March, 1964
30 March 31 1962 30 March, 1962
89

Software Testing
31 August 1 1964 31 July, 1962
32 August 1 1962 31 July, 1964
33 August 15 1964 14 August, 1964
34 August 15 1962 14 August, 1962
35 August 29 1964 28 August, 1964
36 August 29 1962 28 August, 1962
37 August 30 1964 29 August, 1964
38 August 30 1962 29 August, 1962
39 August 31 1964 30 August, 1964
40 August 31 1962 30 August, 1962
41 January 1 1964 31 December, 1964
42 January 1 1962 31 December, 1962
43 January 15 1964 14 January, 1964
90

Software Testing
51 February 1 1964 31 January, 1964
52 February 1 1962 31 January, 1962
53 February 15 1964 14 February, 1964
56 February 29 1962 Impossible
91

Software Testing
Cause Effect Graphing Technique
▪ Consider single input conditions
▪ do not explore combinations of input circumstances
Steps
1. Causes & effects in the specifications are identified.
A cause is a distinct input condition or an equivalence class of input conditions.
An effect is an output condition or a system transformation.
2. The semantic content of the specification is analysed and transformed into a
boolean graph linking the causes & effects.
3. Constraints are imposed
4. graph – limited entry decision table
Each column in the table represent a test case.
5. The columns in the decision table are converted into test cases.
92

Software Testing
The basic notation for the graph is shown in fig. 8
Fig.8. 8 : Basic cause effect graph symbols
93

Software Testing
Myers explained this effectively with following example. “The characters in column 1
must be an A or B. The character in column 2 must be a digit. In this situation, the
file update is made. If the character in column 1 is incorrect, message x is issued. If
the character in column 2 is not a digit, message y is issued”.
The causes are
c1: character in column 1 is A
c2: character in column 1 is B
c3: character in column 2 is a digit
and the effects are
e1: update made
e2: message x is issued
e3: message y is issued
94

Software Testing
Fig. 9: Sample cause effect graph
95

Software Testing
The E constraint states that it must always be true that at most
one of c1 or c2 can be 1 (c1 or c2 cannot be 1 simultaneously). The
I constraint states that at least one of c1, c2 and c3 must always be
1 (c1, c2 and c3 cannot be 0 simultaneously). The O constraint
states that one, and only one, of c1 and c2 must be 1. The
constraint R states that, for c1 to be 1, c2 must be 1 (i.e. it is
impossible for c1 to be 1 and c2 to be 0),
96

Software Testing
Fig. 10: Constraint symbols
97

Software Testing
Fig. 11: Symbol for masks constraint
98

Software Testing
Fig. 12 : Sample cause effect graph with exclusive constraint
99

Software Testing
Example 8.12
Consider the triangle problem specified in the example 8.3. Draw the Cause
effect graph and identify the test cases.
100

Software Testing
Solution
The causes are
c1: side x is less than sum of sides y and z
c2: side y is less than sum of sides x and y
c3: side z is less than sum of sides x and y
c4: side x is equal to side y
c5: side x is equal to side z
c6: side y is equal to side z
and effects are
e1: Not a triangle
e2: Scalene triangle
e3: Isosceles triangle
e4: Equilateral triangle
e5: Impossible stage
101

102
rd
Software Engineering (3 ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
Software Testing
Conditions
C1: x < y + z
?
0 1 1 1 1 1 1 1 1 1 1
C2: y < x + z ? X 0 1 1 1 1 1 1 1 1 1
C3: z < x + y ? X X 0 1 1 1 1 1 1 1 1
C4: x = y ? X X X 1 1 1 1 0 0 0 0
C5: x = z ? X X X 1 1 0 0 1 1 0 0
C6: y = z ? X X X 1 0 1 0 1 0 1 0
e1: Not a triangle 1 1 1
e2: Scalene 1
e3: Isosceles 1 1 1
e4: Equilateral 1
e5: Impossible 1 1 1
Table 6: Decision table
The cause effect graph is shown in fig. 13 and decision table is shown in table 6.
The test cases for this problem are available in Table 5.

Software Testing
Fig. 13: Cause effect graph of triangle problem
103

Software Testing
Structural Testing
A complementary approach to functional testing is called structural / white box
testing. It permits us to examine the internal structure of the program.
Path Testing
Path testing is the name given to a group of test techniques based on judiciously
selecting a set of test paths through the program. If the set of paths is properly
chosen, then it means that we have achieved some measure of test thoroughness.
This type of testing involves:
1. generating a set of paths that will cover every branch in the program.
2. finding a set of test cases that will execute every path in the set of program
paths.
104

Software Testing
Flow Graph
The control flow of a program can be analysed using a graphical representation
known as flow graph. The flow graph is a directed graph in which nodes are either
entire statements or fragments of a statement, and edges represents flow of control.
Fig. 14: The basic construct of the flow graph
105

Software Testing
Fig. 15: Program for previous date problem
110

Software Testing
Fig. 16: Flow graph of previous date
problem
111

Software Testing
Flow
graph
nodes
DD Path graph
corresponding
node
Remarks
1 to 9 n1 There is a sequential flow from node 1 to 9
10 n2 Decision node, if true go to 13 else go to 44
13,14 n5 Sequential nodes and are combined to form new node n5
15,16,17 n6 Sequential nodes
18 n7 Edges from node 14 to 17 are terminated here
20 n9 Intermediate node with one input edge and one output edge
22 n11 Intermediate node
Cont…
11
.2
DD Path Graph
Table 7: Mapping of flow graph nodes and DD path nodes

Software Testing
Flow
graph
nodes
DD Path graph
corresponding
node
Remarks
24,25 n13 Sequential nodes
26 n14 Two edges from node 25 & 23 are terminated here
27 n15 Two edges from node 26 & 21 are terminated here. Also a decision node
36 n20 Three edge from node 29,32 and 35 are terminated here
43 n24 Three edge from node 36,39 and 42 are terminated here
Cont….
113

Software Testing
Flow
graph
nodes
DD Path graph
corresponding
node
Remarks
44 n25 Decision node, if true go to 45 else go to 82. Three edges from 18,43 & 10
are also terminated here.
47,48,49,50 n28 Sequential nodes
52 n30 Intermediate node with one input edge & one output ege
58 n35 Two edge from node 57 and 55 are terminated here
59 n36 Decision node, if true go to 60 else go to 63. Two edge from nodes 58 and 53
are terminated.
Cont….
114

Software Testing
Flow
graph
nodes
DD Path graph
corresponding
node
Remarks
67 n39 Two edge from node 62 and 66 are terminated here
76 n43 Four edges from nodes 50, 67, 71 and 75 are terminated here.
80 n45 Two edges from nodes 76 & 79 are terminated here
85 n48 Two edges from nodes 81 and 84 are terminated here
86,87 n49 Sequential nodes with exit node
115

So
ftw
a
r
eTe
stin
g
Fig. 17: DD path graph
of previous date
problem
116

So
ftw
a
r
eTe
stin
g
117
Fig. 18: Independent paths of previous date problem

Software Testing
Example 8.13
Consider the problem for the determination of the nature of roots of a quadratic
equation. Its input a triple of positive integers (say a,b,c) and value may be from
interval [0,100].
The program is given in fig. 19. The output may have one of the following words:
[Not a quadratic equation; real roots; Imaginary roots; Equal roots]
Draw the flow graph and DD path graph. Also find independent paths from the DD
Path graph.
118

Software Testing
Fig. 19: Code of quadratic equation problem
120

So
ftw
a
r
eT
estin
g
Solution
121
Fig. 19 (a) : Program flow
graph

Software Testing
Fig. 19 (b) : DD Path graph
122

123
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
Software Testing
Flow
graph
nodes
DD Path graph
corresponding
node
Remarks
1 to 10 A Sequential nodes
11 B Decision node
12 C Intermediate node
13 D Decision node
14,15 E Sequential node
16 F Two edges are combined here
17 G Two edges are combined and decision node
18 H Intermediate node
19 I Decision node
20,21 J Sequential node
22 K Decision node
23,24,25 L Sequential node
Cont….
The mapping table for DD path graph is:

Software Testing
Flow
graph
nodes
DD Path graph
corresponding
node
Remarks
26,27,28,29 M Sequential nodes
30 N Three edges are combined
31 O Decision node
32,33 P Sequential node
34,35,36 Q Sequential node
37 R Three edges are combined here
38,39 S Sequential nodes with exit node
124
Independent paths are:
(i) ABGOQRS
(iii) ABCDFGOQRS
(v) ABGHIJNRS
(vi) ABGHIKMNRS
(ii) ABGOPRS
(iv) ABCDEFGOPRS
(vi) ABGHIKLNRS

Software Testing
Example 8.14
Consider a program given in Fig.8.20 for the classification of a triangle. Its input is a
triple of positive integers (say a,b,c) from the interval [1,100]. The output may be
[Scalene, Isosceles, Equilateral, Not a triangle].
Draw the flow graph & DD Path graph. Also find the independent paths from the DD
Path graph.
125

Software Testing
Fig. 20 : Code of triangle classification problem
127

Software Testing
Solution :
Flow graph of
triangle problem is:
Fig.8. 20 (a): Program flow graph
128

129
Software Engineering (3rd ed.), By K.K Aggarwal & Yogesh Singh, Copyright © New Age International Publishers, 2007
Software Testing
Flow
graph
nodes
DD Path graph
corresponding
node
Remarks
1 TO 9 A Sequential nodes
10 B Decision node
11 C Decision node
12, 13 D Sequential nodes
14 E Two edges are joined here
15, 16, 17 F Sequential nodes
18 G Decision nodes plus joining of two edges
19 H Decision node
20, 21 I Sequential nodes
22 J Decision node
23, 24 K Sequential nodes
25, 26, 27 L Sequential nodes
Cont….
The mapping table for DD path graph is:

Software Testing
Flow
graph
nodes
DD Path graph
corresponding
node
Remarks
28 M Three edges are combined here
29 N Decision node
30, 31 O Sequential nodes
32, 33, 34 P Sequential nodes
35 Q Three edges are combined here
36, 37 R Sequential nodes with exit node
130
Fig. 20 (b): DD Path graph

Software Testing
Fig. 20 (b): DD Path graph
DD Path graph is given in Fig. 20 (b)
131
Independent paths are:
(i) ABFGNPQR
(ii) ABFGNOQR
(iii) ABCEGNPQR
(iv) ABCDEGNOQR
(v) ABFGHIMQR
(vi)ABFGHJKMQR
(vii)ABFGHJMQR

Software Testing
Cyclomatic Complexity
McCabe’s cyclomatic metric V(G) = e – n + 2P.
For example, a flow graph shown in in Fig. 21 with entry node ‘a’ and exit node ‘f’.
Fig. 21: Flow graph
132

Software Testing
The value of cyclomatic complexity can be calculated as :
V(G) = 9 – 6 + 2 = 5
Here e = 9, n = 6 and P =1
There will be five independent paths for the flow graph illustrated in Fig. 21.
133
Path 1 :
Path 2 :
Path 3 :
Path 4 :
Path 5 :
a c f
a b e f
a d c f
a b e a c f or a b e a b e f
a b e b e f

Several properties of cyclomatic complexity are stated below:
1. V(G) ≥1
2. V (G) is the maximum number of independent paths in graph G.
3. Inserting & deleting functional statements to G does not affect V(G).
4. G has only one path if and only if V(G)=1.
5. Inserting a new row in G increases V(G) by unity.
6. V(G) depends only on the decision structure of G.
Software Testing
134

Software Testing
Fig. 22
135
The role of P in the complexity calculation V(G)=e-n+2P is required to be understood
correctly. We define a flow graph with unique entry and exit nodes, all nodes
reachable from the entry, and exit reachable from all nodes. This definition would
result in all flow graphs having only one connected component. One could, however,
imagine a main program M and two called subroutines A and B having a flow graph
shown in Fig. 22.

Software Testing
Let us denote the total graph above with 3 connected components as
V(M  A B)  e  n  2P
= 13-13+2*3
= 6
136
1 can be used to calculate the complexity of a
collection of programs, particularly a hierarchical nest of subroutines.
This method with P 

Software Testing
k
137
k
 ∑(ei  ni  2)  ∑V(Ci )
i1 i1
Notice that . In general, the
complexity of a collection C of flow graphs with K connected components is
equal to the summation of their complexities. To see this let Ci,1 ≤ I ≤ K
denote the k distinct connected component, and let ei and ni be the number of edges
and nodes in the ith-connected component. Then
k k
V(C)  e  n  2p  ∑ei  ∑ni  2K
i1 i1
V(M  A B) V(M ) V(A) V(B)  6

Software Testing
Two alternate methods are available for the complexity calculations.
1. Cyclomatic complexity V(G) of a flow graph G is equal to the number of
predicate (decision) nodes plus one.
V(G)= +1
Where  is the number of predicate nodes contained in the flow graph
G.
2. Cyclomatic complexity is equal to the number of regions of the flow
graph.
138

Software Testing
Example 8.15
Consider a flow graph given in Fig. 23 and calculate the cyclomatic
complexity by all three methods.
Fig. 23
139

Software Testing
Solution
Cyclomatic complexity can be calculated by any of the three methods.
140
1. V(G) = e – n + 2P
= 13 – 10 + 2 = 5
2. V(G) = π + 1
= 4 + 1 = 5
3. V(G) = number of regions
= 5
Therefore, complexity value of a flow graph in Fig. 23 is 5.

Software Testing
Example 8.16
Consider the previous date program with DD path graph given in Fig. 17.
Find cyclomatic complexity.
141

Software Testing
Solution
Number of edges (e) = 65
Number of nodes (n) =49
142
(i)
(ii)
(iii)
V(G) = e – n + 2P = 65 – 49 + 2 = 18
V(G) = π + 1 = 17 + 1 = 18
V(G) = Number of regions = 18
The cyclomatic complexity is 18.

Software Testing
Example 8.17
Consider the quadratic equation problem given in example 8.13 with its DD
Path graph. Find the cyclomatic complexity:
143

Software Testing
Solution
Number of nodes (n) = 19
(i) V(G) = e – n + 2P = 24 – 19 + 2 = 7
(ii) V(G) = π + 1 = 6 + 1 = 7
(iii)V(G) = Number of regions = 7
144
Hence cyclomatic complexity is 7
independent paths in the DD Path graph.
meaning thereby, seven

Software Testing
Example 8.18
Consider the classification of triangle problem given in example 8.14. Find
the cyclomatic complexity.
145

Software Testing
Solution
Number of nodes (n) =18
(i) V(G) = e – n + 2P = 23 – 18 + 2 = 7
(ii) V(G) = π + 1 = 6 + 1 = 7
(iii)V(G) = Number of regions = 7
The cyclomatic complexity is 7. Hence, there are seven independent paths
as given in example 8.14.
146

Software Testing
Graph Matrices
A graph matrix is a square matrix with one row and one column for every node in the
graph. The size of the matrix (i.e., the number of rows and columns) is equal to the
number of nodes in the flow graph. Some examples of graphs and associated
matrices are shown in fig. 24.
Fig. 24 (a): Flow graph and graph matrices
147

Software Testing
Fig. 24 (b): Flow graph and graph matrices
148

Software Testing
Fig. 24 (c): Flow graph and graph matrices
149

Software Testing
Fig. 25 : Connection matrix of flow graph shown in Fig. 24 (c)
150

Software
Testing
The square matrix represent that there are two path ab and cd from node 1 to
node 2.
151

Software Testing
Example 8.19
Consider the flow graph shown in the Fig. 26 and draw the graph & connection
matrices. Find out cyclomatic complexity and two / three link paths from a node to
any other node.
Fig. 26 : Flow graph
152

Software Testing
Solution
The graph & connection matrices are given below :
To find two link paths, we have to generate a square of graph matrix [A] and for three
link paths, a cube of matrix [A] is required.
153

Software Testing
Data Flow Testing
Data flow testing is another from of structural testing. It has nothing to do with data
flow diagrams.
i. Statements where variables receive values.
ii. Statements where these values are used or referenced.
As we know, variables are defined and referenced throughout the program. We
may have few define/ reference anomalies:
i. A variable is defined but not used/ referenced.
ii. A variable is used but never defined.
iii. A variable is defined twice before it is used.
155

Software Testing
Definitions
The definitions refer to a program P that has a program graph G(P) and a set of
program variables V. The G(P) has a single entry node and a single exit node. The
set of all paths in P is PATHS(P)
(i) Defining Node: Node n z G(P) is a defining node of the variable v z V,
written as DEF (v, n), if the value of the variable v is defined at the statement
fragment corresponding to node n.
(ii) Usage Node: Node n z G(P) is a usage node of the variable v z V, written as
USE (v, n), if the value of the variable v is used at statement fragment
corresponding to node n. A usage node USE (v, n) is a predicate use (denote
as p) if statement n is a predicate statement otherwise USE (v, n) is a
computation use (denoted as c).
156

(iii) Definition use: A definition use path with respect to a variable v (denoted du-
path) is a path in PATHS(P) such that, for some v z V, there are define and
usage nodes DEF(v, m) and USE(v, n) such that m and n are initial and final
nodes of the path.
(iv) Definition clear : A definition clear path with respect to a variable v (denoted
dc-path) is a definition use path in PATHS(P) with initial and final nodes DEF
(v, m) and USE (v, n), such that no other node in the path is a defining node of v.
The du-paths and dc-paths describe the flow of data across source statements from
points at which the values are defined to points at which the values are used. The
du-paths that are not definition clear are potential trouble spots.
Software Testing
157

Software Testing
Fig. 27 : Steps for data flow testing
158
Hence, our objective is to find all du-paths and then identity those du-paths which are
not dc-paths. The steps are given in Fig. 27. We may like to generate specific test
cases for du-paths that are not dc-paths.

Software Testing
Example 8.20
Consider the program of the determination of the nature of roots of a quadratic
equation. Its input is a triple of positive integers (say a,b,c) and values for each of
these may be from interval [0,100]. The program is given in Fig. 19. The output may
have one of the option given below:
(i) Not a quadratic program
(ii) real roots
(iii) imaginary roots
(iv) equal roots
(v) invalid inputs
Find all du-paths and identify those du-paths that are definition clear.
159

Software Testing
Solution
Step I: The program flow graph is given in Fig. 19 (a). The variables used in the
program are a,b,c,d, validinput, D.
Step II: DD Path graph is given in Fig. 19(b). The cyclomatic complexity of this graph
is 7 indicating there are seven independent paths.
Step III: Define/use nodes for all variables are given below:
160
Variable Defined at node Used at node
a 6 11,13,18,20,24,27,28
b 8 11,18,20,24,28
c 10 11,18
d 18 19,22,23,27
D 23, 27 24,28
Validinput 3, 12, 14 17,31

Software Testing
Step IV: The du-paths are identified and are named by their beginning and ending
nodes using Fig. 19 (a).
Variable Path (beginning, end) nodes Definition clear ?
a
6, 11
6, 13
Y
e
s
Y
e
s
6, 18 Yes
6, 20 Yes
6, 24 Yes
6, 27 Yes
6, 28 Yes
8, 11 Yes
b 8, 18
8, 20
Yes
Yes
8, 24 Yes
8, 28 Yes
161

Software Testing
c
10, 11
10, 18
Y
e
s
Y
e
s
d 18, 19 Yes
18, 22 Yes
18, 23 Yes
18, 27 Yes
D 23, 24 Yes
23, 28 Path not possible
27, 24 Path not possible
27, 28 Yes
validinput
3, 17
3, 31
n
o
n
o
12, 17 no
162

Software Testing
Example 8.21
Consider the program given in Fig. 20 for the classification of a triangle. Its
input is a triple of positive integers (say a,b,c) from the interval [1,100]. The
output may be:
[Scalene, Isosceles, Equilateral, Not a triangle, Invalid inputs].
Find all du-paths and identify those du-paths that are definition clear.
163

Software Testing
Solution
Step I: The program flow graph is given in Fig. 20 (a). The variables used in
the program are a,b,c, valid input.
Step II: DD Path graph is given in Fig. 20(b). The cyclomatic complexity of
this graph is 7 and thus, there are 7 independent paths.
Step III: Define/use nodes for all variables are given below:
164
Variable Defined at node Used at node
a 6 10, 11, 19, 22
b 7 10, 11, 19, 22
c 9 10, 11, 19, 22
valid input 3, 13, 16 18, 29

Software Testing
a
5, 10
5, 11
Y
e
s
Y
e
s
5, 19 Yes
5, 22 Yes
7, 10 Yes
b 7, 11
7, 19
Yes
Yes
7, 22 Yes
Step IV: The du-paths are identified and are named by their beginning and ending
nodes using Fig. 20 (a).
165

Software Testing
c
9, 10
9, 11
Y
e
s
Y
e
s
9, 19 Yes
9, 22 Yes
valid input
3, 18
3, 29
n
o
n
o
12, 18 no
12, 29 no
16, 18 Yes
16, 29 Yes
166
Hence total du-paths are 18 out of which four paths are not definition clear

Software Testing
Mutation Testing
Mutation testing is a fault based technique that is similar to fault seeding, except that
mutations to program statements are made in order to determine properties about
test cases. it is basically a fault simulation technique.
Multiple copies of a program are made, and each copy is altered; this altered copy is
called a mutant. Mutants are executed with test data to determine whether the test
data are capable of detecting the change between the original program and the
mutated program.
A mutant that is detected by a test case is termed “killed” and the goal of mutation
procedure is to find a set of test cases that are able to kill groups of mutant
programs.
167

Software Testing
When we mutate code there needs to be a way of measuring the degree to which the
code has been modified. For example, if the original expression is x+1 and the
mutant for that expression is x+2, that is a lesser change to the original code than a
mutant such as (c*22), where both the operand and the operator are changed. We
may have a ranking scheme, where a first order mutant is a single change to an
expression, a second order mutant is a mutation to a first order mutant, and so on.
High order mutants becomes intractable and thus in practice only low order mutants
are used.
One difficulty associated with whether mutants will be killed is the problem of
reaching the location; if a mutant is not executed, it cannot be killed. Special test
cases are to be designed to reach a mutant. For example, suppose, we have the
code.
Read (a,b,c);
If(a>b) and (b=c) then
x:=a*b*c; (make mutants; m1, m2, m3 …….)
168

Software Testing
To execute this, input domain must contain a value such that a is greater than b and
b equals c. If input domain does not contain such a value, then all mutants made at
this location should be considered equivalent to the original program, because the
statement x:=a*b*c is dead code (code that cannot be reached during execution). If
we make the mutant x+y for x+1, then we should take care about the value of y
which should not be equal to 1 for designing a test case.
The manner by which a test suite is evaluated (scored) via mutation testing is as
follows: for a specified test suite and a specific set of mutants, there will be three
types of mutants in the code i.e., killed or dead, live, equivalent. The sum of the
number of live, killed, and equivalent mutants will be the total number of mutants
created. The score associated with a test suite T and mutants M is simply.
100%
169
#total#equivalent
#killed

Software Testing
Levels of Testing
There are 3 levels of testing:
i. Unit Testing
ii. Integration Testing
iii. System Testing
170

Unit Testing
There are number of reasons in support of unit testing than testing the entire product.
1. The size of a single module is small enough that we can locate an error
fairly easily.
2. The module is small enough that we can attempt to test it in some
demonstrably exhaustive fashion.
3. Confusing interactions of multiple errors in widely different parts of the
software are eliminated.
Software Testing
171

There are problems associated with testing a module in isolation. How do we run a
module without anything to call it, to be called by it or, possibly, to output
intermediate values obtained during execution? One approach is to construct an
appropriate driver routine to call if and, simple stubs to be called by it, and to insert
output statements in it.
Stubs serve to replace modules that are subordinate to (called by) the module to be
tested. A stub or dummy subprogram uses the subordinate module’s interface, may
do minimal data manipulation, prints verification of entry, and returns.
This overhead code, called scaffolding represents effort that is import to testing, but
does not appear in the delivered product as shown in Fig. 29.
Software Testing
172

Software Testing
Fig. 29 : Scaffolding required testing a program unit (module)
173

Integration Testing
The purpose of unit testing is to determine that each independent module is
correctly implemented. This gives little chance to determine that the interface
between modules is also correct, and for this reason integration testing must be
performed. One specific target of integration testing is the interface: whether
parameters match on both sides as to type, permissible ranges, meaning and
utilization.
Software Testing
174

Software Testing
Fig. 30 : Three different integration approaches
175

System Testing
Of the three levels of testing, the system level is closet to everyday experiences.
We test many things; a used car before we buy it, an on-line cable network
service before we subscribe, and so on. A common pattern in these familiar
forms is that we evaluate a product in terms of our expectations; not with
respect to a specification or a standard. Consequently, goal is not to find faults,
but to demonstrate performance. Because of this we tend to approach system
testing from a functional standpoint rather than from a structural one. Since it is
so intuitively familiar, system testing in practice tends to be less formal than it
might be, and is compounded by the reduced testing interval that usually
remains before a delivery deadline.
Petschenik gives some guidelines for choosing test cases during system testing.
Software Testing
176

During system testing, we should evaluate a number of attributes of the
software that are vital to the user and are listed in Fig. 31. These represent the
operational correctness of the product and may be part of the software
specifications.
Software Testing
Usable Is the product convenient, clear, and predictable?
Secure Is access to sensitive data restricted to those with authorization?
Compatible
Will the product work correctly in conjunction with existing
data, software, and procedures?
Dependable
Do adequate safeguards against failure and methods for recovery
exist in the product?
Documented Are manuals complete, correct, and understandable?
177
Fig. 31 : Attributes of software to be tested during system testing

Software Testing
Validation Testing
o It refers to test the software as a complete product.
o This should be done after unit & integration testing.
o Alpha, beta & acceptance testing are nothing but the various ways of involving
customer during testing.
178

Software Testing
Validation Testing
o IEEE has developed a standard (IEEE standard 1059-1993) entitled “ IEEE guide
for software verification and validation “ to provide specific guidance about
planning and documenting the tasks required by the standard so that the
customer may write an effective plan.
o Validation testing improves the quality of software product in terms of functional
capabilities and quality attributes.
179

Software Testing
The Art of Debugging
The goal of testing is to identify errors (bugs) in the program. The process of
testing generates symptoms, and a program’s failure is a clear symptom of the
presence of an error. After getting a symptom, we begin to investigate the cause
and place of that error. After identification of place, we examine that portion to
identify the cause of the problem. This process is called debugging.
Debugging Techniques
Pressman explained few characteristics of bugs that provide some clues.
1. “The symptom and the cause may be geographically remote. That is, the
symptom may appear in one part of a program, while the cause may actually be
located in other part. Highly coupled program structures may complicate this
situation.
2. The symptom may disappear (temporarily) when another error is corrected.
180

3. The symptom may actually be caused by non errors (e.g. round off inaccuracies).
4. The symptom may be caused by a human error that is not easily traced.
5. The symptom may be a result of timing problems rather than processing
problems.
6. It may be difficult to accurately reproduce input conditions (e.g. a real time
application in which input ordering is indeterminate).
7. The symptom may be intermittent. This is particularly common in embedded
system that couple hardware with software inextricably.
8. The symptom may be due to causes that are distributed across a number of tasks
running on different processors”.
Software Testing
181

Induction approach
➢ Locate the pertinent data
➢ Organize the data
➢ Devise a hypothesis
➢ Prove the hypothesis
Software Testing
182

Software Testing
Fig. 32 : The inductive debugging process
183

Deduction approach
➢ Enumerate the possible causes or hypotheses
➢ Use the data to eliminate possible causes
➢ Refine the remaining hypothesis
➢ Prove the remaining hypothesis
Software Testing
184

Software Testing
Fig. 33 : The inductive debugging process
185

Software Testing
Testing Tools
One way to improve the quality & quantity of testing is to make the process as
pleasant as possible for the tester. This means that tools should be as concise,
powerful & natural as possible.
The two broad categories of software testing tools are :
➢ Static
➢ Dynamic
186

Software Testing
There are different types of tools available and some are listed below:
1. Static analyzers, which examine programs systematically and automatically.
2. Code inspectors, who inspect programs automatically to make sure they adhere
to minimum quality standards.
3. standards enforcers, which impose simple rules on the developer.
4. Coverage analysers, which measure the extent of coverage.
5. Output comparators, used to determine whether the output in a program is
appropriate or not.
187

Software Testing
6. Test file/ data generators, used to set up test inputs.
7. Test harnesses, used to simplify test operations.
8. Test archiving systems, used to provide documentation about programs.
188

Module IV (1).pptx for software emgineee

Software
Maintenance
What is Software Maintenance?
Software Maintenance is a very broad activity that includes error
corrections, enhancements of capabilities, deletion of obsolete capabilities,
and optimization.

Software
Maintenance
Categories of Maintenance
▪ Corrective maintenance
This refer to modifications initiated by defects in the software.
▪ Adaptive maintenance
It includes modifying the software to match changes in the ever changing
environment.
▪ Perfective maintenance
It means improving processing efficiency or performance, or restructuring
the software to improve changeability. This may include enhancement of
existing system functionality, improvement in computational efficiency etc.

Software
Maintenance
▪ Other types of maintenance
There are long term effects of corrective, adaptive and perfective changes.
This leads to increase in the complexity of the software, which reflect
deteriorating structure. The work is required to be done to maintain it or to
reduce it, if possible. This work may be named as preventive
maintenance.

Software
Maintenance
Fig. 1: Distribution of maintenance effort
Perfective
Adaptive
Preventive
Corrective

Software
Maintenance
Problems During Maintenance
➢ Often the program is written by another person or group of persons.
➢ Often the program is changed by person who did not understand it
clearly.
➢ Program listings are not structured.
➢ High staff turnover.
➢ Information gap.
➢ Systems are not designed for change.

Software
Maintenance
Maintenance is Manageable
A common misconception about maintenance is that it is not manageable.
Report of survey conducted by Lientz & Swanson gives some interesting
observations:
1 Emergency debugging 12.4%
2 Routine debugging 9.3%
3 Data environment adaptation 17.3%
4 Changes in hardware and OS 6.2%
5 Enhancements for users 41.8%
6 Documentation Improvement 5.5%
7 Code efficiency improvement 4.0%
8 Others 3.5%
Table 1: Distribution of maintenance effort

Software
Maintenance
1 New reports 40.8%
2 Add data in existing reports 27.1%
3 Reformed reports 10%
4 Condense reports 5.6%
5 Consolidate reports 6.4%
6 Others 10.1%
Table 2: Kinds of maintenance requests
Kinds of maintenance requests

Software
Maintenance
Potential Solutions to Maintenance Problems
➢ Budget and effort reallocation
➢ Complete replacement of the system
➢ Maintenance of existing system

Software
Maintenance
The Maintenance Process
Fig. 2: The software
maintenance process

Software
Maintenance
▪ Program Understanding
The first phase consists of analyzing the program in order to understand.
▪ Generating Particular Maintenance Proposal
The second phase consists of generating a particular maintenance
proposal to accomplish the implementation of the maintenance objective.
▪ Ripple Effect
The third phase consists of accounting for all of the ripple effect as a
consequence of program modifications.

Software
Maintenance
▪ Modified Program Testing
The fourth phase consists of testing the modified program to ensure that
the modified program has at least the same reliability level as before.
▪ Maintainability
Each of these four phases and their associated software quality attributes
are critical to the maintenance process. All of these factors must be
combined to form maintainability.

Software
Maintenance
Maintenance Models
▪ Quick-fix Model
This is basically an adhoc approach to maintaining software. It is a fire
fighting approach, waiting for the problem to occur and then trying to fix it
as quickly as possible.
Problem
found
Fix it
Fig. 3: The quick-fix model

Software
Maintenance
▪ Iterative Enhancement Model
➢ Analysis
➢ Characterization of proposed modifications
➢ Redesign and implementation

Software
Maintenance
Fig. 4: The three stage cycle of iterative enhancement
Analyze existing system
Characterize
proposed
modifications
Redesign current
version and
implementation

▪ Reuse Oriented Model
The reuse model has four main steps:
1. Identification of the parts of the old system that are candidates for
reuse.
2. Understanding these system parts.
3. Modification of the old system parts appropriate to the new
requirements.
4. Integration of the modified parts into the new system.
Software
Maintenance

SoftwareMaintenance
Fig. 5: The reuse model
New system
Components
library
Requirements analysis
17
S
o
f
t
w
a
r
e
E
n
g
i
n
e
e
r
i
n
g
(
3
r
d
e
d
.
)
,
B
y
K
.
K
A
g
g
a
r
w
a
l
&
Y
o
g
e
s
h
S
i
n
g
h
,
C
o
p
y
r
i
g
h
t
©
N
e
w
Design
Source code
Test data
Requirements analysis
Design
Source code
Test data
Old system

▪ Boehm’s Model
Boehm proposed a model for the maintenance process based upon
the economic models and principles.
Boehm represent the maintenance process as a closed loop cycle.
Software
Maintenance

Software
Maintenance
Management decisions
Change
implementation
Evaluation
Approved changes
Proposed changes
New version of
software
Results
Fig. 6: Boehm’s model

Software
Maintenance
▪ Taute Maintenance Model
It is a typical maintenance model and has eight phases in cycle fashion. The
phases are shown in Fig. 7
Fig. 7: Taute maintenance model

Software
Maintenance
Phases :
1. Change request phase
2. Estimate phase
3. Schedule phase
4. Programming phase
5. Test phase
6. Documentation phase
7. Release phase
8. Operation phase

Software
Maintenance
Estimation of maintenance costs
Phase Ratio
Analysis 1
Design 10
Implementation 100
Table 3: Defect repair ratio

Software
Maintenance
▪ Belady and Lehman Model
M = P + Ke (c-d)
where
M : Total effort expended
P : Productive effort that involves analysis, design, coding, testing and
evaluation.
K : An empirically determined constant.
c : Complexity measure due to lack of good design and documentation.
d : Degree to which maintenance team is familiar with the software.

Software
Maintenance
Example – 9.1
The development effort for a software project is 500 person months. The
empirically determined constant (K) is 0.3. The complexity of the code is
quite high and is equal to 8. Calculate the total effort expended (M) if
(i) maintenance team has good level of understanding of the project (d=0.9)
(ii) maintenance team has poor understanding of the project (d=0.1)

Software
Maintenance
Solution
Development effort (P) = 500 PM
K = 0.3
C = 8
(i) maintenance team has good level of understanding of the project (d=0.9)
M = P + Ke (c-d)
= 500 + 0.3e(8-0.9)
= 500 + 363.59 = 863.59 PM
(ii) maintenance team has poor understanding of the project (d=0.1)
M = P + Ke (c-d)
= 500 + 0.3e(8-0.1)
= 500 + 809.18 = 1309.18 PM

Software
Maintenance
▪ Boehm Model
Boehm used a quantity called Annual Change Traffic (ACT).
“The fraction of a software product’s source instructions which undergo
change during a year either through addition, deletion or modification”.
ACT 
KLOCadded  KLOCdeleted
KLOCtotal
AME = ACT x SDE
Where, SDE : Software development effort in person months
ACT : Annual change Traffic
EAF : Effort Adjustment Factor
AME = ACT * SDE * EAF

Software
Maintenance
Example – 9.2
Annual Change Traffic (ACT) for a software system is 15% per year. The
development effort is 600 PMs. Compute estimate for Annual Maintenance
Effort (AME). If life time of the project is 10 years, what is the total effort of
the project ?

Software
Maintenance
Solution
The development effort = 600 PM
Annual Change Traffic (ACT) = 15%
Total duration for which effort is to be calculated = 10 years
The maintenance effort is a fraction of development effort and is assumed to
be constant.
AME = ACT x SDE
= 0.15 x 600 = 90 PM
Maintenance effort for 10 years = 10 x 90 = 90 PM
Total effort = 600 + 900 = 1500 PM

Software
Maintenance
Example – 9.3
A software project has development effort of 500 PM. It is assumed that 10%
code will be modified per year. Some of the cost multipliers are given as:
1. Required software Reliability (RELY) : high
2. Date base size (DATA) : high
3. Analyst capability (ACAP) : high
4. Application experience (AEXP) : Very high
5. Programming language experience (LEXP) : high
Other multipliers are nominal. Calculate the Annual Maintenance Effort
(AME).

Software
Maintenance
Solution
Annual change traffic (ACT) = 10%
Software development effort (SDE) = 500 Pm
Using Table 5 of COCOMO model, effort adjustment factor can be
calculated given below :
RELY = 1.15
ACAP = 0.86
AEXP = 0.82
LEXP = 0.95
DATA = 1.08

Software
Maintenance
Other values are nominal values. Hence,
EAF = 1.15 x 0.86 x 0.82 x 0.95 x 1.08 = 0.832
AME = ACT * SDE * EAF
= 0.1 * 500 * 0.832 = 41.6 PM
AME = 41.6 PM

Software
Maintenance
Regression Testing
Regression testing is the process of retesting the modified parts of the
software and ensuring that no new errors have been introduced into
previously test code.
“Regression testing tests both the modified code and other parts of the
program that may be affected by the program change. It serves many
purposes :
➢ increase confidence in the correctness of the modified program
➢ locate errors in the modified program
➢ preserve the quality and reliability of software
➢ ensure the software’s continued operation

Software
Maintenance
▪ Development Testing Versus Regression Testing
Sr.
No.
Development testing Regression testing
1. We create test suites and test plans We can make use of existing test suite and
test plans
2. We test all software components We retest affected components that have
been modified by modifications.
3. Budget gives time for testing Budget often does not give
time for regression testing.
4. We perform testing just once on
a software product
We perform regression testing many times
over the life of the software product.
5. Performed under the
pressure of
release date of the software
Performed in crisis situations, under greater
time constraints.

▪ Regression Test Selection
Regression testing is very expensive activity and consumes significant
amount of effort / cost. Many techniques are available to reduce this effort/
cost.
1. Reuse the whole test suite
2. Reuse the existing test suite, but to apply a regression test
selection technique to select an appropriate subset of the test suite
to be run.
Software
Maintenance

Fragment A Fragment B
(modified form of
A)
S1 y = (x - 1) * (x + 1) S1’ y = (x -1) * (x + 1)
S2 if (y = 0) S2’ if (y = 0)
S3 return (error) S3’ return (error)
S4 else S4’ else
S5
1
return
y
S5’
1
return
y  3
Fig. 8: code fragment A and B
Software
Maintenance

Software
Maintenance
Test cases
Test number Input Execution History
t1 x = 1 S1, S2, S3
t2 x = -1 S1, S2, S3
t3 x = 2 S1, S2, S5
t4 x = 0 S1, S2, S5
Fig. 9: Test cases for code fragment A of Fig. 8

Software
Maintenance
If we execute all test cases, we will detect this divide by zero fault. But we
have to minimize the test suite. From the fig. 9, it is clear that test cases t3
and t4 have the same execution history i.e. S1, S2, S5. If few test cases have
the same execution history; minimization methods select only one test case.
Hence, either t3 or t4 will be selected. If we select t4 then fine otherwise fault
not found.
Minimization methods can omit some test cases that might expose fault in
the modified software and so, they are not safe.
A safe regression test selection technique is one that, under certain
assumptions, selects every test case from the original test suite that can
expose faults in the modified program.

Software
Maintenance
▪ Selective Retest Techniques
Selective retest techniques may be more economical than the “retest-all”
technique.
Selective retest techniques are broadly classified in three categories :
1. Coverage techniques : They are based on test coverage criteria.
They locate coverable program components that have been modified,
and select test cases that exercise these components.
2. Minimization techniques: They work like coverage techniques,
except that they select minimal sets of test cases.
3. Safe techniques: They do not focus on coverage criteria; instead they
select every test case that cause a modified program to produce
different output than its original version.

Software
Maintenance selection
Rothermal identified categories in which regression test
techniques can be compared and evaluated. These categories are:
Inclusiveness measures the extent to which a technique chooses test
cases that will cause the modified program to produce different output than
the original program, and thereby expose faults caused by modifications.
Precision measures the ability of a technique to avoid choosing test cases
that will not cause the modified program to produce different output than
the original program.
Efficiency measures the computational cost, and thus, practically, of a
technique.
Generality measures the ability of a technique to handle realistic and
diverse language constructs, arbitrarily complex modifications, and realistic
testing applications.

Software
Maintenance
Reverse Engineering
Reverse engineering is the process followed in order to find difficult,
unknown and hidden information about a software system.

Software
Maintenance
▪ Scope and Tasks
The areas there reverse engineering is applicable include (but not limited to):
1. Program comprehension
2. Redocumentation and/ or document generation
3. Recovery of design approach and design details at any level of
abstraction
4. Identifying reusable components
5. Identifying components that need restructuring
6. Recovering business rules, and
7. Understanding high level system description

Software
Maintenance
Programming/
implement domain
Fig. 10: Mapping between application and domains program
Mapping
Reverse Engineering encompasses a wide array of tasks related to understanding
and modifying software system. This array of tasks can be broken into a number of
classes.
➢ Mapping between application and program domains
Problem/
application domain

Software
Maintenance
➢ Mapping between concrete and abstract levels
➢ Rediscovering high level structures
➢ Finding missing links between program syntax and
semantics
➢ To extract reusable component

Software
Maintenance
▪ Levels of Reverse Engineering
Reverse Engineers detect low level implementation constructs and replace
them with their high level counterparts.
The process eventually results in an incremental formation of an overall
architecture of the program.

Software
Maintenance
Fig. 11: Levels of abstraction

Software
Maintenance
Redocumentation
Redocumentation is the recreation of a semantically equivalent
representation within the same relative abstraction level.
Design recovery
Design recovery entails identifying and extracting meaningful higher level
abstractions beyond those obtained directly from examination of the source
code. This may be achieved from a combination of code, existing design
documentation, personal experience, and knowledge of the problem and
application domains.

Software
Maintenance
Software RE-Engineering
Software re-engineering is concerned with taking existing legacy systems
and re-implementing them to make them more maintainable.
The critical distinction between re-engineering and new software
development is the starting point for the development as shown in Fig.12.

Software
Maintenance
Fig. 12: Comparison of new software development with re-engineering
System
specification
Design and
implementation
New system
Existing
software
system
Understanding
and
transformation
Re-engineered
system

Software
Maintenance
The following suggestions may be useful for the modification of the legacy
code:
✓ Study code well before attempting changes
✓ Concentrate on overall control flow and not coding
✓ Heavily comment internal code
✓ Create Cross References
✓ Build Symbol tables
✓ Use own variables, constants and declarations to localize the effect
✓ Keep detailed maintenance document
✓ Use modern design techniques

Software
Maintenance
▪ Source Code Translation
1. Hardware platform update: The organization may wish to
change its standard hardware platform. Compilers for the original
language may not be available on the new platform.
2. Staff Skill Shortages: There may be lack of trained
maintenance staff for the original language. This is a particular
problem where programs were written in some non standard
language that has now gone out of general use.
3. Organizational policy changes: An organization may decide to
standardize on a particular language to minimize its support
software costs. Maintaining many versions of old compilers can
be very expensive.

Software
Maintenance
▪ Program Restructuring
1. Control flow driven restructuring: This involves the imposition
of a clear control structure within the source code and can be
either inter modular or intra modular in nature.
2. Efficiency driven restructuring: This involves restructuring a
function or algorithm to make it more efficient. A simple example
is the replacement of an IF-THEN-ELSE-IF-ELSE construct with
a CASE construct.

Software
Maintenance
Fig. 13: Restructuring a program

Software
Maintenance
3. Adaption driven restructuring: This involves changing the
coding style in order to adapt the program to a new programming
language or new operating environment, for instance changing
an imperative program in PASCAL into a functional program in
LISP.

Software
Maintenance
Configuration Management
The process of software development and maintenance is controlled is
different in development and maintenance phases of life cycle due
called configuration management. The configuration management is
to
different environments.
▪ Configuration Management Activities
The activities are divided into four broad categories.
1. The identification of the components and changes
2. The control of the way by which the changes are made
3. Auditing the changes
4. Status accounting recording and documenting all the activities
that have take place

Software
Maintenance
The following documents are required for these activities
✓ Project plan
✓ Software requirements specification document
✓ Software design description document
✓ Source code listing
✓ Test plans / procedures / test cases
✓ User manuals

Software
Maintenance
▪ Software Versions
Two types of versions namely revisions (replace) and variations (variety).
Version Control :
A version control tool is the first stage towards being able to manage
multiple versions. Once it is in place, a detailed record of every version of
the software must be kept. This comprises the
✓ Name of each source code component, including the variations and
revisions
✓ The versions of the various compilers and linkers used
✓ The name of the software staff who constructed the component
✓ The date and the time at which it was constructed

Software
Maintenance
▪ Change Control Process
Change control process comes into effect when the software and
associated documentation are delivered to configuration management
change request form (as shown in fig. 14), which should record the
recommendations regarding the change.

Software
Maintenance
Fig. 14: Change request form

Software
Maintenance
Documentation
Software documentation is the written record of the facts about a
software system recorded with the intent to convey purpose, content
and clarity.

Software
Maintenance
▪ User Documentation
S.No. Document Function
1. System Overview Provides general description of system’s functions.
2. Installation Guide Describes how to set up the system, customize it to
local hardware needs and configure it to particular
hardware and other software systems.
3. Beginner’s Guide Provides simple explanations of how to start using
the system.
4. Reference Guide Provides in depth description of each system facility
and how it can be used.
5. Enhancement Booklet Contains a summary of new features.
6. Quick reference card Serves as a factual lookup.
7. System administration Provides information on services such
as net- working, security and
upgrading.
Table 5: User Documentation

Software
Maintenance
▪ System Documentation
It refers to those documentation containing all facets of system, including
analysis, specification, design, implementation, testing, security, error
diagnosis and recovery.

Software
Maintenance
▪ System Documentation
1. System Rationale Describes the objectives of the entire system.
2. SRS Provides information on exact
requirements of system as agreed
between user and developers.
3. Specification/ Design Provides description of:
(i) How system requirements are implemented.
(ii) How the system is decomposed into a set
of interacting program units.
(iii) The function of each program unit.
4. Implementation Provides description of:
(i) How the detailed system design is expressed
in some formal programming language.
(ii) Program actions in the form of intra program
comments.

Software
Maintenance
5. System Test Plan Provides description of how program units are
tested individually and how the whole system is
tested after integration.
6. Acceptance Test Plan Describes the tests that the system must
pass before users accept it.
7. Data Dictionaries Contains description of all terms that relate to the
software system in question.
Table 6: System Documentation

(b) Software Engineering
(d) Re-engineering
(a) Inverse Engineering
(c) Reverse Engineering
2. Regression testing is primarily related to
(a) Functional testing
(c) Development testing
(b) Data flow testing
(d) Maintenance testing
9.3 Which one is not a category of maintenance ?
(a) Corrective maintenance
(c) Adaptive maintenance
(b) Effective maintenance
(d) Perfective maintenance
9.4 The maintenance initiated by defects in the software is called
(b) Adaptive maintenance
(d) Preventive maintenance
(a) Corrective maintenance
(c) Perfective maintenance
9.5 Patch is known as
(a) Emergency fixes
(c) Critical fixes
MultipleChoice Questions
Note: Choose most appropriate answer of the following questions:
9.1 Process of generating analysis and design documents is called
Software Engineering, By K.K Aggarwal & Yogesh Singh, New Age International Publishers 64
(b) Routine fixes
(d) None of the above

9.6 Adaptive maintenance is related to
(a) Modification in software due to failure
(b) Modification in software due to demand of new functionalities
(c) Modification in software due to increase in complexity
(d) Modification in software to match changes in the ever-changing environment.
9.7 Perfective maintenance refers to enhancements
(a) Making the product better
(b) Making the product faster and smaller
(c) Making the product with new functionalities
(d) All of the above
9.8 As per distribution of maintenance effort, which type of maintenance has
consumed maximum share?
(a) Adaptive
(c) Perfective
(b) Corrective
(d) Preventive
Multiple Choice
Questions
9.9 As per distribution of maintenance effort, which type of maintenance has
consumed minimum share?
(a) Adaptive
(c) Perfective
(b) Corrective
(d) Preventive

(b) Iterative Enhancement model
9.10 Which one is not a maintenance model ?
(a) CMM
(c) Quick-fix model (d) Reuse-Oriented model
Multiple Choice
Questions
9.11 In which model, fixes are done without detailed analysis of the long-term effects?
(b) Quick-fix model
(a) Reuse oriented model
(c) Taute maintenance model
9.12 Iterative enhancement model is a
(a) three stage model
(c) four stage model
9.13 Taute maintenance model has
(a) Two phases
(c) eight phases
9.14 In Boehm model, ACT stands for
(a) Actual change time
(c) Annual change traffic
(b) two stage model
(d) seven stage model
(b) six phases
(d) ten phases
(b) Actual change traffic
(d) Annual change time

9.15 Regression testing is known as
(a) the process of retesting the modified parts of the software
(b) the process of testing the design documents
(c) the process of reviewing the SRS
9.16 The purpose of regression testing is to
(a) increase confidence in the correctness of the modified program
(b) locate errors in the modified program
(c) preserve the quantity and reliability of software
9.17 Regression testing is related to
(a) maintenance of software
(c) both (a) and (b)
(b) development of software
(d) none of the above.
Multiple Choice
Questions
9.18 Which one is not a selective retest technique
(a) coverage technique
(c) safe technique
(b) minimization technique
(d) maximization technique

9.19 Purpose of reverse engineering is to
(a)recover information from the existing code or any other intermediate
document
(b) redocumentation and/or document generation
(c) understand the source code and associated documents
9.20 Legacy systems are
(b) new systems
(a) old systems
(c) undeveloped systems
9.21 User documentation consists of
(a) System overview
(c) Reference guide
(b) Installation guide
Multiple Choice
Questions
9.22 Which one is not a user documentations ?
(a) Beginner’s Guide
(c) SRS
(b) Installation guide
(d) System administration

9.23 System documentation may not have
(a) SRS
(c) Acceptance Test Plan
(b) Design document
(d) System administration
9.24 The process by which existing processes and methods are replaced by new
techniques is:
(a) Reverse engineering
(c) Software configuration management
(b) Business process re-engineering
(d) Technical feasibility
9.25 The process of transforming a model into source code is
(a) Reverse Engineering
(c) Re-engineering
(b) Forward engineering
(d) Restructuring
Multiple Choice
Questions

Exerci
ses
1. What is software maintenance? Describe various categories of
maintenance. Which category consumes maximum effort and why?
2. What are the implication of maintenance for a one person software
production organisation?
3. Some people feel that “maintenance is manageable”. What is your
opinion about this issue?
4. Discuss various problems during maintenance. Describe some solutions
to these problems.
5. Why do you think that the mistake is frequently made of considering
software maintenance inferior to software development?
6. Explain the importance of maintenance. Which category consumes
maximum effort and why?
7. Explain the steps of software maintenance with help of a diagram.
8. What is self descriptiveness of a program? Explain the effect of this
parameter on maintenance activities.

Exerci
ses
9. What is ripple effect? Discuss the various aspects of ripple effect and
how does it affect the stability of a program?
10. What is maintainability? What is its role during maintenance?
11. Describe Quick-fix model. What are the advantage and disadvantage of
this model?
12. How iterative enhancement model is helpful during maintenance?
Explain the various stage cycles of this model.
13. Explain the Boehm’s maintenance model with the help of a diagram.
14. State the various steps of reuse oriented model. Is it a recommended
model in object oriented design?
15. Describe the Taute maintenance model. What are various phases of this
model?
16. Write a short note on Boledy and Lehman model for the calculation of
maintenance effort.

Exerci
ses
17. Describe various maintenance cost estimation model.s
18. The development effort for a project is 600 PMs. The empirically
determined constant (K) of Belady and Lehman model is 0.5. The
complexity of code is quite high and is equal to 7. Calculate the total
effort expended (M) if maintenance team has reasonable level of
understanding of the project (d=0.7).
19. Annual change traffic (ACT) in a software system is 25% per year. The
initial development cost was Rs. 20 lacs. Total life time for software is
10 years. What is the total cost of the software system?
20. What is regression testing? Differentiate between regression and
development testing?
21. What is the importance of regression test selection? Discuss with help of
examples.
22. What are selective retest techniques? How are they different from
“retest-all” techniques?

Exerci
ses
23. Explain the various categories of retest techniques. Which one is not
useful and why?
24. What are the categories to evaluate regression test selection techniques?
Why do we use such categorisation?
25. What is reverse engineering? Discuss levels of reverse engineering.
26. What are the appropriate reverse engineering tools? Discuss any two
tools in detail.
27. Discuss reverse engineering and re-engineering.
28. What is re-engineering? Differentiate between re-engineering and new
development.
29. Discuss the suggestions that may be useful for the modification of the
legacy code.
30. Explain various types of restructuring techniques. How does
restructuring help in maintaining a program?

Exerci
ses
31. Explain why single entry, single exit modules make testing easier during
maintenance.
32. What are configuration management activities? Draw the performa of
change request form.
33. Explain why the success of a system depends heavily on the quantity of
the documentation generated during system development.
34. What is an appropriate set of tools and documents required to maintain
large software product/
35. Explain why a high degree of coupling among modules can make
maintenance very difficult.
36. Is it feasible to specify maintainability in the SRS? If yes, how would
we specify it?
37. What tools and techniques are available for software maintenance?
Discuss any two of them.

Exerci
ses
38. Why is maintenance programming becoming more challenging than
new development? What are desirable characteristics of a maintenance
programmer?
39. Why little attention is paid to maintainability during design phase?
40. List out system documentation and also explain their purpose.

Module IV (1).pptx for software emgineee

More Related Content

Similar to Module IV (1).pptx for software emgineee (20)

Recently uploaded (20)

Module IV (1).pptx for software emgineee