48

Software Engineering (SPPU_IT) Quick Read

Unit V

Chapter-13:Quality Concepts
Whatissoftware qualty? Explain software
a.1 qualitydimensions/parameters. SPPU: May 15, Dec. 15, May 19,61Marks
Ans.

Software Quality
The most software developers will agree that high-quality software is
important goal. In the most general
an

sense, software quality is conformance to explicitly stated, functional and performance requirements, explicitdy
documented development standards, and implicit characteristies that are expected of all professionally
developed software.
The definition emphasizes three important points:
1. Software requirements are the basis for software quality measurement. If requirements are not satisfied then
obviously it will yield low quality software
2. For the development processes, some standards are specified that define the development criteria These
development criteria will guide software engineering process. If the criteria are not followed property then
the quality of the product will be quite low.
3. There are two types
ofrequirements:
Implicit requirements and
Explicit requirements
Even if the explicit requirements are considered, the quality may be degraded if it fails to meet impit
requirements.
Software quality is a complex mix of factors that will vary across different applications and the customers who
request them.
a.2 Explain different McCall's quality factors.
SPPU: Dec.15,May 16, 4 Markss
Ans.:

McCall's Quality Factors

The factors that affect software quality can be categorized in two broad groups:

o Factors that can be directly measured (eg. defects uncovered during testing) and

o Factors that can be measured only indirectly (eg, usability or maintainability)

The categorization of factors that affect software quality shown in Fig 13.1, Focus on three important aspects of
a software product:
1. Its operational characteristics,

2. Its ability to undergo change and

Its adaptability to new environments
3.

Cescasy-soTutions
 Software Engineering (SPPU IT) Quick Read
Maintainablity Portabsiy
edbility Reusabliy
Testabiy
PRODUCT PRODUCTN
EVISION TRANSITON

PRODUCT OPERATION

Corectness Usabiliny Eicenoy

Relabity Integnty
factors
Fig. 13.1: McCall's software quality
Referring to the factors noted in Fig. 13.1, provide the following descriptions:
1. Correctness: The correctness is the quality factor that assesses the software for its correct functioning
according to the specification and customer's requirements.
for its working according to the desired
Reliability: It is the quality attribute that evaluates the software
precision.
to It
The software usability is defined as the degree to which the application software is easy
use.
3. Usability:
defines the efforts taken to operate and learn, submit input and interpret output.
Efficiency: It is defined as the amount of various resources required to execute a given program. The computing

resources are memory devices, processing devices and input output devices etc.
the problems in functioning of a
Maintainability: It is defined as the effort needed to
uncover the errors and
program and resolve these errors.
6. Integrity: The integrity of a system is defined as the efforts taken to manage access authorization. The integrity
to it
of a system can be ensured by controlling all the accesses
7. Flexibility : The ease with which a program can be modified and extended in future.
8. Testability : Amount of time and the efforts taken to test a program

environment to another.
Portability: Shifting a program from
one
9.

10. Reusability : How existing codes can be reused

in future developments according to the scope of the sottware
11. Interoperability: Ability to connect one system to the another system.

a.3 Explain ISO 9126 Quality Factors. SPPU : May 12. Dec. 16, 5Marks
Ans.: ISO 9126 Quality Factors attributes for computer software. The
The ISO 9126 standard developed in an attempt
was to identify quality
attributes:
standard identifies six key quality
be available for the use and should satisty following key attributes
1 Reliability: The software should
Maturity
failures
o Fault tolerance i.e. ability to withstand against
its original state once the failure occurs. It should also ensure
o Recoverability iLe. the system should regain
and consistency while recovering from failure states.
the data integrity
the system should be able to work in different hardware and software
2. Portability: Portability means
to the following attributes:
environments according

o Installability

Adaptability
Ces casysolations
Software Engineering (SPPU_IT) 0 Qulck Rend
o Conformance

oReplaceability
3. Eicdency: Eiticiency means making the optimal use of the system resources like memory devlces, processing
devices and input output devices etc. It should take into conslderation following attributes:

Time behaviour and

o Resource behaviour
4 Maintainability : Maintainability is defined as the ease with wich the software may be repaired and ready to
use once again. The maintainability should take into consideration following attributes

o Changeability
o Testability
o Stability and

o. Analyzability
5. Functionality: The degree to which the application software satisfies the customer's needs and requirements
according to the following attributes

Accuracy ofworking model

oSuitabilityofthe product
o Interoperability (i.e. the product can be connected to any system),
o Compliance and
o Security
6. Usability: The software usability is defined as the degree to which the application software is easy to use
according to the following usability attributes:
o . Understandability of the software by the end-uses
o Learnability means learning the use of the product and
o Operability.
The IS0 9126 factors do not support direct measurement of quality, but provides indirect measurement.
It provides a very good checklist for evaluating the quality.

a.4 What are different metrics are availlable for software quality control7 How they control qualty of software ? (6 Marks)
Ans.: Quality Metrics

Quality metrics are a key component of an effective quality management plan and are the measurements used in
ensuring customers receive acceptable products or deliverables. Quality metries are used to directly translate
customer needs into acceptable performance measures in both products and processes.
Project managers must be able to assess the progress, efficlency, and performance of their projects and metrics
are the means which allow project managers to do this. However, it is important to note that metrics must be
established in an effort to directly Improve the product or processes Involved in the project.
The Software Qualty metrics are classifñed into three broad categories
1. Product metrics

2. Process metrics

Ces0asy-SOlutlons
 Qulck Read
Software Engineering(SPPU_IT) 51

3. Project metrics
Sofware quality metrics are a subset software metrics that focus on the quality aspects of the prouu process,

and project. These are more closely associated with process and product metrics than with project metre

Product Metrics
Describes the characteristics of the product such as size, complexity, design features, performance, and ty

