SOFTWARE TESTING

Boundary value analysis

Boundary value analysis is a black-box testing technique. It is closely associated
with equivalence class partitioning. In this technique, we analyze the behavior of the
application with test data residing at the boundary values of the equivalence classes.

By using the test data residing at the boundaries, there is a higher chance of finding
errors in the software application.
Boundary Value Analysis Example
Let‟s consider the same example we used in the equivalence partitioning tutorial. An
application that accepts a numeric number as input with a value between 10 to 100.

While testing such an application, we will not only test it with values from 10 to 100
but also with other sets of values like – less than 10, greater than 10, special
characters, alphanumeric, etc.

For increasing the probability of finding errors instead of picking random values from
those classes, we can pick the values at the boundaries like below-

Equivalence Classes Test Data using Boundary Value Analysis

Numbers between 10 to100 10, 100

1
SOFTWARE TESTING

Equivalence Classes Test Data using Boundary Value Analysis

Numbers less than 10 9

Numbers greater than 100 101

Advantages of Boundary Value Analysis

1. It is easier and faster to find defects using this technique. This is because the
density of defects at boundaries is more.
2. Instead of testing will all sets of test data, we only pick the one at the
boundaries. So, the overall test execution time reduces.
Disadvantages of boundary value analysis
1. The success of the testing using this technique depends on the equivalence
classes identified, which further depends on the expertise of the tester and his
knowledge of the application. Hence, incorrect identification of equivalence
classes leads to incorrect boundary value testing.
2. Applications with open boundaries or applications not having one-dimensional
boundaries are not suitable for this technique. In those cases, other black-box
techniques like “Domain Analysis” are used.

Equivalence Class Partitioning?

Equivalence class partitioning is a black-box testing technique or
specification-based testing technique in which we group the input data into logical
partitions called equivalence [Link] the data items lying in an equivalence class
are assumed to be processed in the same way by the software application to be tested
when passed as input.
So, instead of testing all the combinations of input test data, we can pick and pass any
of the test data from a particular equivalence class to the application and assume that
the application will behave in the same way for the other test data of that class. Let‟s
understand this with the help of an example.
Example
Consider an example of an application that accepts a numeric number as input with a
value between 10 to 100 and finds its square. Now, using equivalence class testing,
we can create the following equivalence classes-

2
SOFTWARE TESTING

Equivalence
Explanation
Class

Numbers 10 to
This class will include test data for a positive scenario.
100

This class will include test data that is restricted by the application.
Numbers 0 to 9
Since it is designed to work with numbers 10 to 100 only.

Greater than This class will again include test data that is restricted by the application
100 but this time to test the upper limit.

Since negative numbers can be treated in a different way so, we will

Negative
create a different class for negative numbers in order to check the
numbers
robustness of the application.

This class will be used to test the robustness of the application with non-
Alphabets
numeric characters.

Special Just like the equivalence class for alphabets, we can have a separate
characters equivalence class for special characters.

Identification of Equivalence Classes

Let‟s discuss some points or best practices regarding the identification of Equivalence
classes-
 Cover all test data types for positive and negative test scenarios. We have to
create test data classes in such a way that covers all sets of test scenarios but at
the same time, there should not be any kind of redundancy.
 If there is a possibility that the test data in a particular class can be treated
differently then it is better to split that equivalence class.

For example, in the above example, the application doesn‟t work with numbers
– less than 10. So, instead of creating 1 class for numbers less than 10, we
created two classes – numbers 0-9 and negative numbers. This is because there
is a possibility that the application may handle negative numbers differently.
Also check – Boundary Value Analysis

3
SOFTWARE TESTING

Advantages of Equivalence Classes Testing

 With the help of equivalence class testing, the number of test cases greatly
reduces maintaining the same test coverage.
 This testing technique helps in delivering a quality product within a minimal
time period.
 It is perfectly suitable for software projects with time and resource constraints.
 It improves the quality of testing as the software testers have to work with a
smaller dataset of test data, thus focusing more on quality.

Disadvantages of Equivalence Classes Testing

 The whole success of equivalence class testing relies on the identification of
