STQA NOTES SYMCA

UNIT 4
DYNAMIC ANALYSIS
Black Box Testing-

Equivalence Partitioning

 Equivalence partitioning or equivalence class partitioning is a software testing technique

that divides the input data of a software unit into partitions of equivalent data from which
test cases can be derived. In principle, test cases are designed to cover each partition at least
once. This technique tries to define test cases that uncover classes of errors, thereby
reducing the total number of test cases that must be developed. An advantage of this
approach is reduction in the time required for testing a software due to lesser number of
test cases.
 Equivalence partitioning is typically applied to the inputs of a tested component, but may be
applied to the outputs in rare cases. The equivalence partitions are usually derived from the
requirements specification for input attributes that influence the processing of the test
object.
 The fundamental concept of ECP comes from equivalence class which in turn comes
from equivalence relation. The demonstration can be done using a function written in C:

int safe_add( int a, int b )

{
int c = a + b;
if ( a >= 0 && b >= 0 && c < 0 )
{
fprintf ( stderr, "Overflow!\n" );
}
if ( a < 0 && b < 0 && c >= 0 )
{
fprintf ( stderr, "Underflow!\n" );
}
return c;
}

On the basis of the code, the input vectors of [a,b] are partitioned. The blocks we need to
cover are the overflow statement and the underflow statement and neither of these 2. That
gives rise to 3 equivalent classes, from the code review itself.

Page 30 of 88
STQA NOTES SYMCA

Demonstrating Equivalence Class Partitioning

To solve the input problem, we take refuge in the inequation

we note that there is a fixed size of Integer (computer science) hence, the z can be
replaced with:-
INT_MIN ≤ x + y ≤ INT_MAX
and
with x ∈ { INT_MIN , ... , INT_MAX } and y ∈ { INT_MIN , ... , INT_MAX }
The values of the test vector at the strict condition of the equality that is INT_MIN
= x + y and INT_MAX = x + y are called the boundary values, Boundary-value
analysis has detailed information about it. Note that the graph only covers the
overflow case, first quadrant for X and Y positive values.
In general an input has certain ranges which are valid and other ranges which are
invalid. Invalid data here does not mean that the data is incorrect, it means that this
data lies outside of specific partition. This may be best explained by the example of a
function which takes a parameter "month". The valid range for the month is 1 to 12,
representing January to December. This valid range is called a partition. In this
example there are two further partitions of invalid ranges. The first invalid partition
would be ≤ 0 and the second invalid partition would be ≥ 13.

... -2 -1 0 1 .............. 12 13 14 15 .....

--------------|-------------------|---------------------
invalid partition 1 valid partition invalid partition 2

The testing theory related to equivalence partitioning says that only one test case of
each partition is needed to evaluate the behaviour of the program for the related
partition. In other words it is sufficient to select one test case out of each partition to
check the behaviour of the program. To use more or even all test cases of a partition
will not find new faults in the program. The values within one partition are
considered to be "equivalent". Thus the number of test cases can be reduced
considerably.
Equivalence partitioning is not a stand alone method to determine test cases. It has to
be supplemented by boundary value analysis. Having determined the partitions of
possible inputs the method of boundary value analysis has to be applied to select the
most effective test cases out of these partitions.

Page 31 of 88
STQA NOTES SYMCA

BOUNDARY VALUE ANALYSIS-

Boundary value analysis:

It’s widely recognized that input values at the extreme ends of input domain cause more errors in
the system. More application errors occur at the boundaries of input domain. ‘Boundary value
analysis’ testing technique is used to identify errors at boundaries rather than finding those exist in
center of input domain.
Boundary value analysis is the next part of Equivalence partitioning for designing test cases where
test cases are selected at the edges of the equivalence classes.
Boundary value analysis is a software testing technique in which tests are designed to include
representatives of boundary values in a range. The idea comes from the boundary. Given that we
have a set of test vectors to test the system, a topology can be defined on that set. Those inputs
which belong to the same equivalence class as defined by the equivalence partitioning theory would
constitute the basis. Given that the basis sets are neighbors, there would exist a boundary between
them. The test vectors on either side of the boundary are called boundary values. In practice this
would require that the test vectors can be ordered, and that the individual parameters follows some
kind of order (either partial order or total order).
The expected input and output values to the software component should be extracted from the
component specification. The values are then grouped into sets with identifiable boundaries.
Each set, or partition, contains values that are expected to be processed by the component in
the same way. Partitioning of test data ranges is explained in the equivalence partitioning test
case design technique. It is important to consider both valid and invalid partitions when
designing test cases.
The demonstration can be done using a function written in C.

