Structural Testing

 In structural testing, the software is viewed as a white box and test cases are
determined from the implementation of the software.
 Structural testing techniques include control flow testing and data flow testing
 Control Flow Testing
 Control flow testing uses the control structure of a program to develop the test
cases for the program.
 The test cases are developed to sufficiently cover the whole control structure of
the program.
 The control structure of a program can be represented by the control flow graph
of the program.
 Control Flow Testing

Control Flow Graph

 Control Flow Graph is a visual representation of a program’s control flow
 It shows how the program progresses through various statements and decision points.
 The control flow graph was developed by Frances E. Allen, inspired by Reese T. Prosser’s
use of boolean connectivity matrices for flow analysis.
Control Flow Testing
 This is a software testing technique that helps ensure that the different paths a program can
take are tested.
 It is a white-box testing technique.
 The goal of control flow testing is to verify that all possible execution paths of a program
behave as expected.
 A computer program has a set of instructions for the computer to follow.
 Sometimes, the program can go in different ways based on certain conditions
 if-else statements in code
 Control Flow Testing
 Control Flow Graph
 The control flow graph G = (N, E) of a program consists of a set of nodes N and a set
of edge E.
 Each node represents a set of program statements.
 There are five types of nodes.
 There is a unique entry node and a unique exit node.
 There is an edge from node n1 to node n2 if the control may flow from the last
statement in n1 to the first statement in n2 .
 A decision node contains a conditional statement that creates 2 or more control
branches (e.g. if or switch statements).
 A merge node(junction node) usually does not contain any statement
 It is used to represent a program point where multiple control branches
merge(Junction node).
 A statement node contains a sequence of statements.
 The control must enter from the first statement and exit from the last statement.
 The testers will test all these different paths to ensure the program works correctly.
 It is like checking that different roads on a map lead to the right destination.

How is control flow testing done?

 Control flow testing is usually performed using a control flow graph (CFG),
 which is a graphical representation of the flow of a program.
 The CFG shows the different nodes in the program, such as
 statements, branches, and loops, and the edges between them.
 The software tester will start by creating CFG, which will help them identify all the possible
execution paths of a program.
 The tester can create test cases to cover each path.
Purpose of Control Flow Testing
 A study states that control flow testing helps detect 50% of bugs during unit testing.
 that is about 33% of all bugs.
 But, control flow testing cannot find all bugs in a program.
 For example, it can not find interface issues.
 Control Flow Testing
 Here are some examples of control flow testing,
 Testing all branches of an if statement.
 Testing all cases of a switch statement.
 Checking all possible iterations of a loop.
 Testing the error handling.
 Testing the performance of the application for different inputs.
 Control Testing Example
 Control Flow Testing
Uses of Control Flow Testing
 Analyzing program code by executing test cases.
 Involves executing data flow.
 Unit Testing
 Control flow testing is mainly used in unit testing.
 It aims to identify the different paths of execution in the code.
 Test cases are then created based on these paths and executed.
 Control Flow Graphs
 This testing involves creating control flow graphs.
 These graphs provide a visual representation of how the program flows.
 By analyzing these paths, testers will be able to write various test cases.
 High Test Coverage
 When testing with CFGs, every node and edge in the graph is covered.
 Thus, it helps achieve high test coverage.
 Control Flow Testing
Notation of Control Flow Testing
 Control flow testing consists of four nodes, namely,
 Node, Edge, Decision Node, Junction node,
Node
 A node represents a basic block of code.
 It is a section of code that runs from start to end.
 The nodes show the order of procedure in a program.
 They help testers to identify what step comes next, making it easy to understand the
sequence of actions.
Edge
 An edge represents a possible transition or flow of control from one node to another.
 Control Flow Testing
Decision Node
 A decision node, also known as a conditional node, represents a point in the program where a
decision is made based on a condition (e.g., an if-else statement).
Junction Node
 A junction node is a point in the program where at least three nodes meet.
 It is used to represent points where multiple branches merge back into a single path or split into
multiple paths.
 Simply put, junction nodes are where different nodes lead to one node.
 Control Flow Testing
Control Flow Testing Notations – Example
 Let’s understand these notations using a simple program.
 The below program checks if a person is eligible to vote or not.
Public class EligiblityCheck{
public static void main(String []args)
{
Int x=45;
If(x>=18)
{
System.out.println(“You are eligible to vote”);
}
else
{
System.out.println(“you are not eligible to vote”)
}}}
 Control Flow Testing
What will this program do?
 It takes two paths,
 If x is greater than or equal to 18, it prints the message “You are eligible
to vote.”
 Else,
 when x is less than 18, it prints the message “You aren’t eligible to vote.”
 The input value ‘x’ denotes the age.
 Sample Control Flow Graph
 Now, the control flow graph for the above program will be as follows

• Nodes – Start, Age, Eligible, Not Eligible, Stop

• Decision node – x>=18
• The last node that leads to the stop is the Junction
node.
• Edge – All the direction arrows that connect the nodes
 Control Flow Testing
Decision Coverage Testing
 Decision coverage technique comes under white box testing which gives decision
coverage to Boolean values.
 This technique reports true and false outcomes of Boolean expressions.
 There is a possibility of two or more outcomes from the statements like do while statement,
if statement and case statement (Control flow statements),
 It is considered as decision point because there are two outcomes either true or false.
 Decision coverage covers all possible outcomes of each and every Boolean condition of the
code by using control flow graph or chart.
 Generally, a decision point has two decision values one is true, and another is false
 The percent of decision coverage can be found by dividing the number of exercised
outcome with the total number of outcomes and multiplied by 100 .
 Control Flow Testing

 Difficult to get 100% coverage because sometimes expressions get complicated.

 Due to this, there are several different methods to report decision coverage.
 All these methods cover the most important combinations and very much similar to decision coverage.
 The benefit of these methods is enhancement of the sensitivity of control flow.
 Consider the code to apply on decision coverage technique:
Test (int a)
{
If(a>4)
a=a*3
Print (a)
}
 Control Flow Testing
 Scenario 1:
Value of a is 7 (a=7)
Test (int a=7)
{ if (a>4)
a=a*3
print (a)
}
 The code highlighted in blue is executed code. The
outcome of this code is "True" if condition (a>4) is
checked.
 Control flow graph when the value of a is 7.
Decision Coverage = ½*100 (Only "True" is
Calculation of Decision Coverage percent:
exercised)
=100/2
= 50
Decision Coverage is 50%
 Control Flow Testing
 Scenario 2: • The code highlighted in blue will be executed.
• The outcome of this code is ?False? if condition (a>4) is
Value of a is 3 (a=3)
checked.
Test (int a=3) • Control flow graph when the value of a is 3
{ if (a>4)
Calculation of Decision Coverage percent:
a=a*3
print (a)
}

= ½*100 (Only "False" is exercised) <br>

=100/2
= 50
Decision Coverage = 50%
Test Case Value of Output Decision Coverage
A

1 3 3 50%
2 7 21 50%
 Control Flow Testing
Path Coverage testing
 It is a structured testing technique for designing test cases with intention 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.
 In this type of testing every statement in the program is guaranteed to be executed at
least one time. Flow Graph, Cyclomatic Complexity are used to arrive at basis path

Advantages of Path Testing:

• Path Testing helps reducing redundant tests
• Focus on program logic
• Test cases will execute every statement in a program at least once

PathCoverage = Number of Paths Covered/ Number of Total Paths

 Control Flow Testing
• Example of Path Coverage Testing
Read A
Read B
IF A+B > 50 THEN
Print "Large"
ENDIF
If A+B<50 THEN
Print "Small"
ENDIF

• PathCoverage ensures covering of all the

paths from start to end.
All possible paths are-
1-3-5-7
1-3-5-6-8
1-2-4-5-6-8
1-2-4-5-7
So PathCoverage is 4.
Control Flow Testing
Condition coverage testing
 It is a type of white-box testing that tests all the conditional expressions in a program for all possible
outcomes of the conditions.
 It is also called predicate coverage.
 Condition coverage vs. branch coverage
 In branch coverage, all conditions must be executed at least once.
 On the other hand, in condition coverage, all possible outcomes of all conditions must be tested at least
once.
 Example

int a = 10; • Branch coverage requires that the condition a > 0 is executed
if (a > 0) at least once.
{ • Condition coverage requires that both the outcomes a > 0 =
cout<<"a is positive"; True and a > 0 = False of the condition a > 0 are executed at
} least once.
 Control Flow Testing
int num1 = 0; The condition coverage testing of the code above will be
if(num1>0){ as follows:
Test case number
cout<<"valid input"; num1>0 Final output

}else{ 1 True True

cout<<"invalid input";
2 False False
}
int num1 = 0; Test case number
int num2 = 0; num1>0 num2<10 Final output
if((num1>0 || num2<10)){
cout<<"valid input"; 1 True Not required True
}else{
cout<<"invalid input"; 2 False True True
}
3 False False False
 Control Flow Testing
Test case
int num1 = 0; number num1>0 num2<10 num1+nu Final
m2<15 output
int num2 = 0;
if((num1>0 || num2<10) && (num1+num2<15)){ 1 True don't care True True
cout<<"valid input";
2 True don't care False False
}else{
cout<<"invalid input"; 3 False True True True

}
4 False True False False

5 False False Not False

required
Assignment

 if ( ((u == 0) || (x>5)) && ((y<6) or (z == 0)) )

 {
 /* instructions */
 }
 else
 {
 /* instructions */
 }

 Build a full test Coverage of the above condition

 Control Flow Testing
 Statement Coverage Testing
 The statement coverage technique is used to design test cases for white box testing
which involves the execution of all the statements of the source code at least once.
 What is Statement Coverage?
 It is one type of white box testing technique that ensures that all the statements of
the source code are executed at least once.
 It covers all the paths, lines, and statements of a source code.
 It is used to design test box cases where it will find out the total number of
executed statements out of the total statements present in the code.
 Control Flow Testing
 Formula:
 Statement coverage = (Number of executed statements / Total number of
statements in source code) * 100

Case 1:
• If A = 7, B= 3
• No of statements Executed= 5
e.g. 1: • Total statements= 7
• Statement coverage= 5 / 7 * 100
Read A • = 71.00 %
Read B
if A > B Case 2:
Print “A is greater than B” • If A = 4, B= 8
else • No of statements Executed= 6
Print “B is greater than A” • Total statements= 7
End if • Statement coverage= 6 / 7 * 100
• = 85.20 %
 Control Flow Testing

Example 2: Case 1:
• If A = 4, B= 8
print (int a, int b)
• No of statements Executed= 6
{ • Total statements= 8
int sum = a + b; • Statement coverage= 6 / 8 * 100
• = 75.00 %
if (sum > 0)
print (“Result is positive”)
else
print (“Result is negative”)
Case 2:
} If A = 4, B= -8
No of statements Executed= 7
Total statements= 8
Statement coverage= 7 / 8 * 100
= 87.50 %
 Control Flow Testing
 In the internal code structure, there are Why is statement coverage used?
loops, arrays, methods, exceptions, and
control statements. • To check the quality of the code.
 Some code would be executed based on • To determine the flow of different paths of
input while some may not. the program.
 Statement coverage will execute all • Check whether the source code expected to
possible paths and statements of the code perform is valid or not.
 Statement coverage covers: • Tests the software’s internal coding and
 Dead code. infrastructure.
 Unused statements. Drawback of Statement Coverage:
 Unused branches. • Cannot check the false condition.
 Missing statements.
• Different input values to check all the
conditions.
• More than one test case may be required to
cover all the paths with a coverage of 100%.
What is Data Flow Testing:

 It is a method that is used to find the test paths of a program according to the locations of definitions
