SOFTWARE QUALITY ASSURANCE AND TESTING

UNIT - III

REGRESSION TESTING

❖ REGRESSION TESTING

● As per IEEE "Regression testing is selective retesting of a system or component to

verify that modifications have not caused unintended effects and that the system or
component still complies with its specified requirements.”

● Regression testing is performed when changes are made to existing software; the
purpose of regression testing is to provide confidence that the newly introduced changes
do not obstruct the behaviours of the existing, unchanged part of the software.
● It is a complex procedure that is all the more challenging because of some of the recent
trends in software development.
● Regression testing is the process of re-testing the modified parts of the software and
ensuring that no new errors have been introduced into previously tested source code
due to these modifications.

● Therefore, regression testing tests both the modified source code and other parts of
the source code that may be affected by the change. It has some purposes like: -

1) Increases confidence in the correctness of the modified program.

2) Locates errors in the modified program.

3) Preserves the quality and reliability of the software.

4) Ensures the software’s continued operation.

Difference between Re-Testing and Regression Testing:

Retesting means testing the functionality or bug again to ensure the code is fixed. If it
is not fixed, Defect needs to be re-opened. If fixed, Defect is closed.
Regression testing means testing your software application when it undergoes a code
change to ensure that the new code has not affected other parts of the software.
Regression testing process
● The team like to debug the source code to know the reasons for this failure. After
identification of the reasons, the source code is modified and we generally do not expect
the same failure again.
● The team will re-test the source code with a focus on modified portions of the source
code and also on affected portions of the source code due to modifications.

Steps for Regression Testing Process

1) Identifying and Analysing Changes in the Source Code

The first step is to identify the changes made to the source code; then determine the
modules that are affected by the change; and furthermore, check their behaviour on the
existing features of the app or software.
2) Prioritizing Changes
The next step is to prioritize the identified modifications and app or software
requirements, to structure the testing process with the relevant test cases and testing
tools.

3) Defining the Entry Point and Conditions

Thereafter the entry point is to be decided based on the pre-set conditions that confirm
that the app or software is ready for Regression Test execution.

4) Defining the Exit Point

The exit point is also to be defined; the eligibility criteria decided in the previous step.

5) Scheduling Tests
Once all the test components are identified, the opportune time for execution can be
scheduled.

❖ REGRESSION TEST CASES SELECTION

● Effective Regression Tests can be done by selecting the following test cases –
• Test cases which have frequent (regular) defects.
• Functionalities which are more visible to the users.
• Test cases which verify core features of the product.
• Test cases of Functionalities which has recent changes.
• All Integration Test Cases.
• All Complex Test Cases.
• Boundary value test cases.
 • A sample of Successful & Failure test cases.
● Test suite design is an expensive process and its size can grow quite large. Most of the
times, running an entire test suite is not possible as it requires a significant amount of
time to run all test cases. Many techniques are available for the selection of test cases
for the purpose of regression testing.

Regression Testing Techniques

1) Select All Test Cases

● This is the simplest technique where software testers do not want to take any risk.
● Software testers want to run all test cases for any change in the program. This is the
safest technique, without any risk.
● A program may fail many times and every time we will execute the entire test suite.
● This technique is practical only when the size of the test suite is small. For any large
sized test suite, it becomes impractical to execute all test cases.

2) Select Test Cases Randomly

● Testers may select test cases randomly to reduce the size of the test suite.
● Testers decide how many test cases are required to be selected depending upon time
and available resources.
● If the number is large, testers get a good number of test cases for execution and testing
may be of some use. But, if the number is small, testing may not be useful at all.
● In this technique, testers assumption is that all test cases are equally good in their
fault detection ability.

3) Select Modification Traversing (travel across) Test Cases

● Testers select only those test cases that execute the modified portion of the program
and the portion which is affected by the modifications.
● Testers want to select all those test cases that reveal faults in the modified program.
These test cases are known as fault revealing test cases.
● Another objective is that may be to select those test cases that reveal the difference in
the output of the original program and the modified program. These test cases are
known as modification revealing test cases.
Reducing The Number of Test Cases
1) Minimization of Test Cases
● If testers find the selected number of test cases very large, testers may still reduce this
using any test case minimization technique. These test case minimization techniques
attempt to find redundant test cases.
● A redundant test case is one which achieves an objective which has already been
achieved by another test case. The objective may be source code coverage, requirement
coverage, variables coverage, branch coverage, specific lines of source code coverage,
etc.
● A minimization technique may further reduce the size of the selected test cases based
on some criteria. Testers should always remember that any type of minimization is risky
and may omit some fault revealing test cases.

2) Prioritization of Test Cases