int safe_add( int a, int b )

{
int c = a + b ;
if ( a >= 0 && b >= 0 && c < 0 )
{
fprintf ( stderr, "Overflow!\n");
}
if ( a < 0 && b < 0 && c >= 0 )
{
fprintf ( stderr, "Underflow!\n");
}
return c;
}

On the basis of the code, the input vectors of [a,b] are partitioned. The blocks we need to
cover are the overflow statement and the underflow statement and neither of these 2. That
gives rise to 3 equivalent classes, from the code review itself.

Page 32 of 88
STQA NOTES SYMCA

Demonstrating Boundary Values (Orange)

we note that there is a fixed size of integer hence:-

INT_MIN ≤ x + y ≤ INT_MAX
We note that the input parameter a and b both are integers, hence total order exists on
them. When we compute the equalities:-
x + y = INT_MAX
INT_MIN = x + y
we get back the values which are on the boundary, inclusive, that is these pairs
of (a,b) are valid combinations, and no underflow or overflow would happen for
them.
On the other hand:-
x + y = INT_MAX + 1
gives pairs of (a,b) which are invalid combinations, Overflow would occur
for them. In the same way:-
x + y = INT_MIN - 1
gives pairs of (a,b) which are invalid combinations, Underflow would
occur for them.
Boundary values (drawn only for the overflow case) are being shown as
the orange line in the right hand side figure.

For another example, if the input values were months of the year,
expressed as integers, the input parameter 'month' might have the
following partitions:

... -2 -1 0 1 .............. 12 13 14 15 .....

--------------|-------------------|-------------------
invalid partition 1 valid partition invalid partition 2

Page 33 of 88
STQA NOTES SYMCA

STATE TRANSITION TESTING-

State Transition testing, a black box testing technique, in which outputs are triggered by changes to
the input conditions or changes to 'state' of the system. In other words, tests are designed to
execute valid and invalid state transitions.

 State transition testing is used where some aspect of the system can be described in what
is called a ‘finite state machine’. This simply means that the system can be in a (finite)
number of different states, and the transitions from one state to another are determined by
the rules of the ‘machine’. This is the model on which the system and the tests are based.
 Any system where you get a different output for the same input, depending on what has
happened before, is a finite state system.
 One of the advantages of the state transition technique is that the model can be as detailed
or as abstract as you need it to be. Where a part of the system is more important (that is,
requires more testing) a greater depth of detail can be modeled. Where the system is less
important (requires less testing), the model can use a single state to signify what would
otherwise be a series of different states.
 A state transition model has four basic parts:

 The states that the software may occupy (open/closed or

funded/insufficient funds);
 The transitions from one state to another (not all transitions are allowed);
 The events that cause a transition (closing a file or withdrawing money);
 The actions that result from a transition (an error message or being given your
cash).
When to use?
 When we have sequence of events that occur and associated conditions that apply to those
events
 When the proper handling of a particular event depends on the events and conditions that have
occurred in the past
 It is used for real time systems with various states and transitions involved
Deriving Test cases:
 Understand the various state and transition and mark each valid and invalid state
 Defining a sequence of an event that leads to an allowed test ending state
 Each one of those visited state and traversed transition should be noted down
 Steps 2 and 3 should be repeated until all states have been visited and all transitions traversed
 For test cases to have a good coverage, actual input values and the actual output values have to
be generated
Advantages:
 Allows testers to familiarise with the software design and enables them to design tests
effectively.
 It also enables testers to cover the unplanned or invalid states.

Page 34 of 88
STQA NOTES SYMCA

Example:
A System's transition is represented as shown in the below diagram:

The tests are derived from the above state and transition and below are the possible scenarios that
need to be tested.
Tests Test 1 Test 2 Test 3