and uses of variables in the program.
 It has nothing to do with data flow diagrams. Furthermore, it is concerned with:
 Statements where variables receive values,
 Statements where these values are used or referenced.
 To illustrate the approach of data flow testing, assume that each statement in the program assigned a
unique statement number.
 For a statement number S-
 DEF(S) = {X | statement S contains the definition of X}
 USE(S) = {X | statement S contains the use of X}
 If a statement is a loop or if condition then its DEF set is empty and USE set is based on the condition
of statement s.
 Data Flow Testing uses the control flow graph to find the situations that can interrupt the flow of the
program.
 What is Data Flow Testing
 Reference or define anomalies in the flow of the data are detected at the time of associations
between values and variables.
 These anomalies are:
 Using a variable without declaration
 Deleting a variable without declaration
 Defining a variable two times
 Deleting a variable without using it in the code
 Deleting a variable twice
 Using a variable after deleting it
 Not using a variable after defining itAn anomaly is denoted by a two character sequence
of actions
 Example: 'ku' means that the object is killed and then used, where as 'dd' means that the
object is defined twice without an intervening usage
 What is Data Flow Testing
 Types of Data Flow Testing:
 Testing for All-Du-Paths:
 It Focuses on “All Definition-Use Paths.
 All-Du-Paths is an acronym for “All Definition-Use Paths.”
 Using this technique, every possible path from a variable’s definition to every usage
point is tested.
 All-Du-Path Predicate Node Testing:
 This technique focuses on predicate nodes, or decision points, in the control flow
graph.
 All-Uses Testing:
 This type of testing checks every place a variable is used in the application.
 All-Defs Testing:
 This type of testing examines every place a variable is specified within the
application’s code.
 What is Data Flow Testing
 Testing for All-P-Uses:
 All-P-Uses stands for “All Possible Uses.” Using this method, every potential use of a variable is tested.
 All-C-Uses Test:
 It stands for “All Computation Uses.”
 Testing every possible path where a variable is used in calculations or computations is the main goal of this
technique.
 Testing for All-I-Uses:
 All-I-Uses stands for “All Input Uses.”
 With this method, every path that uses a variable obtained from outside inputs is tested.
 Testing for All-O-Uses:
 It stands for “All Output Uses.”
 Using this method, every path where a variable has been used to produce output must be tested.
 Testing of Definition-Use Pairs:
 It concentrates on particular pairs of definitions and uses for variables.
 Testing of Use-Definition Paths:
 This type of testing examines the routes that lead from a variable’s point of use to its definition.
 What is Data Flow Testing

 Advantages of Data Flow Testing:

 To find a variable that is used but never defined,
 To find a variable that is defined but never used,
 To find a variable that is defined multiple times before it is use,
 Deallocating a variable before it is used.
 Disadvantages of Data Flow Testing
 Time consuming and costly process
 Requires knowledge of programming languages
 What is Data Flow Testing
 Example:
 1. read x, y;
 2. if(x>y)
 3. a = x+1
 else
 4. a = y-1
 5. print a;
 Control flow graph of above example:

Define/use of variables of above example:

Variable Defined at node Used at node

x 1 2, 3

y 1 2, 4

a 3, 4 5
 What is Data Flow Testing
 Data flow testing criteria
 Control flow diagrams are a keystone in testing the structure of software programs.
 By examining the flow of control between the various components, we can design and select test cases.
 Data-flow testing is a control-flow testing technique which also examines the lifecycle of data variables.
 Techniques of data flow testing
 Data flow testing can be done using one of the following two techniques:
 Control flow graph
 Making associations between data definition and usages
 Control flow graph
 A control flow graph is a graphical representation of the flow of control, i.e., the order of statements in which they will
be executed.
 Consider the following piece of pseudo-code:
What is Data Flow Testing

 1. input(x) • In the above piece of code, if the value of x entered by the

 user is greater than 5, then the order of execution of
2. if(x>5)
statements would be:
 3. z = x + 10
 4. else 1, 2, 3, 6
 5. z=x-5 • If the value entered by the user in line 1 is less than or equal
 6. print("Value of Z: ", z) to 5, the order of execution of statements would be:

1, 4, 5, 6
 What is Data Flow Testing
 Making associations
 In this technique, we make associations between two kinds of statements:
 Where variables are defined
 Where those variables are used
 An association is made with this format:
 (line number where the variable is declared, line number where the variable is used, name of the
variable)
 For example, (1, 3, x) would mean that the variable ‘x’ is defined on line 1 and used on line 3.
 Now, consider the following piece of pseudo-code:
1. input(x)
2. if(x>5)
3. z = x + 10
4. else
5. z=x-5
6. print("Value of Z: ", z)
 What is Data Flow Testing
 For the above snippet of pseudo-code, we will make the following associations:
 (1, (2,t), x): for the true case of IF statement in line 2
 (1, (2,f), x): for the false case of IF statement in line 2
 (1, 3, x): variable x is being used in line 3 to define the value of z
 (1, 5, x): variable x is being used in line 5 to define the value of z
 (3, 6, z): variable z is being used in line 6, which is defined in line 3
 (5, 6, z): variable z is being used in line 6, which is defined in line 5
 The first two associations are for the IF statement on line 2. #
 One association is made if the condition is true, and the other is for the false case.
 What is Data Flow Testing
 Now, there are two types of uses of a variable:
 predicate use: the use of a variable is called p-use. Its value is used to decide the flow of the
program, e.g., line 2.
 computational use: the use of a variable is called c-use when its value is used compute another
variable or the output, e.g., line 3.
 After the associations are made, these associations can be divided into these groups:
 All definitions coverage
 All p-use coverage
 All c-use coverage
 All p-use, some c-use coverage
 All c-use, some p-use coverage
 All uses coverage
 Once the associations are divided into these groups, the tester makes test cases and examines each
point.
 The statements and variables which are found to be extra are removed from the code.
 Domain Testing
 Domain testing is a testing process where the software is tested to ensure it doesn't accept invalid or