level.
The terms measure, measurement, and metrics are often used interchangeably.
within tne software engineering context, a measure provides a quantitative indication of the extent, amoun

dimension, capacity, or size of some attribute of a product or process.

Measurement is the act

of determining a measure
The IEEE Standard defines metric as "a quantitative measure of the degree to which a system, component,

process poSsesses a given attribute."

Measurement occurs as the result of the collection of one or more data points (eg, a number of component

reviews and unit tests are investigated to collect measures of the number of errors for each).

Software metric relates the individual measures in some way, e.g, the average number of errors tound per

review or the average number of errors found per unit test.

The Challenge of Product Metrics

a
decades, many researchers have attempted to develop a single metric that provides
O v e r the past three
comprehensive measure of software complexity.
is
have been proposed, each takes a somewhat different view of what complexity
Dozens of complexity measures

complexity. There is a need to measure and control software complexity.

and what attributes ofa system lead to

is really very complicated to measure, because

Ifwe consider metric for evaluating an attractive car, this
a

of attraction. In case of software metric, the problem

occurs.
everybody will be having their own definition
Measurement is
but it is no reason to dismiss product metrics.
Each of the "challenges" is a cause for caution,
essential if quality is to be achieved.

Measurement Principles
series of product metrics, it is important to understand basic measurement principles.
Before we introduce a

be characterized by five activities:

Measurement process that can

and metrics appropriate for the representation of the

o Formulation: The derivation of software measures

software that is being considered.

Collection: The mechanism used
to accumulate data required to derive the formulated metrics.
and the application of mathematical tools.
of metrics
Analysis: The computation
etort to gain insight into the quality of the representation.
The evaluation of metrics in an
o Interpretation:
metrics transmitted to the
o Feedback Recommendations
derived from the Interpretation of product
software team.
and validated so that their worth is
useful only if they are characterized etffectively
Software metrics will be
can be proposed lor metrics characterization and validation:
some principles that
proven.The following are

CeseasyS0lutions
Software Engineering (SPPU IT) 52 Quick Read
A metric should have deslrable mathematical properties. That is, the metric's value should be in a meaningful
range. Also, a metric that purports to be on a rational scale should not be composed of components that are only
measured on an ordinal scale.
wnen a menic represents a software characteristic that increases when positive traits occur or decreases when

undesirable
traltsencountered, the value of the metric should increase or decrease in the same manner
are

Each metric shauld be validated empirically in a wide variety of contexts before being published or used to make
decisions.

Process Metrics

This metrics describe the project characteristics and execution. Examples include the number of software
developers, the staffing pattern over the life cycle of the software, cost, schedule, and productivity.
Process metrics or measurements are acquired across all projects and over long intervals of time. Their intent is
to provide a set of process indicators that lead to
long-term software process improvement.
Project metrics permit a software project manager to perform the following:
o Assess the status of an ongoing project,
o Track potential risks,
o Uncover problem areas before they go "critical,"
o Adjust work flow or tasks, and

Evaluate the project team's ability control

to quality of software work
Process Metrics and Software Process
Improvement
The only logical and reasonable way to escalate any
process is to measure specific traits of the process, develop a
set of understandable metrics based on these attributes, and then use the metrics
to provide pointers that will
lead to a plan for improvement.
Product

Customer Business
charactenstics conditions

Process

People Technology
Development
environment

Fig. 13.2: Determinants for software qualty and organizatlonal effectivenesss

.Referring to Fig. 13.2, process sits at the centre of a triangle connecting three factors that have a profound
influence on software quality and organizational performance.
.The skill and motivation of people has been shown to be the single most influential factor în quality and
performance. The complexity of the product can have a substantial impact on quality and team performance. The
technology that populates the process also has an Impact.

Ceseasy-solutions
Software Engineering(SPPU_IT) 53 Quick Read
Project Metrics
S o f t w a r e project metrics are tactical. i e , project metrlcs and the indicators derived from them are uSed oy a

project manager and a software team to adapt project workflow and technical activities
The first application of project metrics on most software projects occurs during estimation.
As a project proceeds, measures of effort and calendar time expended are compared to original estimates and the

project schedule.

As technical work commences, other project metrics begin to have significance.

In addition, errors uncovered during each software engineering task are tracked.
The intent of project metrics is twofold.

o First, to avoid delays and mitigate potential problems and risks.

oSecond, project metrics are used to assess product quality on an ongoing basis and, when necessary, modir
the technical approach to improve quality.

escasy-solutions
Software Engineering (SPPU_IT) 54
Quick Read

Chapter 14: Software Testing

Q.1 What is software testing ?
Ans. :
Introduction to Software Testing SPPU:Dec. 13, Dec. 14, 4 Marks
Testing is an important activity in software
planned and is conducted very development process. Before the start of the
development, testing is
systematically. In order to implement the testing, there are various
strategies defined in the software engineering literature. testing
All these
strategies provide,a testing template to
the developers. The
characteristics that is applicable to
testing templates should possess following
software development
any
o For effective testing, formal process
technical reviews
o
Frequent communication between must be conducted by the development team.
in the developer and customer resolves most of
beginning itself. Thus before start of the the complexities and confusion
fixed. testing process, number of errors may be
uncovered and then
Testing starts from the component level and then
the end. finally complete computer based
system is integrated at
o
There are various testing
may be applied. techniques are available. So at different point of time, suitable testing
Testing may be conducted by the technique
software developer
projects, an independent itself for usually smaller projects.
group (especially those people For the
ired for
conducting an effective testing. that are not the part of larger
The members of development team) may be
independent testing group may be the
Even though testing and
member of some other team
testing strategies. debugging are two separate activities,
or
may be outsourced.
Any testing strategy
debugging should be
accommodated
should be able to in
be easily implemented. conduct low level
tests, since it verifies small source code
Itgives better precision. In addition modules and can
level.tests and it should be able these low level
to
tests, a
testing strategy should also
to validate all the major be able
Q.2 What are the
principles of
functionalities as per
customer's
to
conduct high
software testing
Ans.:
Principles of Testing
? requirements.
A
good software engineer must SPPU: Dec. 15. 5 Marks
methods to effective test understand the basic
cases.
Following principles for
1. All tests should be are the set
of testing principles software testing before he can
traceable
failures. Any inference about to
customer
that have been apply various
requirements Its suggested
follows that the most severe quality the responsibility of
:
is single goal is to
defects are those that quality assurance but uncover faults by
2. Tests should be cause the
program to fail to meetbeyond the triggering
model is ready. All planned long before testing
begins: Test planning can its scope of testing. It
tests can be
planned and designed requirements.
3. The Pareto before any code begin as soon
principle
uncovered during testingapplies to software has been
generated.
as the
requirements
will likely be testing: Pareto
principle
traceable to 20
percent of all implies that 80
program components. percent of all
errors