Start State Off On On

Input Switch ON Switch Off Switch off

Output Light ON Light Off Fault

Finish State ON OFF On

CAUSE EFFECT GRAPHING-

 Cause-Effect Graph graphically shows the connection between a given outcome and all issues
that manipulate the outcome. Cause Effect Graph is a black box testing technique. It is also
known as Ishikawa diagram because of the way it looks, invented by Kaoru Ishikawa or fish bone
diagram.
 It is generally uses for hardware testing but now adapted to software testing, usually tests
external behavior of a system. It is a testing technique that aids in choosing test cases that
logically relate Causes (inputs) to Effects (outputs) to produce test cases.
 A “Cause” stands for a separate input condition that fetches about an internal change in the
system. An “Effect” represents an output condition, a system transformation or a state resulting
from a combination of causes.

Page 35 of 88
STQA NOTES SYMCA

The Cause-Effect Diagram can be used under these Circumstances:

 To determine the current problem so that right decision can be taken very fast.
 To narrate the connections of the system with the factors affecting a particular process or effect.
 To recognize the probable root causes, the cause for a exact effect, problem, or outcome.

Benefits of making cause-Effect Diagram

 It finds out the areas where data is collected for additional study.
 It motivates team contribution and uses the team data of the process.
 Uses synchronize and easy to read format to diagram cause-and-effect relationships.

 It enhances facts of the procedure by helping everyone to learn more about the factors at work
and how they relate.
 It Helps us to determine the root causes of a problem or quality using a structured approach.
 It Uses an orderly, easy-to-read format to diagram cause-and-effect relationships.
 It Indicates possible causes of variation in a process.
 It Identifies areas, where data should be collected for further study.
 It Encourages team participation and utilizes the team knowledge of the process.
 It Increases knowledge of the process by helping everyone to learn more about the factors at
work and how they relate.
 It assists us to decide the root reasons of a problem or quality using a structured approach.
Steps to proceed on Cause-Effect Diagram:
 Firstly: Recognize and describe the input conditions (causes) and actions (effect)
 Secondly: Build up a cause-effect graph
 Third: Convert cause-effect graph into a decision table
 Fourth: Convert decision table rules to test cases. Each column of the decision table represents a
test case

Page 36 of 88
STQA NOTES SYMCA

Symbols used in Cause-effect graphs:

Cause Effect - Flow Diagram

Circumstances - under which Cause-Effect Diagram used

 To Identify the possible root causes, the reasons for a specific effect, problem, or outcome.
 To Relate the interactions of the system among the factors affecting a particular process or
effect.
 To Analyze the existing problems so that corrective action can be taken at the earliest.

Page 37 of 88
STQA NOTES SYMCA

Benefits :
 It Helps us to determine the root causes of a problem or quality using a structured approach.
 It Uses an orderly, easy-to-read format to diagram cause-and-effect relationships.
 It Indicates possible causes of variation in a process.
 It Identifies areas, where data should be collected for further study.
 It Encourages team participation and utilizes the team knowledge of the process.
 It Increases knowledge of the process by helping everyone to learn more about the factors at
work and how they relate.

DECISION TABLE TECHNIQUE

 A decision table is a good way to deal with different combination inputs with their associated
outputs and also called cause-effect table. Reason to call cause-effect table is an associated
logical diagramming technique called ’cause-effect graphing that is basically use to derive the
decision table.
 Decision table testing is black box test design technique to determine the test scenarios for
complex business logic.
 We can apply Equivalence Partitioning and Boundary Value Analysis techniques to only specific
conditions or inputs. Although, if we have dissimilar inputs that result in different actions being
taken or secondly we have a business rule to test that there are different combination of inputs
which result in different actions. We use decision table to test these kinds of rules or logic.
 A decision table is basically an outstanding technique used in both testing and requirements
management. It is a structured exercise to prepare requirements when dealing with complex
business rules.

Advantage of decision table technique:

 Any complex business flow can be easily converted into the test scenarios & test cases using this
technique.
 Such type of table are work iteratively, means the table created at the first iteration is used as