out-of-range values.
 The output is tested against a minimum number of inputs to see whether the system is accepting the
input within the required range or not.
 The white box testing is a perfect example of domain testing.
 What is White Box Testing?
 In this process, testing engineers test the internal structure, coding, and software design, making sure it goes
with the input-output flow.
 It also determines the design, usability, and overall security of the software.
 Since the code is visible to the testers, white box testing is also called the clear box, transparent box, glass box,
and code-based testing.
 This is because white box testing allows testers to penetrate the outer shell of an application and look at its
inner structure.
 White box testing and black box testing both come under software testing.
 The difference is that in a black box, the software is tested based on its external and end-user perspective.
 However, in the white box, testing is done to analyze the inner structure of the product.
 Domain Testing
 Domain Testing Strategy
 A specific boundary defines every domain.
 During the test, testers analyse each point nearby those boundaries.
 Each testing process starts with a question, and the purpose of domain testing is to find solutions
to these questions.
 What domains to choose for the testing process?
 What values should one choose for the test?
 How do you group values into classes?
 How do you get the results?
 Example of Domain testing
 Let's say there is a group of students in a hall.
 They have been given a set of tasks based on their age and gender inputs.
 Here, you can consider the hall as the test, age groups as boundary values with numerous
possible scenarios.
 Domain Testing
 Tasks are given to students in the following ways −
 Students under ten are asked to draw.
 Boys 10 >= 15 are asked to compete in a race
 Girls 10 >= 15 are asked to participate in a sport
 Boys > 15 are asked to dance
 Girls > 15 are asked to sing
 Reaming > 15 students are asked to give a presentation
 After having the above algorithms, testers need to group the values into classes.
 One can classify students into age groups, then set boundary values such as highest and lowest age values.
 What domains are tested in Domain Testing?
 You can test any domains containing input and output functionality.
 First, one needs to enter the input value and verify the output.
 How do you group values into classes?
 For grouping values into classes, you need to partition the values into subsets.
 Domain Testing
 You can partition values in two ways −
 Equivalence Partitioning
 In this process, you have to divide a set of test conditions into groups or set in a way
that the system handles them equivalently.
 In short, the system should consider these partitions as the same.
Variable Valid Class Invalid Class Boundaries &
Equivalence Equivalence Special cases
Class Class

X 0-20 0

20

<0 -1

>20 21
 Domain Testing
 Explanation −
 If a field accepts ranges between 0-20, then it should not accept invalid entries and out of
boundaries entries like -1 and 21.
 The field should only accept values 0, 20, and any number in between them.
 Boundary Testing
 Boundary testing analysis or BVA is a process to test boundaries between partitions.
 In this process, you will have to test both valid and invalid input values from the partition.
 Example − Let's say you are ordering a sandwich through an online platform, and you are asked
to enter the number of sandwiches you are intended to order.
 Now, it's a rule that a single customer can only order up to 10 sandwiches.
 So, when you enter the value 1 to 10, it is considered valid.
 A success message will be displayed.
 If you choose 11 to 99, it will be considered invalid, leading to an error message.
Domain Testing
 Which values of the classes were tested in domain testing?
 You need the boundary values to test the values of the class.
 Example derived from the previous case.
 Test condition −
 Number > 10 in the sandwich field is invalid.
 Number < 1 is considered invalid.
 Number 1 to 10 is valid.
 Three-digit numbers are invalid.
Domain Testing
 How to determine the result?
 The output results are determined through domain knowledge.
 How to formulate a domain testing structure?
 Analyze beforehand what can go wrong while setting boundaries
 Prepare strategies to handle each case
 Checkpoints to conduct error testing
 Use one test point to evaluate adjacent domains
 Check off unnecessary test points
 Run the test
 Check for errors in boundaries
 Verify every boundary are free from defects
Domain Testing
 Is it important to have domain knowledge for domain testing?
 It is highly important to have at least basic domain knowledge for an expert to
conduct domain testing.
 Domain knowledge is crucial as each industry or field is unique and has specific
requirements.
 Retail − In retail domains, the workflow runs at different levels. Therefore, testing
engineers looking forward to running domain testing in retail must know how
things work in warehouse management, in-store solutions, and so on.
 Online Banking − Online backing consists of several crucial internet-dependent
activities such as login, money transfer, bill payment, etc., which is quite different
than retails.
 Healthcare − Handling healthcare domains is quite critical as it holds a huge risk to
someone's life. Besides, it includes numerous menial yet time-consuming tasks like
patient's entry, health history, prescriptions, setting & modifying schedules,
insurance, etc.
System Integration
Testing
 The Concept of Integration Testing

 A software module is a self-contained element of a system

 Modules are individually tested commonly known as unit testing
 Next major task is to put the modules(pieces) together to construct the complete system
 Construction of a working system from the pieces is not a straightforward task because of
numerous interface errors
 The objective of system integration testing (SIT) is to build a “working” version of the system
 Putting modules together in some manner
 Ensuring that the additional modules work as expected without disturbing the functionalities of the modules already put together
 The Concept of Integration Testing
 Integration testing is said to be complete when
 The system is fully integrated together
 All the test cases have been executed
 All the severe and moderated defects found have been fixed
 The major advantages of conducting SIT are as follows:
 Defects are detected early
 It is easier to fix defects detected earlier
 Earlier feedbacks can be obtained on the health and acceptability of the individual
modules and on the overall system
 Scheduling of defect fixes is flexible, and it can overlap with development
 Different Types of Interfaces

 Three common paradigms for interfacing modules:

 Procedure call interface
 Shared memory interface
 Message passing interface

 The problem arises when we “put modules together” because of interface errors
 Interface errors
 Interface errors are those that are associated with structures existing outside the
local environment of a module, but which the module uses
 Types
 Construction
 Some programming languages, such as C, generally separate the interface
specification from the implementation code
 Different Types of Interfaces
 In a C program, programmers can write a statement
 #include header.h where header.h contains an interface specification.
 Since the interface specification lies somewhere away from the actual code,