es Casy:solutionsS
Software Engineering (SPPU_IT) 55 Quick Read
Testing should begin "in the small" and progress toward testing "in the large.": The first tests planned and
executed generally focus on individual components. As testing progresses, focus shifts in an attempt to nna

errors in integrated clusters of components and ultimately in the entire system.

5. Exhaustive testing is not possible : The number of path permutations for even a moderately sized program i3

exceptionally large. Therefore it is impossible to execute every combination of paths during testing
6. To be most effective, testing should be conducted by an independent third party: The software engineer
who created the system is not the best person to conduct all tests for the software. Therefore, to make the testng
effective, it is advisable to conduct the testing from the third person who is not involved in the development
process.

Q.3 Explain graph matrix. SPPU: May 13, 4 Marks

Ans.: Graph Matrix
A graph matrix is a tool that supports basis path testing, A graph matrix is defined as a square matrix whose sre
is equal to the number of nodes on the flow graph. The size of matrix means the number of rows and columns or

the square matrix.

Each of the row and column of graph matrix corresponds to an identified node. The matrix entries as shown in

simple flow, graph and its

Fig. 14.1 correspond to an edge between nodes (i.e. connections). An example of a

corresponding graph matrix is shown Fig. 14.1.

Each of the nodes on the flow graph is denoted by some numbers and the edges are represented by some letters

as shown in following Fig. 14.1

For example: Node 3 in the following diagram is connected to the node 4 by the edge b. This can be represented

in graph matrix by writing "b" in the corresponding cell.

Connected to

node 2 3 4 5
Node 1
1

Flow graph Graph matrlx

Fig. 14.1:Graph Matrix

tabular representation of a flow graph. By adding a link weight to each of the

The graph matrix is actually a

tool for testing program control structure.

matrix entry, it becomes a powerful

Q.4 Differentiate between condition and loop testing. SPPU: May 16, 4Marks
Ans.: Control Structure Testing
for control structure testing.
Basis path testing is one of the techniques
is not sufficient, other variations on control structure testing are discussed in the
Since basis path testing
of control structure testing are:
following sections. The examples
1. Condition Testing
2. Data Flow Testing

3. Loop Testing
CesCasy-solutions
Software Engineering (SPPU_IT) 56 Quick Read
1. Condition Testing
The condition testing is one of the test case design method. In condition testing, all the logical conditons in

the program or the program module are tested..

An example ofa simple condition may be a Boolean variable or a relational expression. The expression may
contain a single NOT operator
Any relational expression has the following simple form:
E <the relational operator >E
Where, E and E, are two arithmetic expressions and between them, any of the following relational operator
may be present:

Less than
<less than or equal to

Non-equality
Greater than
2Greaterthan or equal to
A condition may also be a compound condition and it consists of two or more simple conditions, Boolean
operators and parentheses.
2. Data Flow Testing
In dataflow testing approach, a test paths of a program is selected based on the locations of definitions and
uses of variables in the program.
To explain the data flow testing method, consider that each of statement in a program is assigned a unique
number. Also the functions and globalvariables do not modify their
parameters.
statement S (its
unique statement number) as follows:
Consider a
DEFX(S)={X| statement S contains a definition of X}
USEX(S) = X| statement S contains a use of X}

If statement S is an "if or "loop" statement, then its DEFX set is empty and its USEX set depends on the
condition of statement s.
The variable X at statement S is the live at statement S', if there is a path from statement S to statement S.
Also it should not contain any other definition of X.

a.5 Explain Loop Testing methods.

SPPU: May 13, 4 Marks
Ans.: Loop Testing
Loops are the important part of nearly all the programs in the sotware. Normally the developers pay very little
attention this while conducting tests,
The loop testing technique is in the category of a white-box testing. It focuses mainly on the validity of loop
constructs. In the following section, we define four classes ofloops
1. Simple loops
Following tests can be applied to simple loops, where n is the maximum number of passes through the

loop:
o Skip the whole loop.

es 0asy-solutions
 Qulck Read
Software Engineering(SPPU_IT) 57

o Only one pass allowed.

Only two passes allowed.
o m passes allowed through the loop where m <n.
o Also, the possiblities of n - 1, n and n+1 passes allowed.
2. Concatenated loops
In this
This concatenated loop approach can be implemented by using the approach discussed in simple ioop
each of the loops is independent of other. When loops are not independent, this approach is not Suitabic d

instead nested loop approach is suggested as discussed in the next point.

3. Nested loops
The nested loop approach is an extension of simple loop approach. By nesting the loops, the number or tesu

levels will be increased automatically. This might result in number of tests which may not be practically possibe

Following are some approaches that are suggested to reduce the number of tests :
o Start with the inner most loops and set all the other loops at minimum levels.
minimum interaction
o Now conduct the simple loop approach to innermost loop while hold other with their
value.
o Move outward to conduct simple test to the next loop and keeping its out loop value at minimum.