equivalence classes. The identification of these classes relies on the ability of
the testers who creates these classes and the test cases based on them.
 In the case of complex applications, it is very difficult to identify all sets of
equivalence classes and requires a great deal of expertise from the tester‟s side.
 Incorrectly identified equivalence classes can lead to lesser test coverage and
the possibility of defect leakage.

Decision Table?
A decision table consists of data on various rules, test conditions, and inputs by the
tester. The inputs are inserted as „Yes‟ or „No,‟ „True‟ or „False‟, „Y‟ or „N,‟ etc. It
helps in easy and complicated software testing.
With the help of this table, you can conclude all the possible combinations of testing
the software. Moreover, it eliminates the chances of risk and provides security to the
system.
Here is an example for a better understanding of the topic-

Condition Input 1 Input 2 Input 3

Withdrawal Amount <= Balance T F F

Credit granted – T F

Actions

4
SOFTWARE TESTING

Withdrawal Granted T T F

This example indicates the test cases for a user withdrawing money from the ATM
machine.
Explanation
Every column of the above table consists of business logic and usually combinations
of different circumstances. Additionally, you can see the actions related to those
situations in the ‘Actions’ column.
As you can see, this type of software testing is a structural representation hugely
beneficial for complex business rules. Now take a look at different types of decision
tables.
1. Limited Entry: The condition entries in this category are restricted. For
instance, true or false.
2. Extended Entry: Here, the entries can have more than two values apart from
„true‟ or „false.‟
Here are some of the common notations used for decision tables.
 Y can also be used for True. You can also use T or 1.
 N means False. You can also refer to it as F or 0.
 – indicated condition doesn‟t matter. You can also mark it as N/A.
What is Decision Table Testing?
It is a software testing approach to validate a system‟s behavior for various
combinations of input. In this approach, professionals record the input combinations
and their corresponding system behavior, i.e., output, in a table, as you can see in the
above examples of decision tables. Decision tables are to as referred to as Cause-
Effect tables, as they contain the causes and their respective effects in a table. They
help in better test coverage.
Importance of Decision Table Testing
Although other testing techniques, such as boundary value testing
and equivalence class partitioning testing, cover different circumstances, a bone of
contention arises when the system shows different input [Link] is where
decision table testing proves to be helpful. Decision table testing helps to cover
various input conditions to check the system‟s behavior in and out. It also includes
testing large data sets, making it easier for bigger organizations to scan their overall
system efficiently.

5
SOFTWARE TESTING

Moreover, it is a simple test where evaluating different behaviors is quick. Here are
some more points that depict the importance of decision table testing:
 Helps testers to understand the impact of combinations of inputs while
implementing business rules.
 In complicated business rules, the structured approach helps understand the
company‟s requirements deeply.
 Serves as a beneficial approach for the developers in the development process.
 Helps the testing team to design tests more efficiently.
 Saves the time and energy of the testers to rewrite test cases and scenarios.

Top Advantages of Decision Table Testing

1. Decision table testing, a as black box testing technique, is an efficient method
for testers.
2. It is an excellent way of analyzing complex business rules.
3. Users can expect comprehensive coverage of test cases with all the possible
unique input combinations. This ensures that your system is capable of tackling
multiple circumstances.
4. Automating decision table testing using several software tools is possible. It
helps save time and energy for both developers and testers.
5. It gives you an opportunity to find any missing requirements in both easy and
complex test scenarios. Hence guarantees to cover all the probable conditions
whatsoever.

Disadvantages of Decision Table Testing

1. Although the testing is efficient and beneficial, it can be a little time-

consuming. The more time, the more will be the testing costs. So, this is one of
the major setbacks.
2. As mentioned above, decision table testing provides the output as „true‟ or
„false.‟ Therefore, it lacks to provide other important data related to the security
and overall performance of the software.
3. This testing requires skillful and expert testers to handle complex decision
tables, as there are many inputs in complex tables. Beginners may struggle to
manage the tables.

6
SOFTWARE TESTING

4. Whenever there are any changes in the software, it is mandatory to incorporate