programmers overlook the interface specification while writing code.
 Therefore, inappropriate use of #include statements cause construction errors.
 Inadequate functionality
 These are errors caused by implicit assumptions in one part of a system that
another part of the system would perform a function.
 However, in reality, the “other part” does not provide the expected functionality –
intentionally or unintentionally by the programmer who coded the other part.
 Different Types of Interfaces
 Location of Functionality
 Disagreement on or misunderstanding about the location of a functional capability within the
software leads to this sort of error.
 The problem arises due to the design methodology, since these disputes should not occur at the
code level.
 It is possible that inexperienced personnel contribute to the problem.
 Changes in Functionality
 Changing one module without correctly adjusting for that change in other related modules
affects the functionality of the program.
 Added Functionality:
 A completely new functional module, or capability, was added as a system modification.
 Any added functionality after the module is checked in to the version control system without a
CR is considered to be an error.
 Different Types of Interfaces
 Misuse of Interface
 One module makes an error in using the interface of a called module.
 Interface misuse can take the form of wrong parameter type, wrong parameter
order, or wrong number of parameters passed.
 Inadequate Error Processing
 A called module may return an error code to the calling module.
 However, the calling module may fail to handle the error properly.
 Violation of Data Constraints
 A specified relationship among data items was not supported by the
implementation.

 This can happen due to incomplete detailed design specifications .

 Different Types of Interfaces
 Timing/Performance Problems
 These errors were caused by inadequate synchronization among
communicating processes.
 A race condition is an example of these kinds of error.
 Coordination of Changes
 These errors are caused by a failure to communicate changes to one
software module to those responsible for other interrelated modules.
 Hardware/Software Interfaces
 These errors arise from inadequate software handling of hardware
devices.
 For example, a program can send data at a high rate until the input
buffer of the connected device is full.
 Different Types of Interfaces
 Initialization/Value Errors
 A failure to initialize, or assign, the appropriate value to a variable data structure leads to
this kind of error.
 For example, if the programmer forgets to reinitialize the pointer before using a function
once again, the pointer may eventually point to code.
 Inadequate Interface Support
 The actual functionality supplied was inadequate to support the specified capabilities of
the interface.
 For example, a module passes a temperature value in Celsius to a module which interprets
the value in Fahrenheit.
 Misunderstanding of Interface
 A calling module may misunderstand the interface specification of a called module.
 The called module may assume that some parameters passed to it satisfy a certain
condition, whereas the caller does not ensure that the condition holds.
Granularity of System Integration
 System Integration testing is performed at different levels of granularity
 Intra-system testing
 This form of testing constitutes low-level integration testing with the
objective of combining the modules together to build a cohesive system
 Inter-system testing
 It is a high-level testing phase which requires interfacing independently
tested systems
 Pairwise testing
 In pairwise integration, only two interconnected systems in an overall
system are tested at a time
 This ensures that two systems under consideration can function together,
assuming that the other systems within the overall environment behave as
expected
 System Integration Techniques
 Common approaches to perform system integration testing
 Incremental

 Top-down

 Bottom-up

 Sandwich

 Big-bang
Incremental

 A software image is a compiled software binary

A build is an interim software image for internal testing within an
organization
 Constructing a build is a process by which individual modules are integrated
to form am interim software image.
 The final build is a candidate for system testing
 Constructing a software image involves the following activities
 Gathering the latest unit tested, authorized versions of modules
 Compiling the source code of those modules
 Incremental

 Checking in the compiled code to the repository

 Linking the compiled modules into subassemblies
 Verifying that the subassemblies are correct
 Exercising version control
 Integration testing is conducted in an incremental manner as a series of test cycles
 In each test cycle, a few more modules are integrated with an existing and tested
build to generated larger builds
 The complete system is built, cycle by cycle until the whole system is operational
for system-level testing.
 Incremental

 The number of SIT cycles and the total integration time are determined by the
following parameters:
 Number of modules in the system
 Relative complexity of the module (cyclomatic complexity)
 Relative complexity of the interfaces between the modules
 Number of modules needed to be clustered together in each test cycle
 Whether the modules to be integrated have been adequately tested before
 Turnaround time for each test-debug-fix cycle
Incremental

 A release note containing the following information accompanies a build.

 What has changed since the last build?
 What outstanding defects have been fixed?
 What are the outstanding defects in the build?
 What new modules, or features, have been added?
 What existing modules, or features, have been enhanced, modified, or
deleted?
 Are there any areas where unknown changes may have occurred?
Incremental

 A test strategy is created for each new build and the following issues are
addressed while planning a test strategy
 What test cases need to be selected from the SIT test plan?
 What previously failed test cases should now be re-executed in order to
test the fixes in the new build?
 How to determine the scope of a partial regression tests?
 What are the estimated time, resource demand, and cost to test this build?
Incremental

 Creating a daily build is very popular among many organizations

 It facilitates to a faster delivery of the system
 It puts emphasis on small incremental testing
 It steadily increases number of test cases
 The system is tested using automated, re-usable test cases
 An effort is made to fix the defects that were found within 24 hours
 Prior version of the build are retained for references and rollback
 A typical practice is to retain the past 7-10 builds
 Top-down
Top-down

 Module A has been decomposed into modules B, C,

and D
 Modules B, D, E, F, and G are terminal modules
Top-down integration of modules A and B  First integrate modules A and B using stubs C` and
D` (represented by grey boxes)
 Next stub D` has been replaced with its actual
instance D
Top-down integration of modules A, B and D  Two kinds of tests are performed:
 Test the interface between A and D
 Regression tests to look for interface defects
between A and B in the presence of module D
Top-down integration of modules A, B, C, D, E and F
 Top-down

• Stub C` has been replaced with the actual module C,