o Continue the same process till l the loops are exercised.

4. Unstructured loops (Fig. 14.2)
Whenever it is required, the loops should be redesigned by using structure using structured programming

constructs.

Nested loops
Simple loops
Concatenated
loops

Unstructured
l0ops

Fig. 14.2: Classes of loops

Q.6 Explain boundary value analysis testing SPPU : Dec. 16, 3 Marks
Ans.: Boundary Value Analysis
occurs at the
boundarles of the input domain and not at the "center" of it
Generally large number of
errors

Boundary Value Analysis (BVA). It has been developed and used as a testin
This is the reason why we require ditterent test cases to test
value anaiysis selecis and conaucts the
technique by the developers. Boundary
domain.
boundary values of input

es Casy-s0lutions
Software Engineering (SPPU JT)
BVA ISa test case design method in which the equtralence yartitinásg tskes plan. in sitr td vedeing v r e
of an equvalence dass,the boundary value analysis acuaiy sedects the R a s a t e ' d a dta t s
Here in boundary value analysis apprcach, the focus is not anly on tnst cnditans tost aln k o m e 510
conducts the test cases from the output values.
Following are some guidelines for boundary value analysis approach
o Ifan input condition selea a range between a and b then test ases shsd4 te desizpes tgrb the viss
and b. It means the input values may be just beln and just atme the vatues da and b
fan input condition selects the minimum and mazámum snumbers,then values just aiurne asd juz teln te
minimum and maximum values are also tested.

The above two guidelines are applied to output cnditons.

I f internal program or its data structures prescritsed some boandary velves like an array h 10 oniers
then the care must be taken to conduct the test cases up tw 10 entries onily ie. ts torudary
Most of the software developers perform boundary value analysis up w svme deggee only. Afer sprithaz ai
these guidelines on boundary value analysis testing, then it wil gre mare cnges vtrz an4 biher
probabilities of finding errors.

a.7 Explain Orthogenal Array testirg SPPU: Dec.16,3 Maks

Ans.: Orthogonal Array Testing
In various applications, the input domain is relatsvely iraited snd tence orthognal array testing is a god
opton in such situations. In orthogpnal aray testing the protles in vwhich the input domain is snall but it is
large enough to accommodate the ezdhaustive testing
The orthogonal array testing approach is especially used in detecting errors that are caused by the faulty kuge
within a software component
To explain the comparison between orthogonal array
testing and more coventional appruadts, onsider the
follawing system in which there are three inprt values ,Y and4z
All these input values have three discrete values associatedith each of it The proiablity of test a s is
3P27.
In the following Fig 143,a geometric vien of the pssible test cases aswciated are exglaited by comsidering the
input values ie. K, Y, and Z

One ingat inam at a time L5 wrthoremal array

Fig 143: A geometric vhew d test cases

esasy-1oletios
 Quick Readd
Software Engineering (SPPU_IT)
Refer the ig. 14.3, in that one Input value at a time is changing in accordance with the input a

obtained are generally having less coverage of the input values.

uenerauy
ra L9
a

is conducted.
An L9 orthogonal array of test cases is created whenever an orthogonal array testing noe

In this the test coverage

aray nas an important property called as balancing property.
ortnogona
complete with the input domain.
May 15. 4 Marks
a.8 DiffereDtiate between whlte box and black box testing. SPPU: May 12, Dec. 12,
Ans.: Differentiation between White-box and Black-box Testing
Black box testing
Sr. White box testing
No. behaviOural
known as
is also
White-box testing also called as glass-box testing. It Black-box testing on the functional
It focuses only
employs the test case design concept that uses the| testing.

control structures. These control structures are requirements of the software.

described as component-level design to derive the

test cases.
the software developer
The black-box testing helps
t guarantees the traversal of all independent paths conditions. These input
2. derive the sets of input
in module at least once. It refers the concept of to the functional requirements
a
must conditions exercise all
in tree
traversal of tree i.e. each of the nodes a

for a program.
be traversed at least once.
behavioural
errors or the
It evaluates performance
decisions and finds whether defined
It evaluates all logical errors. It evaluates missing
or incorrectly
the loops to
false. It evaluates all incorrect data structures
and
they are true or It functions. It evaluates
check their boundaries
and operational bounds. | database errors. It evaluates errors
to confirm external
and termination and
structures
evaluates all internal data initialization
occurred during
their validity. interface errors also.
The black box testing is applied in the final stages
in the testing
The white box testing begins early
t. of testing
methods are:
process.
methods Different black-box testing
testing
Differentt
white-boxx
Graph-Based Testing Method, Equivalence
are Partitioning, Boundary
Value Analysis,
Basis Path Testing,
Orthogonal Array Testing
Control Structure Testing
SPPU: May 14, 3 Marks
a.0 Explain validation testing
and Validation fulfilled by the
Ans.: Verification that ensures that all customer's requirements
are

Verification and validation

is a set ofactivities
and working correctly.
The Verification and Validation (V&V) is
functlons are implemented
software and all the
elements of software testing.
the
basically o n e of and it is traceable to all the customer's requirements.
software Is developed
ensures that the
The validation In following way:
validation
verlfication and
The Boehm defines right way ?
whether the developer build product in a
evaluating
Verification means
o built right product?
Validation m e a n s
the evaluating whether developer
o

Ces easy-solutionS
Software Engineering (SPPU_IT) 60 Quick Read
The V&V consists of different activities that are also the
part of sQA (Software Quality Assurance).
The software quallty assurance conslsts of
following important activities:
FTR
o
(Formal Technical Reviews): Frequent meetings between developer and customer to ensure effectivé
communication on technical part of the software.
o Performance monitoring

o
Quality and configuration audits
o Algorithm analysis