● Testers indicate the order in which a test case may be addressed. This process is
known as prioritization of test cases.
● All prioritization guidelines should be designed on the basis of risk analysis. All risky
functions should be tested on higher priority. The risk analysis may be based on
complexity, criticality, impact of failure of the code.
● A test case with the highest rank has the highest priority and the test case with the
second highest rank has the second highest priority and as so on. The efficiency of the
regression testing is dependent upon the criteria of prioritization.

❖ WHAT IS RISK?
● Risk is an expectation of loss, a potential problem that may or may not occur in the
future. It is generally caused due to lack of information, control or time.
● Loss can be anything, increase in production cost, development of poor-quality
software, not being able to complete the project on time.
● Risk is defined as the “probability of occurrence of an undesirable event and the
impact of occurrence of that event.”

Risk Analysis
● Unexpected behaviours of a software programme always carry huge information and
most of the time they disturb every associate person. No one likes such unexpected
behaviour from the software. In practice, the situation is entirely different and
developers need to face such unexpected situations frequently and work hard to find
the solutions of the problems highlighted by these unexpected behaviours.
● Risk analysis is a process of identifying the potential problems and then assigning a
‘Probability of occurrence of the problem’ value and ‘impact of that problem’ value for
each identified problem.
● A factor ‘risk exposure’ is calculated for every problem which is the product of
‘probability of occurrence of the problem’ value and ‘impact of that problem’ value.

Risk analysis table of ‘University Registration System’

Risk Matrix
● Risk matrix is used to capture identified problems, estimate their probability of
occurrence with impact and rank the risks based on this information.
● We may use the risk matrix to assign thresholds (Meaning-the level at which
something starts to happen) that group the potential problems into priority categories.
● The risk matrix is shown in Figure with four quadrants. Each quadrant represents a
priority category.
Threshold by quadrant: -
 The priority category in defined as:
Priority category 1 (PC-1) = High probability value and high impact value
Priority category 2 (PC-2) = High probability value and low impact value
Priority category 3 (PC-3) = Low probability value and high impact value
Priority category 4 (PC-4) = Low probability value and low impact value
● In this case, a risk with high probability value is given more importance than a
problem with high impact value.
● We may change this and may decide to give more importance to high impact value
over the high probability value.

❖ CODE COVERAGE PRIORITIZATION TECHNIQUE

● Code coverage is a measurement in which describes the intensity of which the source
code of the program has been tested. It is one form of white box testing means testers
test internal structure of the code.
● Code coverage system gathers information about the running program and it also
combines that with source code information to generate a report about the test suite’s
code coverage.

Why use Code Coverage?

● It helps to ascertain that the software has lesser bugs when compared to the software
that does not have a good Code Coverage.
● By aiding in improving the code quality, it indirectly helps in delivering a better
‘quality’ software. It is a measure that can be used to know the test effectiveness.

Code Coverage Methods

1) Statement Coverage
2) Decision Coverage
3) Branch Coverage

1) Statement Coverage
● The main purpose of Statement Coverage is to cover all the possible paths, lines and
statements in source code.
● It is a white box testing technique in which all the executable statements in the source
code are executed at least once.
● It is used for calculation of the number of statements in source code which have been
executed.
2) Decision Coverage
● Decision Coverage is a white box testing technique which reports the true or false
outcomes of each Boolean expression of the source code.
● The goal of decision coverage testing is to cover and validate all the accessible source
code by checking and ensuring every possible decision point is executed at least once.

3) Branch Coverage
● Branch Coverage is a white box testing method in which every outcome from a code
module (statement or loop) is tested.
● The purpose of branch coverage is to ensure that each decision condition from every
branch is executed at least once. It helps to measure independent code segments and
to find out sections having no branches.

❖ INTRODUCTION OF OBJECT-ORIENTED TESTING:

● Object–Oriented Analysis (OOA) is the procedure of identifying software engineering

requirements and developing software specifications in terms of a software system’s
object model.
● Object-oriented analysis and design (OOAD) are a software engineering approach that
models a system as a group of interacting objects. Each object represents some entity
of interest, and is characterised by its class, its state (data elements), and its behaviour.

Classes and Objects

Jacobson has defined an object as:
“An instance is an object created from a class. The class describes the (behaviour and
information) structure of the instance, while the current state of the instance is defined
by the operations performed on the instance.”

Jacobson has defined a class as:

“A class represents a template for several objects and describes how these objects are
structured internally. Objects of the same class have the same definition both for their
operations and for their information structures.”

Inheritance
OOD allows similar classes to stack up in a hierarchical manner where the lower or
sub-classes can import, implement, and re-use allowed variables and functions from
their immediate super classes. This property of OOD is called an inheritance. This
makes it easier to define a specific class and to create generalized classes from specific
ones.