the same in the decision tables. Therefore, you must maintain and update them
frequently, which will result in more costs and efforts by the team.
5. Such tables do not provide information about user experience or the overall
quality of the software system.
Examples of Decision Table Testing
For a better understanding, find more examples of decision table testing below:
1. Login System
In the login system, the decision table can consist of inputs like username and
password. You can insert the conditions, such as an invalid password or an invalid
username. If the information doesn‟t match the user‟s actual credentials, the table can
show the output with an error message to the user.

Username (Condition) T T F F

Password (Condition) T F T F

Invalid
Open Invalid Invalid
Result (Action) Username and
Account Password Username
Password

Case 1: username and password both are correct.

Case 2: username is correct, but the password is not.
Case 3: username is incorrect, but the password is correct.
Case 4: username and password are both incorrect.
Check out: Test Cases for Login Page
1. Traffic Light System
You can easily create a decision table for testing the traffic light system. The table
below shows the inputs like the working state of every traffic light in the area, signs at
the traffic light, and the presence of traffic police. Further, the actions tell whether the
traffic lights, priority signs, or the traffic police regulate the traffic.

Conditions 1 2 3 4 5 6 7 8

Traffic light state (working or not) T T T T F F F F

Signs present? T T F F T T F F

7
SOFTWARE TESTING

Traffic Police Presence T F T F T F T F

Actions

Regulated by traffic lights – T – T – – –

Regulated by priority signs – – – – – T –

Regulated by traffic police T – T – T – T

Allow traffic to move – – – – – – – T

1. Chemical Factory Inventory

This is an example of a decision table for a chemical factory. The table below shows
the conditions and actions the company must take in different circumstances.

Condition 1 2 3 4 5

Is the customer authorized? F T T T T

Availability of chemical – F T T T

Is the chemical hazardous? – – F T T

Is the customer trained? – – – F T

Action

Accept X X

Reject X X X

Cause-Effect Graph falls under the black box testing technique which illustrates the
relationship between the outcome and all the factors resulting into it. It is very
important in the testing universe because it not only helps us in deriving the minimum
number of possible test cases which can cover a maximum test area of the software but
also helps us in identifying the gaps and ambiguities in the requirement specifications.
If we realize that we are not able to derive a clear cause-effect graph then it means that
there is a scope of improvement in the requirements. Cause-Effect Graph technique

8
SOFTWARE TESTING

converts the requirements specification into a logical relationship between the input
and the output conditions by using logical operators like AND, OR and NOT.
Before jumping into the steps to derive the graph, let us first understand what exactly a
cause and effect is?
What is a Cause?
This is either a condition or set of conditions because of which either some
change/transformation happens in the system or some output is generated.
What is an Effect?
An effect is nothing but either the output which is generated or system transformation
which has occurred due to some inputs which are fed.
Now let us see how to we derive the graph step by step.
Step1:
The very first step is to identify the cause and effects from the specifications and
assign unique numbers to each of them.
Step 2:
Draw a Boolean graph linking the cause and effects.
Step 3:
Specify the constraints on the graph describing the combinations of cause and/or
effects that are impossible.
for eg: if x == y and x == z, then x == z or x will always be equal to y and there will
not be any possibility of x not being equal to z.
Step 4:
Convert the graph into limited entry decision table by tracing state conditions in the
graph. Limited entry decision table is a form of decision table where there are only two
possible values for conditions which is nothing but Boolean value. This decision table
shall be used to derive the final test cases. Here, each column will be translated into a
test case.
Before deriving the graph, let us understand few notation that will be helpful. These
notations can exist between either Cause and Effect, Cause and Cause or Effect and
Effect. Below are some notations which exist between Cause and Effect.
1. Identity Function:

9
SOFTWARE TESTING

It means that if C1 is true, then E1 will also be true. If C1 is false, then E1 will also be
false. Both C1 and E1 will be identical in terms of Boolean value.
2. NOT Function:

It means if C1 exists or if C1 is true then E1 will cease to exist or E1 will be false.

Although, if C1 is false then E1 will be true. In short, if the cause exists then the
corresponding effect will not exist and vice versa.
3. OR Function:

Here there are three causes which are related to each other to derive a single effect. If
any of the causes is true, then only the effect will be true or else it will be false.
4. AND Function:

10
SOFTWARE TESTING

If both the causes C1 and C2 are true then the effect E1 will be true or else the effect
E1 will be false.
NOTE: In the first two functions (Identity and NOT) there is one to one mapping of
cause and effect which means for one cause there will be one effect and we cannot
have more then one causes for a single effect. However, in the case of OR and AND
functions, we can have multiple causes combined to derive one effect.
Now, let us try to derive a graph for a problem. The problem is that there are two input
values and one output value against each. The first value accepts only character and the
character should be either A or B. The second value must be a digit. If the two values
has above combination then the output printed is “MESSAGE 1”. If the character in
the first value is incorrect, then the output printed is “INCORRECT VALUE 1”. If the
character in the second value is not a digit, then the message printed is “INCORRECT
VALUE 2”.
Let us try to derive the happy flows of causes and corresponding effect.
Causes are:
C1: Character for first value is A.
C2: Character for first value is B.
C3: Character for second value is a digit.
Effects are:
E1: Output is “MESSAGE 1”. → (C1 OR C2) AND C3.
E2: Output is “INCORRECT VALUE 1” → When first value has neither A nor B.
(NOT C1) AND (NOT C2) = NOT (C1 OR C2). Using De-Morgan‟s law, NOT of
individual causes with AND can be combined as combined NOT of OR of both the
causes.
E3: Output is “INCORRECT VALUE 2”. When cause C3 is negated. NOT(C3).
If we try to derive the decision table with both positive and negative values the it
would be something like this:

11
SOFTWARE TESTING

In the above decision table, each column represents a test case. The same can be
derived into a easily understandable graph given below:

Here, the cause nodes are named and effect nodes are named but the intermediator nod
is not required to be name.
Path Testing is a method that is used to design the test cases. In path testing method,
the control flow graph of a program is designed to find a set of linearly independent
paths of execution. In this method Cyclomatic Complexity is used to determine the
number of linearly independent paths and then test cases are generated for each
path.
It give complete branch coverage but achieves that without covering all possible
paths of the control flow graph. McCabe‟s Cyclomatic Complexity is used in path
testing. It is a structural testing method that uses the source code of a program to
find every possible executable path.

12
SOFTWARE TESTING

Path Testing Process:

 Control Flow Graph:

Draw the corresponding control flow graph of the program in which all the
executable paths are to be discovered.
 Cyclomatic Complexity:
After the generation of the control flow graph, calculate the cyclomatic
complexity of the program using the following formula.
McCabe's Cyclomatic Complexity = E - N + 2P

Where,
E = Number of edges in control flow graph
N = Number of vertices in control flow graph
P = Program factor
 Make Set:
Make a set of all the path according to the control flow graph and calculated
cyclomatic complexity. The cardinality of set is equal to the calculated
cyclomatic complexity.
 Create Test Cases:
Create test case for each path of the set obtained in above step.
Path Testing Techniques:
 Control Flow Graph:
The program is converted into control flow graph by representing the code into
nodes and edges.

13
SOFTWARE TESTING

 Decision to Decision path:

The control flow graph can be broken into various Decision to Decision paths
and then collapsed into individual nodes.
 Independent paths:
Independent path is a path through a Decision to Decision path graph which
cannot be reproduced from other paths by other methods.

Advantages of Path Testing:

1. Path testing method reduces the redundant tests.
2. Path testing focuses on the logic of the programs.
3. Path testing is used in test case design.
The cyclomatic complexity of a code section is the quantitative measure of the
number of linearly independent paths in it. It is a software metric used to indicate
the complexity of a program. It is computed using the Control Flow Graph of the
program. The nodes in the graph indicate the smallest group of commands of a
program, and a directed edge in it connects the two nodes i.e. if the second
command might immediately follow the first command.
For example, if the source code contains no control flow statement then its
cyclomatic complexity will be 1, and the source code contains a single path in it.
Similarly, if the source code contains one if condition then cyclomatic complexity
will be 2 because there will be two paths one for true and the other for false.
Mathematically, for a structured program, the directed graph inside the control flow
is the edge joining two basic blocks of the program as control may pass from first to
second.
So, cyclomatic complexity M would be defined as,
M = E – N + 2P where E = the number of edges in the control flow
graph
N = the number of nodes in the control flow graph
P = the number of connected components
In case, when exit point is directly connected back to the entry point. Here, the
graph is strongly connected, and cyclometric complexity is defined as
M=E–N+P
where