Development testing
Feasibility study
o Database review

o Simulation

o
Qualification testing and installation testing
o Documentation review

oUsability testing
Q.10 Differentiate between verification and
validation. SPPU: May 12, Dec. 13, 4Marks, Dec. 15, May 16, 4 Marks
Ans.: Difference between
Verification and Validation
Sr.
Verification Validation
No.

Verification is a set of activities that ensures that

all | The validation ensures
customer's requirements are that the software is

all the functions

fulfilled by software and developed and it is traceable
the
to all the |
are
implemented and working correctly. customer's requirements.
2. TheVerification is basically one of the elements of The
software testing. Validation is also one of the elements of
software testing
Verification means
evaluating whether the developer build| Validation means evaluating whether
product inarightway ? developer built right product?
Verification is static.
Validation is dynamic.
Verification evaluates all the documentation, the planning. | Validation means the evaluation of the
the coding. requirements and specifications. complete product itself.
6. Verification takes place before validation. Not vice versa.
The inputs for verification are:
The input for validation the
Technical
are:
complete
meetings, various issues, review meeting etc. testing of the product itself.
8.
The output of verification: The output
of validation
Flawless documents, perfect
plans and nearly completed The
perfect final product.
specifications along with requirement.

es 0asy-solutions
 Quick Read
Software Engineering(SPPU IT) 61
a. 11 Explain unit testing. SPPU: May 12, 4 Marks
Ans.: Unit Testing
o
like component
In unit testing the main focus is on assessment of smallest unit of the product design
and data
The unit has limited scope and it emphasizes on internal processing logic
software or
module. testing
structures. Multiple modules and components can be tested in paralle.
Unit test considerations

14.4
The unit testing is illustrated diagrammatically as follow in Fig.

Module Interface
Local data siructure8

Boundary condrions
Independent pains
Error handling paihsS

Test

Fig. 14.4:Unit test

to assess the proper flow of input
and output and
each of the module interface
T h e test strategy is conducted on
its correctness as per the requirements.
ensure its integrity in the execution of the algorithm.
structures are assessed to
Next, the local data and it keeps
called basis paths) are also evaluated through the control structure
All the independent paths (also module should have been executed
that at least each of the statements in a
the program and makes
sure
track on

once. boundaries or within the

also tested so that the software works properly within the
are
Boundary conditions
limits. All the error handling paths are tested.
unit testing methodolog
Thus the boundary testing is
one
of the significant
Unit test procedures unit test can be
is conducted. Before the start of coding,
In parallel with coding step,
usually unit testing
used in agile development process.
conducted. This method is most commonly
establish the test cases and uncover the errors.
for the developers to
The design information gives sufficient help
the set of results with the
test cases.
The developers always couple
Unit test environment
illustrated in Fig 14.4.
T h e unit
test environment is itself accepts all the
the "main program. This main program
driver is considered as
In most of the applications, a
side by side.
to the component under test
and the results are also printed
test case data and pass that data
that the stubs replace the modules
of the program and are tested next to
In the above diagram, we observe make an interface with the main
to be the subprogram. These subprograms
driver. The stub is also considered
the test.
program to complete

Cescasy-solutionsS
 sida 3eed

Exsrairg pts
Mense

sts

Fi 145:Uittet evheonmer
Laly bsth the drver ad sus sre the svtwae t a ae wren bt sn sienied to tte catomer aad t s
are unsitzed s te metesd. t is smays resnerded o keeg tse vehesd j e w rebrce te cm ez
wesnd can un e mate smge in all he caes ad terce tte vnt tesag can be potyred to tte i e g e i

a 12 Wroyuasad by etegdn Tesse EnJin criess Artegdne g SPPU:Des 19.61Mais

Ana. :Intagrion Testing
Istytm tstrg is we ta unsruinz tte skwase arch:aere. tis a sytemsic apprach íor andacing
t s to vama aortaing erons. The wain cbiptve beiind inttin vsinzs tu aep all te unit tested
Umans ad negae nna pruizam rucure zs gven by the dsizp
his o n hserves ths there is a tentercy v a n p anays non-iricreetal appractes. AI the component
e trysd n the veafnnhzagsd te progan s tedaa wtaie.
In this apprah a m d errrs are encmntered ad comeaia sens to be very difficuit due to isolation of
cws ad te vmpkstns by prungam since prugrasn is exzazded orea several modules. After coTTection of
tse erors,vme DEN TaJ apphat and tte procs ontszues. t knis ike an infinite kop
Snall rerenets oh te prunan are tesed in an incremestal approach. In incremental integratien approcach, the
err dewsn and vmeton ts euite simle. In this all te ntertacs ae tested completely ard thus a
sypemaa vemsrany na be applied.
Follhrgare diserert incremennal sntrzyatin straes:
0) Tup-down integratson
.Topdrm ineayatiun testing is one f the ineremental testing stratezjes fur construction of the software
architeture
All he madues are combined ty maorhng vp to drun direction through the control hierarchy. It begins with
the masin prnpan or the main wntrok module. The fiurw is from main module to ts subortinate modules in
degth-first on breadth-irst smanner.
Deth-irst integyatin hs situstrated in Fiy 146, and t integrates all the components on most of the control
yath d the pruyan.

Ces casy-solutions
 Quick Read
Software Engineering (SPPU_IT) 63

M
M2 MA

Ms M M

Fig. 14.6: Top-down integratlon

(2) Bottom-up integration

at the lowest
testing begins with the construction and components
In bottom-up integration testing, the
level. These components are called as atomic modules.
is always available for
Since the components are integrated from the bottom to top, the required processing
approach the need of stub is completed eliminated.
in all the levels. Here in this
components subordinate
disadvantage due to overhead.
The use of stub was actually a

of bottom-up integration strategy:

Following steps are required for implementation
perform sub function of a specific
are integrated to form clusters that can
The low-level components
software