and new stubs E`, F`, and G`
• Perform tests as follows:
• first, test the interface between A and C;
• second, test the combined modules A, B, and D in
the presence of C
• The rest of the process depicted in the right handTop-down integration of modules A, B, D and C
side figures.

Top-down integration of modules A, B, C, D and E

Top-down integration of modules A, B, C, D, E and F

 Top-down
 Advantages
 The SIT engineers continually observe system-level functions as the integration
process continue
 Isolation of interface errors becomes easier because of the incremental nature of the
top-down integration
 Test cases designed to test the integration of a module M are reused during the
regression tests performed after integrating other modules
 Disadvantages
 It may not be possible to observe meaningful system functions because of an absence
of lower level modules and the presence of stubs.
 Test case selection and stub design become increasingly difficult when stubs lie far
away from the top-level module.
 Bottom-up
 One has to design a test driver to integrate
lowest-level modules E, F, and G
 Return values generated by one module is
likely to be used in another module
 The test driver mimics module C to
Bottom-up integration of module E, F, and G
integrate E, F, and G in a limited way.
 The test driver is replaced with actual
module , i.e., C.
 A new test driver is used
 At this moment, more modules such as B
and D are integrated
 The new test driver mimics the behaviour of
module A
Bottom-up integration of module B, C, and D with F, F, and
 Finally, the test driver is replaced with G
module A and further test are performed
 Bottom-up

 Advantages
 One designs the behaviour of a test driver by simplifying the behaviour of the actual
module
 If the low-level modules and their combined functions are often invoked by other modules,
then it is more useful to test them first so that meaningful effective integration of other
modules can be done
 Disadvantages
 Discovery of major faults are detected towards the end of the integration process, because
major design decision are embodied in the top-level modules
 Test engineers can not observe system-level functions from a partly integrated system.
 In fact, they can not observe system-level functions until the top-level test driver is in place
 Big-bang and Sandwich

 Big-bang Approach
 First all the modules are individually tested
 Next all those modules are put together to construct the entire system which is tested as a whole
 Sandwich Approach
 In this approach a system is integrated using a mix of top-down, bottom-up, and big-bang
approaches
 A hierarchical system is viewed as consisting of three layers
 The bottom-up approach is applied to integrate the modules in the bottom-layer
 The top layer modules are integrated by using top-down approach
 The middle layer is integrated by using the big-bang approach after the top and the bottom
layers have been integrated
Software and Hardware Integration

 Integration is often done in an iterative manner

 A software image with a minimal number of core modules is loaded on a
prototype hardware
 A small number of tests are performed to ensure that all the desired software
modules are present in the build
 Next, additional tests are run to verify the essential functionalities
 The process of assembling the build, loading on the target hardware, and
testing the build continues until the entire product has been integrated
 Hardware Design Verification Tests

 A hardware engineering process consists of four phases

 Planning and specification
 Design, prototype implementation, and testing
 Integration with the software system
 Manufacturing, distribution and field service
 A hardware Design Verification Test (DVT) plan is prepared and executed by the
hardware group before the integration with software system
 Hardware Design Verification Tests

 The main hardware tests are as follows:

 Diagnostic Test

 Electrostatic Discharge Test

 Electromagnetic Emission Test
 Electrical Test

 Thermal Test

 Environment Test

 Equipment Handling and Packaging Test

 Acoustic Test

 Safety Test

 Reliability Test
 Hardware and Software Compatibility Matrix

 H/W and s/w compatibility information is maintained in the form of a

compatibility matrix
 It documents different revisions of the h/w and s/w that will be used for
official release of the product
 An Engineering Change Order (ECO) is a formal document that describes a
change to the hardware and software
 An ECO document includes the hardware software compatible matrix
 It is distributed to the operation, customer support and sales teams of the
organization
Test Plan for System Integration Testing
Test Plan for System Integration Testing
Test Plan for System Integration Testing
 Test Plan for System Integration
 Categories of System Integration Tests:
 Interface integrity – Internal and external interfaces are tested as each module is
integrated
 Functional validity – Tests to uncover functional errors in each module after it is
integrated
 End-to-end validity – Tests are designed to ensure that a completely integrated
system works together from end-to-end
 Pairwise validity – Tests are designed to ensure that any two systems work properly
when connected by a network
 Interface stress – Tests are designed to ensure that the interfaces can sustain the load
 System endurance – Tests are designed to ensure that the integrated system stay up
for weeks
 Off-the-self Component Integration
 Off-the-self Component Integration Organization occasionally purchase off-the-
self (OTS) components from vendors and integrate them with their own components
 Useful set of components that assists in integrating actual components:
 Wrapper: It is a piece of code that one builds to isolate the underlying
components from other components of the system
 Glue: A glue component provides the functionality to combine different
components
 Tailoring: Components tailoring refers to the ability to enhance the functionality
of a component
 Tailoring is done by adding some elements to a component to enrich it with a
functionality not provided by the vendor
 Tailoring does not involve modifying the source code of the component
 Off-the-shelf Component Testing
 Off-the-shelf Component Testing OTS components produced by the vendor
organizations are known as commercial off-the-shelf (COTS) components
 A COTS component is defined as:
 A unit of composition with contractually specified interfaces and explicit context
dependencies only.
 A software component can be deployed independently and is subject to composition
by third parties
 Three types of testing techniques are use to determine the suitability of a COTS
component:
 Black-box component testing: This is used to determine the quality of the component
 System-level fault injection testing: This is used to determine how well a system will
tolerate a failing component
 Operational system testing: This kind of tests are used to determine the tolerance of
a software system when the COTS component is functioning correctly
Built-in Testing

 Testability is incorporated into software components

 Testing and maintenance can be self-contained
 Normal mode
 The built-in test capabilities are transparent to the component user
 The component does not differ from other non-built-in testing enabled
components
 Maintenance mode
 The component user can test the component with the help of its built-in
testing features
 The component user can invoke the respective methods of the component,
which execute the test, evaluate autonomously its results, and output the test
summary
System Testing

 System Testing includes testing of a fully integrated software system.

 Generally, a computer system is made with the integration of software (any software is
only a single element of a computer system).
 The software is developed in units and then interfaced with other software and
hardware to create a complete computer system.
 In other words, a computer system consists of a group of software to perform the
various tasks,
 But only software cannot perform the task
 For that software must be interfaced with compatible hardware.
 System testing is a series of different type of tests with the purpose to exercise and
examine the full working of an integrated software computer system against
requirements.
System Testing
• System testing.is to check the end-to-end flow of
an application or the software as a user
• All the necessary modules of an application have to
be navigated
• Checks have to be made if the end features or the
end business works fine to test the product as a
whole system.
• System Testing is end-to-end testing where the
testing environment is similar to the production
environment.
 System Testing
 There are four levels of software testing:
 unit testing,
 integration testing,
 system testing and
 acceptance testing, all are used for the testing purpose.
 Unit Testing used to test a single software;
 Integration Testing used to test a group of units of software,
 System Testing used to test a whole system and Acceptance Testing used to test
the acceptability of business requirements .
System Testing

• There are mainly two widely used methods for

software testing
• One is White box testing which uses internal
coding to design test cases
• Another is black box testing which uses GUI or
user perspective to develop test cases.
 System Testing
 System testing falls under Black box testing as it includes testing of the external
working of the software.
 Testing follows user's perspective to identify minor defects.
 System Testing includes the following steps.
 Verification of input functions of the application to test whether it is
producing the expected output or not.
 Testing of integrated software by including external peripherals to check the
interaction of various components with each other.
 Testing of the whole system for End to End testing.
 Behavior testing of the application via a user's experience
 System Testing
 Types of System Testing
 System testing is divided into more than 50 types, but software testing companies typically uses some of them.
 These are listed below:

• Regression testing is performed under system testing to

confirm and identify that if there's any defect in the system
due to modification in any other part of the system.
• It makes sure, any changes done during the development
process have not introduced a new defect and also gives
assurance; old defects will not exist on the addition of new
software over the time.
For more information about regression testing refers to the
below link:
https://www.javatpoint.com/regression-testing
 System Testing
 Load Testing
 Load testing is performed under system testing to clarify whether the system can work under real-
time loads or not.
 Functional Testing
 Functional testing of a system is performed to find if there's any missing function in the system.
 Tester makes a list of vital functions that should be in the system and can be added during
functional testing and should improve quality of the system.
 Recovery Testing
 Recovery testing of a system is performed under system testing to confirm reliability,
trustworthiness, accountability of the system and all are lying on recouping skills of the system.
 It should be able to recover from all the possible system crashes successfully.
 This testing involves testing the application to check how well it recovers from the crashes or
disasters.
 System Testing
 Migration Testing
 Migration testing is performed to ensure that if the system needs to be
modified in new infrastructure so it should be modified without any
issue.
 Usability Testing
 The purpose of this testing to make sure that the system is well
familiar with the user and it meets its objective for what it supposed to
do.
 For more information about usability testing refers to the below link:
 https://www.javatpoint.com/usability-testing
 System Testing
 Software and Hardware Testing
 This testing of the system intends to check hardware and software compatibility.
 The hardware configuration must be compatible with the software to run it without any
issue.
 Compatibility provides flexibility by providing interactions between hardware and software.
 Why is System Testing Important?
 System Testing gives hundred percent assurance of system performance as it covers end to
end function of the system.
 It includes testing of System software architecture and business requirements.
 It helps in mitigating live issues and bugs even after production.
 System testing uses both existing system and a new system to feed same data in both and
then compare the differences in functionalities of added and existing functions so, the user
can understand benefits of new added functions of the system.
 Acceptance Testing
 Acceptance Testing is a method of software testing where a system is tested for
acceptability.
 The major aim of this test is to evaluate the compliance of the system with the
business requirements and assess whether it is acceptable for delivery or not.
 So, acceptance Testing is formal testing according to user needs, requirements, and
business processes conducted to determine whether a system satisfies the
acceptance criteria or not
 This enables the users, customers, or other authorized entities to determine whether
to accept the system or not.
 Acceptance Testing is the last phase of software testing performed after System
Testing and before making the system available for actual use.
 Types of Acceptance Testing

 User Acceptance Testing (UAT)

 User acceptance testing is used to determine whether the product is working for the user
correctly.
 Specific requirements which are quite often used by the customers are primarily picked
for testing purposes.
 This is also termed as End-User Testing.
 Business Acceptance Testing (BAT)
 BAT is used to determine whether the product meets the business goals and purposes or
not.
 BAT mainly focuses on business profits which are quite challenging due to the changing
market conditions and new technologies,
 So the current implementation may have to being changed which results in extra budgets
 Types of Acceptance Testing
 Contract Acceptance Testing (CAT)
 CAT is a contract that specifies that once the product goes live, within a predetermined
period, the acceptance test must be performed, and it should pass all the acceptance use
cases.
 Here is a contract termed a Service Level Agreement (SLA), which includes the terms
where the payment will be made only if the Product services are in-line with all the
requirements, which means the contract is fulfilled.
 Sometimes, this contract happens before the product goes live.
 There should be a well-defined contract in terms of the period of testing, areas of
testing, conditions on issues encountered at later stages, payments, etc.
 Types of Acceptance Testing
 Regulations Acceptance Testing (RAT)
 RAT is used to determine whether the product violates the rules and regulations that are defined by
the government of the country where it is being released.
 This may be unintentional but will impact negatively on the business.
 Generally, the product or application that is to be released in the market, has to go under RAT,
 Because different countries or regions have different rules and regulations defined by its governing
bodies.
 If any rules and regulations are violated for any country then that country or the specific region
then the product will not be released in that country or region.
 If the product is released even though there is a violation then only the vendors of the product will
be directly responsible.
 Types of Acceptance Testing
 Operational Acceptance Testing (OAT)
 OAT is used to determine the operational readiness of the product
 It is non-functional testing.
 It mainly includes testing of recovery, compatibility, maintainability, reliability, etc.
OAT assures the stability of the product before it is released to production.
 Alpha Testing
 Alpha testing is used to determine the product in the development testing
environment by a specialized testers team usually called alpha testers.
 Types of Acceptance Testing
 Beta Testing
 Beta testing is used to assess the product by exposing it to the real end-users,
typically called beta testers in their environment.
 Feedback is collected from the users and the defects are fixed. Also, this helps in
enhancing the product to give a rich user experience.
 Uses of Acceptance Testing
 To find the defects missed during the functional testing phase.
 How well the product is developed.
 A product is what actually the customers need.
 Feedback help in improving the product performance and user experience.
 Minimize or eliminate the issues arising from the production.
Acceptance Testing
 Acceptance Testing - In SDLC
 The following diagram explains the addition of acceptance testing in the software
development life cycle.
 Acceptance Testing
 The acceptance test cases are executed against the test data or using an
acceptance test script and then the results are compared with the expected ones.
 Acceptance Criteria
 Acceptance criteria are defined on the basis of the following attributes

• Functional Correctness and Completeness • Timeliness

• Data Integrity • Confidentiality and Availability
• Data Conversion • Installability and Upgradability
• Usability • Scalability
• Performance • Documentation
 Acceptance Testing
Acceptance Test Plan - Attributes
 The acceptance test activities are carried out in phases.
 Firstly, the basic tests are executed,
 If the test results are satisfactory then the execution of more complex scenarios are
carried out.
 The Acceptance test plan has the following attributes:

 Test Title
 Introduction
 Test Objective
 Acceptance Test Category
 Test Procedure
 Operation Environment
 Test Schedule
 Test case ID
 Resources
 Acceptance Testing
 The acceptance test activities are designed to reach at one of the conclusions
 Accept the system as delivered
 Accept the system after the requested modifications have been made
 Do not accept the system
 Acceptance Test Report - Attributes
 The Acceptance test Report has the following attributes
 Report Identifier
 Summary of Results
 Variations
 Recommendations
 Summary of To-DO List
 Approval Decision
 Types of Acceptance Testing
 Advantages of Acceptance Testing
 This testing helps the project team to know the further requirements from the users directly as it involves the
users for testing.
 Automated test execution.
 It brings confidence and satisfaction to the clients as they are directly involved in the testing process.
 It is easier for the user to describe their requirement.
 It covers only the Black-Box testing process and hence the entire functionality of the product will be tested.
 Disadvantages of Acceptance Testing
 Users should have basic knowledge about the product or application.
 Sometimes, users don’t want to participate in the testing process.
 The feedback for the testing takes a long time as it involves many users and the opinions may differ from one
user to another user.
 Development team is not participated in this testing process.
Unit-5 Topics
Legal, Ethical, and Professional Aspects of Testing
 Outline
 Legal, Ethical, and Professional Aspects of Testing
 The Ethical Software Tester
 Professional Responsibility of Software Tester
 ACM Code of Professional Conduct and Ethics
 Ethics is a practical branch of philosophy that deals with moral questions such as what is right or
wrong, and how a person should behave in a given situation in a complex world.
 Ethics explore what actions are right or wrong within a specific context or within a certain
society and seek to find satisfactory answers to moral questions.
 Cultural relativism argues that the particular society determines what is right or wrong based
upon its cultural values.
 Deontological ethics argues that there are moral laws to guide people in deciding what is right or
wrong.
 Utilitarianism which argues that an action is right if its overall affect is to produce more
happiness than unhappiness in society.
 Professional ethics are a code of conduct that governs how members of a profession deal with each other and with third
parties.
 A professional code of ethics expresses ideals of human behaviour, and it defines the fundamental principles of the
organization and is an indication of its professionalism.
 Business ethics define the core values of the business and are used to guide employee behaviour.
 Business ethics (also called corporate ethics) are concerned with ethical principles and moral problems that arise in a
business environment
 Business ethics refers to the core principles and values of the organization and apply throughout the organization.
 Business ethics guide individual employees in carrying out their roles and ethical issues include the rights and duties
between a company and its employees, customers, and suppliers.
 Human resource function in a company plays an important role in promoting ethics
and in putting internal HR policies in place relating to the ethical conduct of the
employees.
 Companies are expected to behave ethically and not exploit its workers.
 What is Computer Ethics?
 Computer ethics are a set of principles that guide the behaviour of individuals when using
computer resources.
 Several ethical issues that may arise include intellectual property rights, privacy concerns, and the
impacts of computer technology on wider society.
 Computer Ethics Institute (CEI) Ten commandments on computer ethics
1. Not use a computer to harm other people
2. Not interfere with other people’s computer work.
3. Not snoop around in other people’s computer files
4. Not use a computer to steal
5. Not use a computer to bear false witness
6. Not copy or use proprietary software for which you have not paid
7. Not use other people’s computer resources without authorization or proper compensation.
8. Not appropriate other people’s intellectual output
9. Think about the social consequences of the program you are writing or the system you are designing
10. Always use a computer in ways that ensure consideration and respect for your fellow humans
 The Ethical Software Tester
 Certified software testers shall act consistently in the public interest
 They shall act in the best interests of their client and employer
 Certified software testers shall ensure that their deliverables meet the highest professional standards
 They shall maintain independence and integrity in professional judgments
 Certified software test managers and leaders shall promote an ethical approach to the management of software testing
 They shall advance the integrity and reputation of the profession
 Certified software testers shall be supportive of their colleagues and promote cooperation with software developers
 They shall participate in lifelong learning regarding the practice of their profession and promote an ethical approach to the
practice of their profession.
Professional responsibilities of software engineers and testers

 Honesty and fairness in dealings with Clients

 Responsibility for actions
 Continuous learning to ensure appropriate knowledge to serve the client effectively
ACM Code of Professional Conduct and Ethics
ACM Code of Professional Conduct and Ethics
The End