14
SOFTWARE TESTING

E = the number of edges in the control flow graph

N = the number of nodes in the control flow graph
P = the number of connected components
In the case of a single method, P is equal to 1. So, for a single subroutine, the
formula can be defined as
M=E–N+2
where
E = the number of edges in the control flow graph
N = the number of nodes in the control flow graph
P = the number of connected components
How to Calculate Cyclomatic Complexity?
Steps that should be followed in calculating cyclomatic complexity and test cases
design are:
Construction of graph with nodes and edges from code.
 Identification of independent paths.
 Cyclomatic Complexity Calculation
 Design of Test Cases
Let a section of code as such:
A = 10
IF B > C THEN
A=B
ELSE
A=C
ENDIF
Print A
Print B
Print C

Cyclomatic Complexity
The cyclomatic complexity calculated for the above code will be from the control
flow graph. The graph shows seven shapes(nodes), and seven lines(edges), hence
cyclomatic complexity is 7-7+2 = 2.

15
SOFTWARE TESTING

Use of Cyclomatic Complexity

 Determining the independent path executions thus proven to be very helpful
for Developers and Testers.
 It can make sure that every path has been tested at least once.
 Thus help to focus more on uncovered paths.
 Code coverage can be improved.
 Risks associated with the program can be evaluated.
 These metrics being used earlier in the program help in reducing the risks.
Advantages of Cyclomatic Complexity
 It can be used as a quality metric, given the relative complexity of various
designs.
 It is able to compute faster than Halstead‟s metrics.
 It is used to measure the minimum effort and best areas of concentration for
testing.
 It is able to guide the testing process.
 It is easy to apply.
Disadvantages of Cyclomatic Complexity
 It is the measure of the program‟s control complexity and not the data
complexity.
 In this, nested conditional structures are harder to understand than non-
nested structures.
 In the case of simple comparisons and decision structures, it may give a
misleading figure.

A graph matrix is a data structure that can assist in developing a tool for
automation of path testing. Properties of graph matrices are fundamental for
developing a test tool and hence graph matrices are very useful in
understanding software testing concepts and theory.
What is a Graph Matrix ?
A graph matrix is a square matrix whose size represents the number of nodes in the
control flow graph. If you do not know what control flow graphs are, then
read this article. Each row and column in the matrix identifies a node and the entries
in the matrix represent the edges or links between these nodes. Conventionally,
nodes are denoted by digits and edges are denoted by letters.

16
SOFTWARE TESTING

Let‟s take an example.

Let‟s convert this control flow graph into a graph matrix. Since the graph has 4
nodes, so the graph matrix would have a dimension of 4 X 4. Matrix entries will be
filled as follows :
 (1, 1) will be filled with „a‟ as an edge exists from node 1 to node 1
 (1, 2) will be filled with „b‟ as an edge exists from node 1 to node 2. It is
important to note that (2, 1) will not be filled as the edge is unidirectional and
not bidirectional
 (1, 3) will be filled with „c‟ as edge c exists from node 1 to node 3
 (2, 4) will be filled with „d‟ as edge exists from node 2 to node 4
 (3, 4) will be filled with „e‟ as an edge exists from node 3 to node 4
The graph matrix formed is shown below :

Connection Matrix :
A connection matrix is a matrix defined with edges weight. In simple form, when a
connection exists between two nodes of control flow graph, then the edge weight is

17
SOFTWARE TESTING

1, otherwise, it is 0. However, 0 is not usually entered in the matrix cells to reduce

the complexity.
For example, if we represent the above control flow graph as a connection matrix,
then the result would be :