inputs and outputs.

coordinate all the test case
A driver is needed to

Later all the clusters are tested.

direction in the
again from bottom to top
removed and all the clusters are integrated
once
Then, drivers are

program.
illustrated in Fig. 14.7.
Integration follows the pattern
Ma

*******

D D2 D
Cluster 3

Cluster 1

Cluster 2

Fig. 14.7: Bottom-up Integratlon

in such a fashion that they can form clusters 1, 2 and 3. These clusters are
The components are integrated
tested by using a driver (marked by a dashed block).
The components in clusters 1 and 2 are subordinate to module M,. The drivers D, and D, are then removed
and the clusters arc connected directly to M,

the driver D, for the cluster 3 is removed and then cluster 3 is directly connected
to
In the same way,
Here both the modules, M, and M, are finally integrated with the component M, and so on.
module M
CesCasy-solutions
Software Engineering (SPPU_IT) 54
Quick Read
Problems associated with Top down approach of testing
In incremental integration testing approach, a set of errors are encountered and correction seems to be very
difñicult due to isolation of causes and the complications by program since program is expanded over several
modules. After correction of these errors, some new may appear and the process continues. It looks like an
infinite loop.
Top-down integration testing is one of the incremental testing strategies for construction of the software
architecture.
The main problem with top down approach is that the test conditions are nearly impossible or they are
extremely dificult to create.
Stub modules are complicated.
Comments on Integration Testing
The selection ofany integration strategy is based on the software characteristics or the project schedule.
Generally a combined approach ie. both the top-down and bottom-up are used. It is called as sandwich testing
The top-down tests can be implemented for upper levels and bottom-up tests are implemented for subordinate
levels of the program. Actually the sandwich testing is the best compromise.
Integration Test Documentation

The complete test plan for integration testing is documented in a test specification.
This document encompasses a test plan and a test procedure that is actually a work product of the software
process, and it becomes the part of the software configuration.

Q.13 Ditferentiate between alpha and beta testing. SPPU: May 19, Dec. 19, 6 Marks
Ans.: Alpha and Beta Testing
It is very diffcult for a software developer to visualize how the end user will actually use his program. The
instructions for use may be read but not understood properly or some wrong meaning can be drawn. Also some
combinations of input may be regularly used and the output that is correct for tester but it is not satisfied by the
user in actual practice.
When customized software is developed for one customer, then a series of acceptance tests are necessary to
validate all the requirements by the customer
The acceptance test is conducted by the end-user rather than software developer. The need is to find the range of
Thus the acceptance test is well planned and is executed systematically. The series
input values by the customer.
of acceptance test are usually conducted to validate the requirements.
The acceptance testing is conducted over a period of weeks or months and thereby detecting the cumulative

errors. These may degradé the system over time.

errors

If the software is built as a product that is to be used by different customers, then it is practically not possible to

perform formal acceptance tests with each of the user.

In such a scenario, most of the software developers use alpha and beta testing to find those errors that can be

detected the end-user only.

The alpha test is conducted at developer's end by end-users. The end users work on the sotware and developer
has a keen observation on all nteractions of user with the software in an environment that is controlled by' the
developer. The developer keep on recording all the errors and problems encountered. Alpha tests are generally
conducted in a controlled environment.

es casy-solutions
 Software Engineering (SPPU IT) 65 Quick Read
The beta test is conducted at end-user place. Here the developer is generally not present. Hence the beta testis
supposed to be the "live" application of the software.
This environment is not controlled by the developer in contrast to the alpha testing that is done at developers
end.
In beta testing, the end-user will record all the problems (may be a real one or imaginary) that are encountered

and will report to the developer at regular basis.

Ater getting the reports from the end user, the developer will make modifications and then prepare the new

release of the software and deliver to the customer.

Difference between Alpha Testing and Beta Testing
Beta testing
Alpha testing
No.
Here the
1. The alpha test is conducted at developer's end by The beta test is conducted at end-user place.
the beta test
end-users. developer is generally not present. Hence
is supposed to be the "live" application of the software.

2. The end users work on thesoftware and developer| This environment is not controlled by the developer in
has a keen observation on all interactions of user contrast to the alpha testing that is done at developer's

with the software in an environment that is end.

controlled by the developer.

the and In beta testing, the end-user will record all the
The developer keep on recording all errors

Alpha tests are generally problems (may be a real one or imaginary) that are
problems encountered. encountered and ill report to the developer at regular
conducted in a controlled environment.
basis.

and In beta testing. user reports the problems and thus

4. Developer does not know the types of users
developer is able to correct errors.
hence unable control the errors.

this, the developer may modify after getting the

In this, developer may modify the codes at his site In
feedback from user and prepare the next release.
before the release.

?
SPPU: Dec. 13, 3 Marks
a. 14 What do you mean by recovery testing
Ans.: Recovery Testing9
from faults that are occurring and can resume back the normal
recover
The computer-based systems may
time. But in some cases, the system should be fault tolerant ie. it should continue
processing within a stipulated
to functioning despite failure.

must recovered back from the failure and corrected within a stipulated period of
In some other cases, the system
time.
then some drastic economic damage will take place. For example online shopping sites, banking
If not done so,

sites where the data is very sensitive and critical.

In recovery testing a system is forcefully sent to variety of way and testing is done
failed state in a to recover

test that the system is recovering properly from the failure state.
from those states. The motive is to

Ces casy-solutions
Software Englneering (SPPU_IT) 66
Qulck Read
If it is an automatic recovery, then re-Inltlalization, data
recovery, restart and check-polnting mechanisms are
evaluated for correcting the errors, If the recovery requlres human
Interventlon, then the Mean-Time-To-Repair
(l.e. MTTR) Is calculated to flnd whether It is In acceptable limlts or not.
a. 18 Write a ohort note on deloct management
SPPU: May 19, 4 Marks
Ans.: Defect Management