Polymorphism

● Polymorphism means many forms. OOD languages provide a mechanism where

methods performing similar tasks but vary in arguments, can be assigned the same
name. This is known as polymorphism.
● The same message is sent to different objects irrespective of their class, but the
responses of objects may be different. When we abstract the interface of an operation
and leave the implementation details to sub-classes, this activity is called
polymorphism. This operation is called polymorphic operation.

Encapsulation
●Encapsulation is also known as information hiding concept. It is a way in which both
data and functions (or operations) that operate on data are combined into a single unit.
● The only way to access the data is through functions, which operate on the data. The
data is hidden from the external world. Hence, it is safe from outside (external) and
accidental modifications.

Messages, Methods, Responsibility, Abstraction

● A message is a request for performing an operation by some object in the system. A
message may consist of the identification of the target object, name of the requested
operation and other relevant information for processing the request.
● An object which originates a message is called the sender and the object which receives
a message is called the receiver.
● A ‘method’ is the sequence of steps (or set of operations) to be performed to fulfil the
assigned task. It is the responsibility of the receiver of the message to choose an
appropriate method to complete a task effectively and efficiently.
● Responsibility is an important concept of an object-oriented system. Behaviour of an
object is described in terms of responsibilities. This improves the independence amongst
the objects which is very important for solving any complex problem.
● The complexity of a problem is managed using the right level of abstraction which is
the elimination of the irrelevant and the amplification of the essentials. abstraction
concept provides independence and improves the clarity of the system.
❖ OBJECT-ORIENTED TESTING & TESTING LEVELS
●The whole object-oriented testing revolves around the fundamental entity known as
“class”. With the help of “class” concept, larger systems can be divided into small well-
defined units which may then be implemented separately.
● The object-oriented testing can be classified as like conventional systems. These are
called as the levels for testing.

What is a Unit?
● A unit is a smallest software component that can be complied and executed. A unit is
a software component that would never be assigned to more than one designer to
develop.
● In unit testing, the individual classes are tested. It is seen whether the class attributes
are implemented as per design and whether the methods and the interfaces are error-
free.
● The purpose of unit testing is to ensure that each unit meets its specification. If each
unit meets its specification, then any bugs that appear when units are integrated
together are more likely caused by incorrect interfacing of units than by incorrect
implementations of the units.

Levels of Testing
The various testing levels are:
1) Method testing
2) Class testing
3) Inter-class testing
4) System testing
5) Functionality testing

1) Method testing
● In this level the individual methods are tested to ensure that they are working as they
are intended to by the specification.
● The intended testing is just for one method, it may be that other methods and variables
may have to be included in the testing, to facilitate the testing of current method.
● This might be the case for instance if you are testing a method that calls one or more
other methods within the same class.
● This brings up the need for stub, which are replacements for the real
methods/variables which are often static in nature and simply return values that are
known to be true by the tester.

2) Class testing
● Class is tested as a whole, with each of the methods being tested to ensure when a
class is quickly that the methods work correctly with the given inputs.
● For each class, we must decide whether to test it independently as a unit or in some
way as a component of a larger part of the system.
We base that decision on the following factors:
● The role of the class in the system, especially the degree of risk associated with it.
● The complexity of the class measured in terms of the number of states, operations,
and associations with other classes.
● The amount of effort associated with developing a test driver for the class.

● Class testing should be performed prior to the use of the class in other portions of
the software.

Issues Related to Class Testing

• Testing all operations associated with an object.
• Setting and interrogating all object attributes.
• Exercising the object in all possible states.

Preparation steps for class testing: -

1) List specified states for the object that is to be tested.
2) List the messages and operations that will be exercised as a consequence of the test.
3) List the exceptions that may occur as the object is tested.
4) List external conditions.

3) Inter-class testing
● The focus of the testing at this level is in finding errors in classes. Faults which are
caused during communication between different classes are identified. It also ensures
that there is a minimum chance of these faults in system testing.
● One of the main aims is to find errors that can only be found when dealing with the
application as a whole.
 ● Another aim of this testing is to ensure that the application that has finally been
developed have all the functionality required as per the specification from the view point
of an end user.

4) System testing
● System testing is independent of system implementation. A system tester does really
need to know if the implementation is in procedural or object-oriented code.
● System testing involves testing the system as a whole and is the responsibility of the
quality-assurance team.
● The team often uses system tests as regression tests when assembling new releases.
● This involves testing a particular module or a subsystem and is the responsibility of
the subsystem lead. It involves testing the associations within the subsystem as well as
the interaction of the subsystem with the outside.

5) Functionality testing - Tests all functionalities of the software against the

requirement.

1) Acceptance testing: - As per mentioned in Unit- I.