As we can see, the weight of the edges are simply replaced by 1 and the cells which
were empty before are left as it is, i.e., representing 0.
A connection matrix is used to find the cyclomatic complexity of the control
graph.
Although there are three other methods to find the cyclomatic complexity but this
method works well too.
Following are the steps to compute the cyclomatic complexity :
1. Count the number of 1s in each row and write it in the end of the row
2. Subtract 1 from this count for each row (Ignore the row if its count is 0)
3. Add the count of each row calculated previously
4. Add 1 to this total count
5. The final sum in Step 4 is the cyclomatic complexity of the control flow
graph
Let‟s apply these steps to the graph above to compute the cyclomatic complexity.

18
SOFTWARE TESTING

We can verify this value for cyclomatic complexity using other methods :
Method-1 :
Cyclomatic complexity
=e-n+2*P
Since here,
e=5
n=4
and, P = 1
Therefore, cyclomatic complexity,
=5-4+2*1
=3
Method-2 :
Cyclomatic complexity
=d+P
Here,
d=2
and, P = 1
Therefore, cyclomatic complexity,
=2+1
=3
Method-3:
Cyclomatic complexity
= number of regions in the graph
li

19
SOFTWARE TESTING

 Region 1: bounded by edges b, c, d, and e

 Region 2: bounded by edge a (in loop)
 Region 3: outside the graph