Software development teams and software

testing teams have numerous cholces of defect management tools to
help support thelr software defect efforts. Selecting and
defect management system.
utilízing an effective tool is really only part of an overall
From ahlgh-level view, defect management systems are made up of a combination of some defect
tools or tool and a defect management management
process.
These two primary
components work together to support each other. Ignore either one, and
can be expected. sub-optimal results
Following is an overview
of a typlcal defect
management process' and the key features to look for in an
defect effective
management tool. All of this Information will be useful to review.
Defect Management Process
High Level Steps in a typical defect management
process
The typlcal defect
management process includes the following high-level process steps. When
inside of a speciflc implemented
organlzation, each of these high-level steps would have more detailed standard
procedures along with operating
policies carry
to out the details of the process.
1. Identification This step involves the
discovery of a defect. Hopefully, the person discovering the defect is
someone on the
testing team. In the real world, it can be anyone including the other
team, or on rare occasions even the end-customer. individuals on the project
2. Categorization- When a defect is reported, it is typically assigned to a designated team member to confirm that
the defect is actually a defect as
opposed to an enhancement, or other appropriate category as defined the
organization. Once categorized, the defect moves on in the process to the next step which is prioritization. by
3. Prioritization Prioritization is typically based on a combination of the severity of impact on the user, relative
effort to fix, along with a comparison against other open defects. Depending on the size and
structure of the
organization, the priorltization is often handled by a formal change control board. The
should be
determined with priority
representation from
management, the customer, and the project team.
4. Assignment-Once a defect has been prioritized, it is then assigned to a developer or other technician to fix.
5. Resolution The developer fixes (resolves) the defect and follows the organization's process to move the fix to
the environment where the defect was originally identified.
6. Verification Depending on the environment where the defect was found and the fix was applied, the software
testing team or customer typically verifies that the fix actually resolved the defect.
7. Closure- Once a defect has been resolved and verified, the defect is marked as closed.
8. Management Reporting Management reports provided to
are
appropriate individuals at regular intervals as
defined reporting requirements. In addition, on-demand reports are provided on an as-needed basis.
Defect Removal Efficiency
A quality metric that provides benefits at both the project and process level is defect removal
efficiency (DRE).
DRE is a
measure of the filtering abilltyof quality assurance and control activities as
they are applied throughout
all process framework activities.

Ces0asy-$0lutions
 Software Bngineering (SPPU_IT) 57 Quick Read
DRE is defined in the following manner

DRE E/(E+D)
the end-user, and D the number o
Where, E is the number of errors found before delivery of the software to is
defects found after delivery.
D will be greater than 0,
The ideal value for DRE is 1. That is, no defects are found in the software. Realistically,
but the value of DRE can stll approach 1.
team individual software engineer) is to achieve DRE that approaches 1.
A quality objective fora software (or an
That is, errors should be filtered out before they are passed on to the next activity.

?
a. 16 Describe Defect lite Cycle
Ans.: Defect Life Cycle
which a defect goes through during8
D e f e c t life cycle, also known Bug Life cycle is the journey of a defect cycle,
as

and also from project to project as it is governed by the

its lifetime. It varies from organization to organization
software testing process and also depends upon the tools used.
lifetime. It starts when defect is found
and ends
Defect life cycle is a cycle which a defect goes through during its
life cycle is related to thee bug found during
when is closed, after ensuring it's not reproduced. Defect
a
defect
testing.
The number of states that a defect goes through varies from project to project. Following lifecycle diagram,
covers all possible states:

New

Assigned

Duplicate
rejected
detfered
not A Bug

Pending9
retest

ReOpened Retest

Verfled

Closed

Fig. 14.8:Defect Life Cycle

New: When a new defect is logged and posted for the first time. It is assigned a status NEW.
Assigned : Once the bug is posted by the tester, the lead of the tester approves the bug and assigns the bug to
developer team.

Ceseasy-solutionS
 68
Software Engineering(SPPU_IT) Qulck Read
Open: The developer starts analyzing and works on the defect fix
Fixed :When developer makes necessary code change and verifles the change, he or she can make bug status as
"Fixed."
Pending retest : Once the defect is fixed the developer gives particular code for retesting the code to the tester.
Since the testing remalns pending from the testers end, the status asslgned is "pending request."
Retest: Tester does the retesting of the code at this stage to check whether the defect is fixed by the developer
or not and change the status to "Re-test."
Verified: The tester re-tests the bug after it got fixed by the developer. If there is no bug detected in the
software, then the bug is fixed and the status assigned is "verified."
Reopen : If the bug persists even after the developer has fixed the bug, the tester changes the status to
"reopened".Once again the bug goes through the life cycle.
Closed: Ifthe bug is no longer exists then tester assigns the status "Closed."
Duplicate : If the defect is repeated twice or the defect corresponds the same concept of the bug the status is
changed to "duplícate."
Rejected : Ifthe developer feels the defect is not a genulne defect then it changes the defect to "rejected."

Deferred: Ifthe present bug is not ofa prime priority and if it is expected to get fixed in the next release, then
status
"Deferred" is assigned to such bugs.
N o t a bug : ifit does not afect the functionality of the application then the status assigned to a bug is "Not a bug.
a.17 Explain the debugging process. SPPU: May 13,8Marks, Dec.13, 6 Marks
Ans.: Debug9ging

Debugging is not a testing process but it is the consequence of testing. The debugging process starts with
conduction of a test case.
The results are evaluated anda diference between expected and actual performance is encountered.
The debugging process has one of two outcomes as follows
(1) The reason for causing error are found and çorrected, or
(2) The reason for causing the error will not be found.
In the case 2, the person performing debugging will be suspicious about a cause. Conducting the test cases will
help to validate that suspicion, and the person can work to correct the errors in iterative fashion.
It is observed that the debugging is a difficult process. Sometimes human psychology is required in addition to
software technology. Following are some characteristics of bugs that will provide some clues to clear the doubts
about debugging process :

o The cause or the symptom can be geographically remote,

o The symptom may be unavailable temporarlly, while some other errors are corrected.
o The symptom may also be,caused by non-errors (e-g, round-off inaccuracies).
o The symptom may be caused by some human error and that can not be easily traced.
o The symptom may be due to timing problems rather than processing problems.
o It is very difficult to reproduce input conditlons accurately. For example real-time applications where order
of the input values is indeterminate.

Ces Casy-solutons
Software Engineering(SPPUIT) 69 Quick Read
o The symptom can also be intermittent ie. not continuous. This scenario is very common in embedded

systems.
O The symptom can also be caused by number of tasks running on different processors in a distributed system

Scenario.
In the debugging process, numerous error are encountered that may be mild annoying or catastrophic.

The examples of mild annoying errors are:

oIncorrect output format
The éxamples ofcatastrophicerrors are:
O System fails

o Physical damage
Economical losses
finding the, that errors itself. The
in debugging process, finding the cause of the errors is more important
more errors are introduces.
software developer sometimes eliminates an error and at the same time, two

Paychological Considerations
are not
are good in debugging and some
Debugging is considered to be the natural process and some people
It is evident from the various reports
good in debugging. Thus there is large variance in the debugging process.
that the developers with the same education and same experiences have different debugging capabilities.

Based on human abilities of debugging. Shneiderman gave following statements:

o Debugging is the most frustrating phase of development. It consists of problem solving and brain teasers,

along with some annoying recognition that you made a mistake.

to admit the of errors, usually increases the dificulty of the task
o The anxiety and unwillingness possibility
But finally all the bugs are corrected.
o It is quite difficult to "learn" debugging process as there are number of approaches exists for problem

solving
Debugging Approaches
Regardless of the approach that is chosen, debugging has one simple objective i.e. to detect and correct the cause

oferror. The objective can be achieved by different evaluation techniques.

Bradley has described the
debugging approach in the following way:
o Debugglng is an application of scientific method.

by partitioning it.
oIn debugging, the basic idea is to locate the problem's
source

Consider the following non-software example

Suppose a lamp in a house is not working, it means that lamp is faulty. If everything in the house is not working
it means there is problem in the main circult breaker. If I see in my neighbourhood, everything is blackout, then I
can find there is problem in the main connection in my area and so on.
. I n this scenario I have to startcorrecting the problems from top and reach to the speciñc location.
.This hypothesis may be useful in conducting the test.

es 0asy-solutions
Software Engineering(SPPUIT) 70
Quick Read
Following are three important categories for debugging approaches
(1) Brute force
(2) Backtracking
3) Cause elimination
(1) Brute force