2) Alpha testing - As per mentioned in Unit- I.
3) Beta testing - As per mentioned in Unit- I.

NOTE: - You should study and write 1,2,3 points description in the examination.

❖ PATH TESTING
● Path testing is a structural testing method that involves using the source code of a
program to attempt to find every possible executable path.
● The idea is to test each individual path in as many ways as possible in order to
maximise the coverage of each test case. This gives the best possible chance of
discovering all faults within a piece of code.
● The fact that path testing is based upon the source code of a program means that it
is a white box testing method.

Activity Diagram
● The first step of path testing is to convert source code into its activity diagram. In
Unified Modelling Language (UML), activity diagram is used to represent sequences in
which all activities are performed. This is similar to a flow graph of path testing.
● Activity diagram may be generated from a use case or from a class. It may represent
basic flow and also possible alternative flows.
● An activity diagram represents the flow of activities through the class. It provides the
basis for the path testing where we may like to execute each independent path of the
activity diagram at least once.

Path Testing Techniques:

1) Control Flow Graph (CFG) - The Program is converted into Flow graphs by
representing the code into nodes, regions and edges.
2) Decision to Decision path (D-D) - The CFG can be broken into various Decision to
Decision paths and then collapsed into individual nodes.
3) Independent (basis) paths - Independent path is a path through a DD-path graph
which cannot be reproduced from other paths by other methods.

Symbols of an Activity Diagram

To represent multiple parallel activities i.e.

1) fork -
an activity is split into two or more
activities.

2) Join - To represent the combination of two or more

parallel activities after completion of
respective activities.

To represent the transfer of flow of control

3) Transition - from one activity to another.

To represent a set of operations known as

4) Activity -
an activity.

5) Start - To represent start state of activity diagram.

6) End - To represent end state of activity diagram.

 7) Branch - To represent the transfer of flow on the
basis of evaluation of Boolean expression
known as guard condition.

❖ STATE BASED TESTING

● State based testing uses the concept of state machine of electronic circuits where the
output of the state machine is dependent not only on the present state but also on the
past state.
● In state machine, the output is not only dependent on the present inputs but also on
the previous inputs. In electronic circuits, such circuits are called sequential circuits.
● If the output of a state is only dependent on present inputs, such circuits are called
combinational circuits. In state-based testing, the resulting state is compared with the
expected state.

What is a State Machine?

● State machines are used to model the behaviour of objects.
● A state machine represents various states which an object is expected to visit during
its lifetime in response to events or methods along with its responses to these events or
methods.
● A state is represented by rectangles with rounded corners and transitions are
represented by edges (arrows). Events and actions are represented by annotations on
the directed edges. A typical state machine is shown in Figure.
typical state machine diagram

State 1

Event [guard]/action
B [ x<y]/previous
A[x>y]/next

State 2
Terminologies used in state chart diagram
Terminologies used in
Sr. No. Description Remarks
state chart diagram
Abstract situation in the life State1, state2
1 State cycle of an entity that occurs in
response to occurrence of some
event.

2 Event An input (a message or method A, B

call).
3 Action An output or the result of an Next, previous
activity.
4 Transition Change of state after When x>y and A is
occurrence of an event. the input, state is
changed from state1
to state2.
5 Guard condition Predicate expression with an Two predicate
event, stating a Boolean expressions
restriction for a transition to x>y and x<y
fire.

● In Unified Modelling Language (UML), a state machine is graphically represented by a

state chart diagram. It shows the flow of control from one state to another state.
● Here too, states are represented by rectangles with rounded corners and transitions
are represented by edges (arrows).
● Two special states are used i.e. (alpha) and (omega) state for representing the
constructor and destructor of a class.
● These states may simplify testing of multiple constructors, exception handling and
destructors. These are additional states to make things more explicit and meaningful.

There are four events new, push, pop and destroy, with the following purposes:

1) New: Creates an empty stack.

2) Push: Push an element in the stack, if space is available.
3) Pop: Pop out an element from the stack, if it is available.
4) Destroy: Destroy the stack after the completion of its requirement i.e., instance of
the stack class is destroyed.
EXAMPLE OF ATM MACHINE
Consider the example of withdrawing cash from an ATM machine. The process consists
of the following steps:
1) The customer will be asked to insert the ATM card and enter the PIN number.
2) If the PIN number is valid, the withdrawal transaction will be performed:
(a) The customer selects amount.
(b) The system verifies that it has sufficient money to satisfy the request; then the
appropriate amount of cash is dispensed by the machine and a receipt is issued.
(c) If sufficient amount is not available in the account, a message “Balance not
sufficient” is issued.
3) If the bank reports that the customer’s PIN is invalid, then the customer will have to
re-enter the PIN.