Therefore, cyclomatic complexity,
=1+1+1
=3
What is Data Flow Testing?
Data flow testing is a white box testing type concerned with the flow of variables and
not the module's flow. It follows where the variable is referenced. Data flow testing
makes use of control flow graphs and associations.
The below example will look at both techniques.
Example
<code>if(age>=18)<br>if(gender=='F')<br> print('You have made a difference
woman')<br>else<br> print('You have made a difference man')<br>else<br>
print('Young')</code>
Control Flow Graph of the Above Example
Control flow graphs are used to represent the code graphically. This representation
helps depict the code flow of variables to help data flow testing.
Types of Data Flow Testing
1. Static Data Flow Testing
Declaring the variables, using the variables, and finding the values all happen without
the code execution is static data flow testing. Control flow graphs are used for the
same.
2. Dynamic Data Flow Testing
The variables and their value are examined with the code execution in dynamic data
flow testing. The changes in the variable and their references are observed with the
requirement that the code must be executed.
Associations
Here associations are made between, where the variable is defined and used. The
format of the association is as follows: (line variable declared, line variable used,
variable name).
int(x)
if(x%2==0)
x=x+10

20
SOFTWARE TESTING

else
x=x+5

ssociations of the above code are as follows:

(1,(2,t),x) for the true condition in line 2 (1,(2,f),x) for the false condition in line 2
(1,3,x) for the x being used in line 3 (1,5,x) for the x being used in line 5
There are two types of uses of variables based on how they are being used in the code.
Predicate use: This value decides the flow of the code, as in line 2 is called p-
use. Computational use: The variable's value is used by another variable, so if we
have z=x in line 6. That would be a c-use.

Advantages of Data Flow Testing

1. Data flow testing helps to redefine the flow of code.
2. It helps to identify the excess code if it exists.
3. It helps to identify computational variables.
4. It tests the code without executing it.

Disadvantages of Data Flow Testing

1. Since it is white box testing, coding knowledge is required.
2. It is a time-consuming testing process.
3. It requires a good amount of manual testing.
4. It is a slow process as a lot of manual intervention is required.

Data Flow Testing Coverage

1. All definition coverage: It covers all the sub-paths from each definition.
2. All definition-c use coverage: It covers all the computation use sub-paths
from each definition
3. All definition-p use coverage: It covers all the predicate use sub-paths from
each definition
4. All-use coverage: It covers all the c-use and p-use sub-paths from each
definition.
5. All definition use coverage: It covers all the sub-paths from definition to their
respective use.

21
SOFTWARE TESTING

Data Flow Testing Strategies

Test case selection criteria are as follows
1. All-defs: All the sub-paths that include c-use and p-use. Suppose there is a
variable x and node i to select all edges.
2. All c-uses: There is global node i to all the sub-paths to node j. Select all the
sub-paths which are c-use.
3. All p-uses: There is global node i to all the sub-paths to node j. Select all the
sub-paths which directly use variable x.
4. Some c-uses: From the global declaration of variable x with node i, choose
selectively sub-paths node j, which affects the module.
5. Some p-uses: From the global declaration of variable x with node i. Choose
selectively sub-paths node j directly affecting the value of a variable.

ata Flow Testing Applications

1. Noticing the change and updation of a variable make the module more bug-
free than merely doing branch testing.
2. Debuggers are an excellent tool to track data changes in a variable.
3. Data flow testing tools are integrable into the compilers helping in unit testing.

Slice-based testing
Slice-based testing breaks down the entire system into different modules
called slices. Now, the most used slices are tested for accuracy. The common concept
in testing is that 90% of the bugs are due to 10% of modules. So, ensuring 10% of
modules are defect-free makes the product higher in quality.
Slice Based Testing
Slice Based Testing (SBT) can be defined as a software testing technique that is based
on slices – executable parts of the program or groups of statements which affect some
values at particular points of interest in the program, for example, parts where
variables are defined or the output of a group of statements.

22
SOFTWARE TESTING

How To Do Slicing

Slicing example in SBT: Code to print out even and odd numbers (Python)
num_list =range(1,12)
even_nums =[]
odd_nums =[]
forvar innum_list:
ifvar%2==0:
even_nums.append(var)
print(f"Even numbers: {even_nums}")
elifvar%3==0:
odd_nums.append(var)
print(f"Odd numbers: {odd_nums}")

There are two ways to look at a slice: By following the path of a variable of interest
or the part of the code that affects the output.
In our example, if we look at the odd numbers output, we can trace the part of the
code that leads us to this output.
In the slicing criteria given by Mark Weiser (who introduced SBT), a slice is defined
using this formula: S(v, n), where, v refers to the variable in question(for
example, where a variable is defined), and n is the statement of interest (for
example, where output is given), and S stands for the slice.
In the above example, to get the slice, we start from our output on line 10, which
becomes our n. Our variable is var.
So our slicing criteria is:
S(v,n) = S(var,10)

23
SOFTWARE TESTING

Our concern is the statements that lead us to the output.

These are:
10,9,8,4,3,1
So, our slice in this code is:
num_list =range(1,12)
odd_nums =[]

forvar innum_list:
elifvar%3==0:
odd_nums.append(var)
print(f"Odd numbers: {odd_nums}")

Slice Based Testing Types

There are two types of SBT: Static and Dynamic
#1) Dynamic Slice Based Testing
The SBT example explained above where we looked at the statements that affect the
printing of the odd numbers is dynamic SBT. Our concern is very specific. We get to
focus only on what directly affects the particular output.
We execute the code and use test data to ensure that it works as it is supposed to. We
could increase the range to range(1,50), for example, to see whether it still generates
only odd numbers. Dynamic SBT is also known as validation testing.
#2) Static Slice Based Testing
Unlike Dynamic SBT, static testing‟s focus is on a particular variable. If we think
about our output in the above example as var, we can trace the slice that affects it
as 10,9,8,7,6,5,4,3,2,1
It is basically the entire code block! Here we verify that the code is correct in terms of
syntax and requirements, and we do not execute it. Static SBT is also known as
verification testing.

24
SOFTWARE TESTING

It is important to note that dynamic SBT is „smaller‟ when compared to its static
counterpart. It is also more specific.
Slice Based Testing Best Practices/Guidelines
Slicing criteria should be determined by:
 Statements where values are defined or assigned value, as well as reassigned
value.
 Statements where values are being received from outside the program, for
example, via user input.
 Statements that print output/return output.
 The program‟s last statement, for example, a function call which may define
values, or provide values to arguments
Advantages of slice-based testing include:
 Since in SBT we only work with specific areas of interest, it makes it easier to
effectively generate test suites.
 The path is defined by dependencies within the code, which is better than
using path coverage.
 With SBT, it‟s easier to find errors in the source code.
Disadvantages of slice-based testing include:
 If we use dynamic testing when testing a large codebase, we will need a lot of
computational resources.
 If we use static testing, we might miss out on errors.

25