input table for next tables. Such iteration can be carried out only if the initial table is
unsatisfactory.
 Simple to understand and everyone can use this method design the test scenarios & test cases.
 It provide complete coverage of test cases which help to reduce the rework on writing test
scenarios & test cases.
 These tables guarantee that we consider every possible combination of condition values. This is
known as its “completeness property”.

Page 38 of 88
STQA NOTES SYMCA

EXAMPLE

TABLE 1: Blank decision table

Conditions Step 1 Step 2 Step 3 Step 4

Repayment money has

been mentioned

Terms of loan has been

mentioned

TABLE 2: Decision table – Input combination

Conditions Step 1 Step 2 Step 3 Step 4

Repayment money has Y Y N N

been mentioned

Terms of loan has been Y N Y N

mentioned

TABLE 3: Decision table – Combinations and outcomes

Conditions Step 1 Step 2 Step 3 Step 4

Repayment money has Y Y N N

been mentioned

Terms of loan has been Y N Y N

mentioned

Actions/Outcomes

Page 39 of 88
STQA NOTES SYMCA

Process loan money Y Y

Process term Y Y

TABLE 4: Decision table – Additional outcomes

Conditions Step 1 Step 2 Step 3 Step 4

Repayment money has Y Y N N

been mentioned

Terms of loan has been Y N Y N

mentioned

Actions/Outcomes

Process loan money Y Y

Process term Y Y

Error message Y

TABLE 5: Decision table – Changed outcomes

Conditions Step 1 Step 2 Step 3 Step 4

Repayment money has Y Y N N

been mentioned

Terms of loan has been Y N Y N

mentioned

Page 40 of 88
STQA NOTES SYMCA

Actions/Outcomes

Process loan money Y

Process term Y

Error message Y Y

USER DOCUMENTATION TESTING

Documentation Testing involves testing of the documented artifacts that are usually developed
before or during the testing of Software.
Documentation for Software testing helps in estimating the testing effort required, test coverage,
requirement tracking/tracing, etc. This section includes the description of some commonly used
documented artifacts related to Software development and testing, such as:
 Test Plan
 Requirements
 Test Cases
 Traceability Matrix

 It is a type of non-functional testing

 Any written or pictorial information describing, defining, specifying, reporting, or certifying

activities, requirements, procedures, or results’. Documentation is as important to a
product’s success as the product itself. If the documentation is poor, non-existent, or wrong,
it reflects on the quality of the product and the vendor.

 As per the IEEE Documentation describing plans for, or results of, the testing of a system or
component, Types include test case specification, test incident report, test log, test plan, test
procedure, test report. Hence the testing of all the above mentioned documents is known
as documentation testing.
 This is one of the most cost effective approaches to testing. If the documentation is not
right: there will be major and costly problems. The documentation can be tested in a
number of different ways to many different degrees of co mplexity. These range from
running the documents through a spelling and grammar checking device, to manually
reviewing the documentation to remove any ambiguity or inconsistency.

 Documentation testing can start at the very beginning of the software process and hence
save large amounts of money, since the earlier a defect is found the less it will cost to be
fixed.

Page 41 of 88
STQA NOTES SYMCA

DOMAIN TESTING

Domain testing is a software testing technique in which selecting a small number of test cases from a
nearly infinite group of test cases. For testing few applications, Domain specific knowledge plays a
very crucial role.
Domain testing is a type of functional testing and tests the application by feeding interesting inputs
and evaluating its outputs.
Domain - Equivalence Class Testing
Equivalence class carries its own significance when performing domain testing. Different ways of
equivalence class are:
 Intuitive equivalence
 Specified equivalence
 Subjective equivalence
 Risk-based equivalence
STATEMENT COVERAGE
 The statement coverage is also known as line coverage or segment coverage.
 The statement coverage covers only the true conditions.
 Through statement coverage we can identify the statements executed and where the code is
not executed because of blockage.

 In this process each and every line of code needs to be checked and executed

 In Statement Coverage testing the code is executed in such a manner that every statement
of the application is executed at least once. It helps in assuring that all the statements
execute without any side effect.This method is also called as line coverage or segment
coverage. It is one of the testing coming under white box testing.

 In statement coverage testing we make sure that all of our code blocks are executed. We