oThe Brute force is the most common and least efficient method for finding
the cause of a software errór.
o This category of
debugging i.e. Brute force
debugging methods is applicable generally when all the other
methods failed. In this method, computer find the errors
are
itself since memory dumps are used and thus
run-timé traces are invoked. In this, the
program is loaded with the WRITE statements.
oIn the complicated and
confused pool of
cause of errors.
the information,
is able to developer reach to the clue to find the
T h e mass information
produced will lead to suçcess finally. Sometimes it may lead to wasted
effort. Therefore first, the
thought should be expended. of time and
(2) Backtracking

Backtracking category of debugging is more common and is used

programs. In this approach, the hint or the
approach successfully in especially small
point where errors are seen
is selected as a starting point and thee
ource code is traced
backward. The backtracking is a manual process and continues till the cause of the
error is found.

o In this category, the task is increased as compared to previous approaches. The number of source code
areincreased and sometimes the lines
large number of backward paths are
unmanageable.
(3) Cause elimination
o The third category of
debugging use the concept of binary partitioning. The
achieved by induction or deduction.
cause elimination approach is

o Data that causes errors or somehow that data is related to the

error
occurrence, are organized properly to
find the actual cause of
potential errors. In this category of debugging, a "cause
any previously mentioned data is taken to prove or disprove the hypothesis" is used. In this,
hypothesis. this, the list of causes is
In
prepared and finally the tests are conducted to eliminate these errors.
o Iftests prove the cause
hypothesis then the data is refined to find the
errors.
o These debugging approaches are supported by various
debugging tools available to make it more effective.
oVarious debugging compilers are applied and various dynamic debugging aids called as tracers are used.
o Also the automatic test case
generators, cross-reference maps and memory dumps are also
used to make
his category of debugging more effective. But one should be remembered that these
tools can not be the
substitute of debugging process, they are only the supporting tools.
As soon as the errors are found, they are eliminated, but during the correction of
these errors, some new
errors can be introduced. So instead of some good thing, more damage can be caused in this
process.
Van Vleck stated following three simple questions that must be answered before
correction starts:

Ces easy-SOlutions
Software Engineering (SPPU_IT) 71 Qulck Read
1. Check whether the cause of error is reproduced in some another part of the program?

A) In most of the cases, the program errors caused by erring logic and this erroneous logic may
are
should be taken for
also be reproduced in another part of the program. The explicit consideratdon
all the logical pattern. This consideration may discover the errors.

2. What will be the next error, if I fix one ?

the source code to find the use of any
B) So before any correction is made, the tester should assess

that interrelated
is taken in correction so
1ogic in another part of the same program. A utmost care
logic or coupling should not cause any new errors.
prevent the error at the first place only?
3. What precaution should be taken to

approach, this question can be answered. If the

C By using proper SQA (Software Quality Assurance) errors may be eliminated
process and the product, both are
corrected simultaneously then all the
from the current programs as well as future programs.

Cescasy-s0lutionsS