can also identify which blocks are failed to execute in this method.
 Still bugs may be there after executing all the blocks without any failure. Because it wont
check with all the conditions in a single block. Its only a basic testing after the complete
coding and dynamic analysis. For checking with every conditions we need to to branch and
path coverage testing.

Page 42 of 88
STQA NOTES SYMCA

Advantage of statement coverage:

 It verifies what the written code is expected to do and not to do

 It measures the quality of code written
 It checks the flow of different paths in the program and it also ensure that whether
those path are tested or not.

Disadvantage of statement coverage:

 It cannot test the false conditions.

 It does not report that whether the loop reaches its termination condition.
 It does not understand the logical operators.

The statement coverage can be calculated as shown below:

BRANCH COVERAGE

Branch coverage is a testing method, which aims to ensure that each one of the possible branch
from each decision point is executed at least once and thereby ensuring that all reachable code is
executed.
That is, every branch taken each way, true and false. It helps in validating all the branches in the
code making sure that no branch leads to abnormal behavior of the application.

 Branch coverage is also known as Decision coverage or all-edges coverage.

 It covers both the true and false conditions unlikely the statement coverage.
 A branch is the outcome of a decision, so branch coverage simply measures which
decision outcomes have been tested. This sounds great because it takes a more in-depth
view of the source code than simple statement coverage
 A decision is an IF statement, a loop control statement (e.g. DO-WHILE or REPEAT-
UNTIL), or a CASE statement, where there are two or more outcomes from the
statement. With an IF statement, the exit can either be TRUE or FALSE, depending on
the value of the logical condition that comes after IF.

Advantages of decision coverage:

 To validate that all the branches in the code are reached

 To ensure that no branches lead to any abnormality of the program’s operation
 It eliminate problems that occur with statement coverage testing

Disadvantages of decision coverage:

 This metric ignores branches within boolean expressions which occur due to short-
circuit operators.

The decision coverage can be calculated as given below:

Page 43 of 88
STQA NOTES SYMCA

Formula:

Branch Testing = (Number of decisions outcomes tested / Total Number of decision

Outcomes) x 100 %

Example:

Read A

Read B

IF A+B > 10 THEN

Print "A+B is Large"

ENDIF

If A > 5 THEN

Print "A Large"

ENDIF

Page 44 of 88
STQA NOTES SYMCA

The above logic can be represented by a flowchart as:

Result :

To calculate Branch Coverage, one has to find out the minimum number of paths which will
ensure that all the edges are covered. In this case there is no single path which will ensure
coverage of all the edges at once. The aim is to cover all possible true/false decisions.

(1) 1A-2C-3D-E-4G-5H

(2) 1A-2B-E-4F

Hence Branch Coverage is 2.

PATH COVERAGE

Basis path testing, a structured testing or white box testing technique used for designing test cases
intended to examine all possible paths of execution at least once. Creating and executing tests for all
possible paths results in 100% statement coverage and 100% branch coverage.
Path coverage testing is a specific kind of methodical, sequential testing in which each individual line
of code is assessed.
As a type of software testing, path coverage testing is in the category of technical test methods,
rather than being part of an overarching strategy or "philosophy" of code. It is labor-intensive and is
often reserved for specific vital sections of code.

Page 45 of 88
STQA NOTES SYMCA

Example:

Function fn_delete_element (int value, int array_size, int array[])

1 int i;

location = array_size + 1;

2 for i = 1 to array_size

3 if ( array[i] == value )

4 location = i;

end if;

end for;

5 for i = location to array_size

6 array[i] = array[i+1];

end for;

7 array_size --;

Page 46 of 88
STQA NOTES SYMCA

Steps to Calculate the independent paths

Step 1 : Draw the Flow Graph of the Function/Program under consideration as shown below:

Step 2 : Determine the independent paths.

Path 1: 1 - 2 - 5 - 7

Path 2: 1 - 2 - 5 - 6 - 7

Path 3: 1 - 2 - 3 - 2 - 5 - 6 - 7

Path 4: 1 - 2 - 3 - 4 - 2 - 5 - 6 - 7

Page 47 of 88