Unit 4

SOFTWARE TESTING
Topics to cover
• Testing Objectives
• Unit Testing (Test Drivers and Test Stubs), Integration testing, Acceptance
testing, Regression Testing
• Testing for functionality and testing for performance.
• Top Down and Bottom up testing strategies:
• White Box testing /Structural Testing
• Functional Testing/Black Box Testing
• Test Data Suit preparation, Alpha and Beta testing of products.
• Static Testing Strategies:
• Formal technical Reviews (Peer reviews)
• Walk Through
• Code Inspection
• Compliance with Design and Coding standards.
What is Testing?
• “Testing is the process of executing a program with the intent of finding errors.”
• Testing a program consists of providing the program with a set of test inputs (or test cases) and
observing if the program behaves as expected.
• If the program fails to behave as expected, then the conditions under which failure occurs are
noted for later debugging and correction.
• Some commonly used terms associated with testing are:
i. Failure: This is a manifestation of an error (or defect or bug). But, the mere presence of an
error may not necessarily lead to a failure.
ii. Test case: This is the triplet [I,S,O], where I is the data input to the system, S is the state of the
system at which the data is input, and O is the expected output of the system.
iii. Test suite: This is the set of all test cases with which a given software product is to be tested.
Aim of testing
• The aim of the testing process is to identify all defects existing in a software product.
• It is not possible to guarantee that the software is error free.
• This is because the input data domain of most software products is very large. It is not practical to
test the software exhaustively with respect to each value that the input data may assume.
• Even with this practical limitation of the testing process, the importance of testing should not be
underestimated.
• Testing provides a practical way of reducing defects in a system and increasing the users’
confidence in a developed system.
Software Testing Principles
• Software testing is a procedure of implementing software or the application to identify the defects or
bugs.
• For testing an application or software, we need to follow some principles to make our product defects
free, and that also helps the test engineers to test the software with their effort and time.
Software Testing Principles: 1. Testing shows the
presence of defects

• The test engineer will test the application to make sure that the application is bug or defects free.
• While doing testing, we can only identify that the application or software has any errors.
• The primary purpose of doing testing is to identify the numbers of unknown bugs with the help of
various methods and testing techniques because the entire test should be traceable to the
customer requirement, which means that to find any defects that might cause the product failure
to meet the client's needs.
• By doing testing on any application, we can decrease the number of bugs, which does not mean
that the application is defect-free because sometimes the software seems to be bug-free while
performing multiple types of testing on it.
Software Testing Principles:
Exhaustive Testing is not possible
• Sometimes it seems to be very hard to test all the modules and their features with effective and
non- effective combinations of the inputs data throughout the actual testing process.
• Hence, instead of performing the exhaustive testing as it takes boundless determinations and
most of the hard work is unsuccessful.
• So we can complete this type of variations according to the importance of the modules because
the product timelines will not permit us to perform such type of testing scenarios.
Software Testing Principles: Early
Testing
• Here early testing means that all the testing activities should start in the early stages of the
software development life cycle's requirement analysis stage to identify the defects because if
we find the bugs at an early stage, it will be fixed in the initial stage itself, which may cost us very
less as compared to those which are identified in the future phase of the testing process.
• To perform testing, we will require the requirement specification documents; therefore, if the
requirements are defined incorrectly, then it can be fixed directly rather than fixing them in
another stage, which could be the development phase.
Software Testing Principles: Defect
clustering
• The defect clustering defined that throughout the testing process, we can detect the numbers of
bugs which are correlated to a small number of modules.
• We have various reasons for this, such as the modules could be complicated; the coding part may
be complex, and so on.
• These types of software or the application will follow the Pareto Principle, which states that we
can identify that approx.
• Eighty percent of the complication is present in 20 percent of the modules.
• With the help of this, we can find the uncertain modules, but this method has its difficulties if the
same tests are performing regularly, hence the same test will not able to identify the new defects.
Software Testing Principles: Pesticide
paradox
• This principle defined that if we are executing the same set of test cases again and again over a
particular time, then these kinds of the test will not be able to find the new bugs in the software
or the application.
• To get over these pesticide paradoxes, it is very significant to review all the test cases frequently.
• And the new and different tests are necessary to be written for the implementation of multiple
parts of the application or the software, which helps us to find more bugs.
Software Testing Principles: Testing
is context-dependent
• Testing is a context-dependent principle states that we have
multiple fields such as e-commerce websites, commercial
websites, and so on are available in the market.
• There is a definite way to test the commercial site as well as
the e-commerce websites because every application has its
own needs, features, and functionality.
• To check this type of application, we will take the help of
various kinds of testing, different technique, approaches,
and multiple methods. Therefore, the testing depends on
the context of the application.
Software Testing Principles: Absence
of errors fallacy
• Once the application is completely tested and there are no bugs identified before the release, so
we can say that the application is 99 percent bug-free.
• But there is the chance when the application is tested beside the incorrect requirements,
identified the flaws, and fixed them on a given period would not help as testing is done on the
wrong specification, which does not apply to the client's requirements.
• The absence of error fallacy means identifying and fixing the bugs would not help if the
application is impractical and not able to accomplish the client's requirements and needs.
Software Testing
• Software testing can be divided into two steps:
1. Verification: it refers to the set of tasks that ensure
that software correctly implements a specific function.
2. Validation: it refers to a different set of tasks that
ensure that the software that has been built is traceable
to customer requirements.
Verification: “Are we building the product right?”
Validation: “Are we building the right product?”
Methods of Software Testing

white-box black-box
methods methods

Methods

Strategies
Black-Box Testing
requirements Comparison

output

input events
 Black-Box Testing
• Black box design treats the system as a black-box.
• It is also known as Functional Testing, Behavioral Testing,
Data-Driven Testing, Input/Output driven Testing.
• Give input to the system, get the output, compare the
output with the specification, if it matches, then the
system is fine, otherwise error is there.
• Black-Box testing attempts to uncover the following
Incorrect functions
Missing functions
Performance errors
Initialization & Termination errors
External Database access errors.
White-Box Testing

AAAAAA
BBBBBB
CCCC
DDDDD

input
White-Box Testing
• Also known as Structural Testing, Clear-Box Testing, Open-
Box Testing, Logic-Driven Testing.
• Using White-Box testing methods, the software engineer
can derive test cases that.
Guarantee that all independent paths within a module have
been exercised at least once.
Exercise all logical decisions on their true and false sides.
Execute all loops at their boundaries and within their
operational bounds.
Exercise internal data structures to ensure their validity.

• white-box testing: the internal structure of the software is

taken into account to derive the test cases
Difference Between Black Box
Testing and White Box Testing
BLACK BOX TESTING WHITE BOX TESTING

Internal workings of an application are not

Knowledge of the internal workings is must.
required.

Also known as closed box/data driven testing. Also knwon as clear box/structural testing.

End users, testers and developers. Normally done by testers and developers.

THis can only be done by trial and error method. Data domains and internal boundaries can be
better tested.
 Software Testing Life Cycle

Refer this website: https://www.javatpoint.com/software-testing-life-cycle

Levels of Testing as per SDLC
V-model:
acceptance
requirements test

system
specification test

detailed integration
design test

implementation unit
code test
 Unit Testing
• Involves testing a single isolated module

• Note that unit testing allows us to isolate the errors to a single module
• we know that if we find an error during unit testing it is in the module
we are testing

• Modules in a program are not isolated, they interact with each other.
Possible interactions:
• calling procedures in other modules
• receiving procedure calls from other modules
• sharing variables

• For unit testing we need to isolate the module we want to test, we do this
using two things
• drivers and stubs
 Drivers and Stubs

Module
Driver Stub
procedure Under Test procedure
call call

access to global
variables

• Driver and Stub should have the same interface as the modules they replace

• Driver and Stub should be simpler than the modules they replace
 Drivers and Stubs
• Driver: A program that calls the interface procedures of the
module being tested and reports the results

• A driver simulates a module that calls the module currently

being tested

• Stub: A program that has the same interface as a module that is

being used by the module being tested, but is simpler.

• A stub simulates a module called by the module currently

being tested
Refer this link for more example of drivers and stubs : https://slideplayer.com/slide/9433412/
 Integration Testing
• The modules that may work properly and
independently may not work when they are
integrated.
• Integration Testing will test whether the
modules work well together.
• This will check whether the design is correct.
• Integration testing: Integrated collection of
modules tested as a group or partial system
• Integration plan specifies the order in which to
combine modules into partial systems
• Different approaches to integration testing
• Bottom-up
• Top-down
• Big-bang
• Sandwich
 Module Structure
A B
• We assume that
This is required hierarchy and is
a directed acyclic graph.
• If there are cycles merge
D them to a single module

level 1 C H

level 0 E F G I

• A uses C and D; B uses D; C uses E and F; D uses F, G, H and I; H uses I

• Modules A and B are at level 3; Module D is at level 2
Modules C and H are at level 1; Modules E, F, G, I are at level 0
• level 0 components do not use any other components
• level i components use at least one component on level i-1 and no
component at a level higher than i-1
 Bottom-Up Integration
• Modules at lower levels are tested using the previously tested
higher level modules

• Non-terminal modules are not tested in isolation

• Requires a module driver for each module to feed the test case
input to the interface of the module being tested
• However, stubs are not needed since we are starting with the
terminal modules and use already tested modules when
testing modules in the lower levels
Bottom-up Integration

A B

C H

E F G I
 Top-down Integration
• Only modules tested in isolation are the modules which are at
the highest level

• After a module is tested, the modules directly called by that

module are merged with the already tested module and the
combination is tested

• Requires stub modules to simulate the functions of the missing

modules that may be called
• However, drivers are not needed since we are starting with
the modules which is not used by any other module and use
already tested modules when testing modules in the higher
levels
Top-down Integration

A B

C
H

E F G I
 Other Approaches to
Integration
• Sandwich Integration
• Compromise between bottom-up and top-down testing
• Simultaneously begin bottom-up and top-down testing and meet at a
predetermined point in the middle
• Instead of completely going for top down or bottom up, a layer is
identified in between.
• Above this layer we go for top down and below this layer bottom up.

• Big Bang Integration

• Every module is unit tested in isolation
• After all of the modules are tested they are all integrated together at once
and tested
• No driver or stub is needed
• However, in this approach, it may be hard to isolate the bugs!
System Testing(Non-functional testing are
included in this only)
• At the system testing level, the system is tested as a whole, and primarily functional testing
techniques are used to test the system.
• System testing ensures that each system function works as expected and it also tests for non-
functional requirements like performance, security, reliability, stress, load, etc.
• This is the only phase of testing which tests both functional and non-functional requirements of
the system. A team of the testing persons does the system testing under the supervision of a test
team leader. We also review all associated documents and manuals of the software.
• A proper impact analysis should be done before fixing the defect. Sometimes, if the system
permits, instead of fixing the defects, they are just documented and mentioned as the known
limitations.
• This may happen in a situation when fixing is very time consuming or technically it is not possible
in the present design, etc.
• Progress of system testing also builds confidence in the development team as this is the first phase
in which the complete product is tested with a specific focus on the customer’s expectations. After
the completion of this phase, customers are invited to test the software.
Non- Functional Testing Types
• Performance Testing
• Load Testing
• Scalability Testing
• Stability Testing
• Stress Testing
• Usability Testing
• Compatibility Testing
Load Testing
• While executing the performance testing, we will apply some load on
the particular application to check the application's performance,
known as load testing. Here, the load could be less than or equal to
the desired load.
• It will help us to detect the highest operating volume of the software
and bottlenecks.
Stress Testing
• It is used to analyze the user-friendliness and robustness of the
software beyond the common functional limits.
• Primarily, stress testing is used for critical software, but it can also be
used for all types of software applications.
Scalability Testing
• To analysis, the application's performance by enhancing or reducing
the load in particular balances is known as scalability testing.
• In scalability testing, we can also check the system, processes, or
database's ability to meet an upward need. And in this, the Test
Cases are designed and implemented efficiently.
Stability Testing
• Stability testing is a procedure where we evaluate the application's
performance by applying the load for a precise time.
• It mainly checks the constancy problems of the application and the
efficiency of a developed product. In this type of testing, we can
rapidly find the system's defect even in a stressful situation.
Usability Testing
• Another type of non-functional testing is usability testing. In usability
testing, we will analyze the user-friendliness of an application and
detect the bugs in the software's end-user interface.
• Here, the term user-friendliness defines the following aspects of an
application:
• The application should be easy to understand, which means that all the
features must be visible to end-users.
• The application's look and feel should be good that means the application
should be pleasant looking and make a feel to the end-user to use it.
Compatibility Testing
• In compatibility testing, we will check the functionality of an
application in specific hardware and software environments. Once the
application is functionally stable then only, we go for compatibility
testing.
• Here, software means we can test the application on the different
operating systems and other browsers, and hardware means we can
test the application on different sizes.
 Some other types of Software
Testing
• In software testing, we also have some other types of testing that are not part
of any above discussed testing, but those testing are required while testing any
software or an application.
• In smoke testing, we will test an application's basic and critical
features before doing one round of deep and rigorous testing.
• Or before checking all possible positive and negative values is known
as smoke testing. Analyzing the workflow of the application's core
and main functions is the main objective of performing the smoke
testing.

• Sanity Testing
• It is used to ensure that all the bugs have been fixed and no added
issues come into existence due to these changes. Sanity testing is
unscripted, which means we cannot document it. It checks the
correctness of the newly added features and components.
Regression Testing
• Regression testing is the most commonly used type of software testing. Here,
the term regression implies that we have to re-test those parts of an
unaffected application.
• Regression testing is the most suitable testing for automation tools. As per the
project type and accessibility of resources, regression testing can be similar
to Retesting.
• Whenever a bug is fixed by the developers and then testing the other features
of the applications that might be simulated because of the bug fixing is known
as regression testing.
• In other words, we can say that whenever there is a new release for some
project, then we can perform Regression Testing, and due to a new feature
may affect the old features in the earlier releases.
Exploratory Testing
• Whenever the requirement is missing, early iteration is required, and
the testing team has experienced testers when we have a critical
application. New test engineer entered into the team then we go for
the exploratory testing.
• To execute the exploratory testing, we will first go through the
application in all possible ways, make a test document, understand
the flow of the application, and then test the application.
Adhoc Testing
• Testing the application randomly as soon as the build is in the checked
sequence is known as Adhoc testing.
• It is also called Monkey testing and Gorilla testing. In Adhoc testing,
we will check the application in contradiction of the client's
requirements; that's why it is also known as negative testing.
• When the end-user using the application casually, and he/she may
detect a bug. Still, the specialized test engineer uses the software
thoroughly, so he/she may not identify a similar detection.
• Security Testing
• It is an essential part of software testing, used to determine the
weakness, risks, or threats in the software application.
• The execution of security testing will help us to avoid the nasty
attack from outsiders and ensure our software applications'
security.
• In other words, we can say that security testing is mainly used to
define that the data will be safe and endure the software's working
process.
• Globalization Testing
• It is used to check the developed software supports multiple
languages and multiple features in all languages.
• In present scenarios, we can see the enhancement in several
technologies as the applications are prepared to be used globally.
User Acceptance Testing

• Acceptance Testing is done by the customer to test whether the

system is meeting the requirements
• Acceptance Testing is of two types
Alpha Testing
Beta Testing
Acceptance Testing
Alpha Testing –
The Alpha test is conducted in the developer’s environment by the
end-users. The environment might be simulated, with the developer
and the typical end-user present for the testing. The end-user uses
the software and records the errors and problems. Alpha test is
conducted in a controlled environment.
Acceptance Testing
Beta Testing –
The Beta test is conducted in the end-user’s environment. The
developer is not present for the beta testing. The beta testing is
always in the real-world environment which is not controlled by the
developer. The end-user records the problems and reports it back to
the developer at intervals. Based on the results of the beta testing the
software is made ready for the final release to the intended customer
base.
Static and Dynamic Testing
• Software testing is a process of analyzing or operating software for the
purpose of finding bugs.
• Test activities that are associated with analyzing the products of software
development are called static testing.
• Static testing includes code inspections, walkthroughs, and desk checks.
• Test activities that involve operating the software are called dynamic
testing.
• Methodologies for dynamic testing are unit testing, integration testing, system
testing & acceptance testing.
• Static and dynamic testing complement to one another and each type has a
unique approach to detecting bugs.
• Static testing is a system of White Box testing where developers verify or
check code to find fault. This type of testing is completed without executing
the applications that are currently developed. Dynamic Testing is completed
by walking the real application with valid entries to verify the expected
results.
Difference between Static testing
and Dynamic Testing:
• Static testing is about prevention whereas dynamic testing is about cure.
• Static testing is more cost-effective than dynamic testing.
• Static testing tools provide greater marginal benefits as compare to dynamic testing.
• Static testing gives comprehensive diagnostics for code than dynamic testing.
• Dynamic testing finds fewer bugs as compare to static testing.
• Dynamic testing usually takes longer time as compare to static testing as it test each
case separately.
• Static testing covers more areas than dynamic testing in shorter time.
• Static testing is done before the code deployment whereas dynamic testing is after the
code deployment.
• Static testing is done in verification stage whereas dynamic testing is done in validation
stage.
• In static testing code is being examined without being executed whereas In dynamic
testing, code is being executed and tested without necessarily being examined.
Static Testing Techniques

• Static testing techniques offer a great way to enhance the quality and
efficiency of software development. The Static testing technique can
be done in two ways, which are as follows:
• Review
• Static Analysis
• Review
• In static testing, the review is a technique or a process implemented to find
the possible bugs in the application. We can easily identify and eliminate
faults and defects in the various supporting documents such as SRS [Software
Requirements Specifications] in the review process.
• In other words, we can say that a review in Static Testing is that where all the
team members will understand about the project's progress.
Static Analysis
• Another Static Testing technique is static analysis, which is used to contain
the assessment of the code quality, which is established by developers.
• We can use the different tools to perform the code's analysis and
evaluation of the same.
• In other words, we can say that developers' developed code is analyzed
with some tools for structural bugs, which might cause the defects.
• The static analysis will also help us to identify the below errors:
• Dead code
• Unused variables
• Endless loops
• Incorrect syntax
• Variable with undefined value
 Formal Technical
Reviews
• Formal Technical Reviews are conducted by software engineers.
• The primary objective is to find errors during the process so that they do not
become defects after release of software as they uncover errors in function, logic
design, or implementation.
• The idea is to have early discovery of errors so they do not propagate to the next
step in the process.
• They also ensure that the software has been represented according to predefined
standards and it is developed in a uniform manner.
• They make projects more manageable and help groom new resources as well as
provide backup and continuity.
 Formal Technical Reviews
(Contd.)
• FTRs are usually conducted in a meeting that is successful only if it
is properly planned, controlled.
• The producer informs the Project Manager that the Work Product
is ready and the review is needed.
• The review meeting consists of 3-5 people and advanced
preparation is required.
• It is important that this preparation should not require more than 2
hours of work per person.
• It should focus on specific (and small) part of the overall software.
• For example, instead of the entire design, walkthroughs are
conducted for each component, or small group of components. By
narrowing focus, FTR has a high probability of uncovering errors.
Formal Technical Reviews (Contd.)
• It is important to remember that the focus is on a work
product (WP) for which the producer of the WP asks the
project leader for review.
• Project leader informs the review leader.
• The review leader evaluates the WP for readiness and if
satisfied generates copies of review material and
distributes to reviewers for advanced preparation.
Formal Technical Reviews Review
Meetings (Contd.)
• Review meeting (RM) is attended by the review leader, all reviewers, and the
producer.
• One of the reviewer takes the roles of recorder.
• Producer walks through the product, explaining the material while other
reviewers raise issues based upon their advanced preparation.
• When valid problems or errors are recorded, the recorder notes each one of
them.
• At the end of the RM, all attendees of the meeting must decide whether to:
Accept the product without further modification
Formal Technical Reviews Review
Meetings (Contd.)
• Reject the product due to severe errors
– Major errors identified
– Must review again after fixing
• Accept the product provisionally
– Minor errors to be fixed
– No further review
Formal Technical Reviews
Review Reporting and Record
keeping(Contd.)
• During the FTR the recorder notes all the issues.
• They are summarized at the end and a review issue list is prepared.
• A summary report is produced that includes:
• What is reviewed
• Who reviewed it
• What were the findings and conclusions
• It then becomes part of project historical record.
 Formal Technical Reviews
(Contd.)
The review issue list
• It is sometimes very useful to have a proper review issue list. It has two objectives.
• Identify problem areas within the WP Action item checklist
• It is important to establish a follow-up procedure to ensure that items on the issue list
have been properly addressed.
Review Guidelines
• It is essential to note that an uncontrolled review can be worse than no review.
• The basis principle is that the review should focus on the product and not the
producer so that it does not become personal.
• Errors should be pointed out gently and the tone should be loose and constructive.
Walkthrough

• A walkthrough is a term describing the consideration of a process at an abstract

level.
• The term is often employed in the software industry (see software walkthrough)
to describe the process of inspecting algorithms and source code by following
paths through the algorithms or code as determined by input conditions and
choices made along the way.
• The purpose of such code walkthroughs is generally to provide assurance of the
fitness for purpose of the algorithm or code; and occasionally to assess the
competence or output of an individual or team.
Guidelines of Walkthrough
• The team performing code walk through should not be either too big or too
small.
• Ideally, it should consist of between three to seven members.
• Discussion should focus on discovery of errors and not on how to fix the
discovered errors.
• In order to foster cooperation and to avoid the feeling among engineers that they
are being evaluated in the code walk through meeting, managers should not
attend the walk through meetings.
Code Inspection
• The aim of code inspection is to discover some common types of errors caused
due to oversight and improper programming.
• During code inspection the code is examined for the presence of certain kinds of
errors, in contrast to the hand simulation of code execution done in code walk
throughs.
• For instance, consider the classical error of writing a procedure that modifies a
formal parameter while the calling routine calls that procedure with a constant
actual parameter Errors.
Code Inspection (Contd.)
• It is more likely that such an error will be discovered by looking for these kinds of
mistakes in the code, rather than by simply hand simulating execution of the
procedure.
• In addition to the commonly made errors, adherence to coding standards is also
checked during code inspection.
• Good software development companies collect statistics regarding different types
of errors commonly committed by their engineers and identify the type of errors
most frequently committed.
• Such a list of commonly committed errors can be used during code inspection to
look out for possible
Code Inspection (Contd.)
• Following is a list of some classical programming errors which can be checked
during code inspection:
• Use of un-initialized variables.
• Jumps into loops.
• Non-terminating loops.
• Incompatible assignments.
• Array indices out of bounds.
• Improper storage allocation and de-allocation.
• Mismatches between actual and formal parameter in procedure calls.
• Use of incorrect logical operators or incorrect precedence among operators.
• Improper modification of loop variables.
• Comparison of equally of floating point variables, etc.
Coding
• The goal of coding phase is to translate the design of the system into code in a
given programming language, which can be executed by a computer and that
performs the computation specified by the design.
• A coding standard lists several rules to be followed during coding, such as the way
variables are to be named, the way the code is to be laid out, error return
conventions, etc.
• A coding standard gives a uniform appearance to the codes written by different
engineers.
• It enhances code understanding.
• It encourages good programming practices.
Importance of Good Programming
Style

To simplify software maintenance

To avoid problems
To simplify the testing process.
To achieve readability.
To improve modifiability
To improve transportability
To make a robust product
Coding standards and guidelines
• Rules for limiting the use of global: These rules list what types of data can be
declared global and what cannot.
• Contents of the headers preceding codes for different modules: The following
are some standard header data:
• Name of the module.
• Date on which the module was created.
• Author’s name.
• Modification history.
• Synopsis of the module.
• Different functions supported, along with their input/output parameters.
• Global variables accessed/modified by the module.
Coding standards and guidelines
• Naming conventions for global variables, local variables, and constant
identifiers: A possible naming convention can be that global variable names
always start with a capital letter, local variable names are made of small letters,
and constant names are always capital letters.
• Error return conventions and exception handling mechanisms: The way error
conditions are reported by different functions in a program are handled should be
standard within an organization.
Coding standards and guidelines: Recommended by SW
Development Organization

• Do not use a coding style that is too clever or too difficult to understand
• Do not use an identifier for multiple purposes
• The code should be well-documented
• The length of any function should not exceed 10 source lines
• Do not use goto statements
• Do not do hard coding
Techniques to perform Testing
• Black Box Testing • White Box Testing
• Boundary Value Analysis • Coverage metrics
• Equivalence class testing • Statement coverage: all statements in
• Cause Effect Graphing Technique the programs should be executed at
least once
• Decision Table Based Testing
• Branch coverage: all branches in the
program should be executed at least
once
• Path coverage: all execution paths in
the program should be executed at lest
once
• The best case would be to execute
all paths through the code
 Equivalence Class Partitioning
• Equivalence partitioning (EP) is a specification-based or black-box technique.
• It can be applied at any level of testing and is often a good technique to use
first.
• The idea behind this technique is to divide (i.e. to partition) a set of test
conditions into groups or sets that can be considered the same (i.e. the system
should handle them equivalently), hence ‘equivalence
partitioning’. Equivalence partitions are also known as equivalence classes –
the two terms mean exactly the same thing.
• In equivalence-partitioning technique we need to test only one condition from
each partition.
• This is because we are assuming that all the conditions in one partition
will be treated in the same way by the software.
• If one condition in a partition works, we assume all of the conditions in
that partition will work, and so there is little point in testing any of these
others.
• Similarly, if one of the conditions in a partition does not work, then we
assume that none of the conditions in that partition will work so again
there is little point in testing any more in that partition.
Guidelines for Equivalence Class
Partitioning
• If the range condition is given as an input, then one valid and two invalid equivalence classes are defined.
• If a specific value is given as input, then one valid and two invalid equivalence classes are defined.
• If a member of set is given as an input, then one valid and one invalid equivalence class is defined.
• If Boolean no. is given as an input condition, then one valid and one invalid equivalence class is defined.
Equivalence Class Partitioning
(Contd.)
• If testing is done for an input box accepting numbers
from 1 to 1000 then there is no use in writing
thousand test cases for all 1000 valid input numbers
plus other test cases for invalid data.
• Using equivalence partitioning method above test
cases can be divided into three sets of input data
called as classes. Each test case is a representative of
respective class.
• So in above example we can divide our test cases into
three equivalence classes of some valid and invalid
inputs.
Equivalence Class Partitioning
(Contd.)
• Test cases for input box accepting numbers between 1 and
1000 using Equivalence Partitioning:
1) One input data class with all valid inputs. Pick a single value
from range 1 to 1000 as a valid test case. If you select other
values between 1 and 1000 then result is going to be same. So
one test case for valid input data should be sufficient.
2) Input data class with all values below lower limit. I.e. any
value below 1, as a invalid input data test case.
3) Input data with any value greater than 1000 to represent third
invalid input class.
• So using equivalence partitioning you have categorized all possible
test cases into three classes. Test cases with other values from any
class should give you the same result.
 Equivalence Class Partitioning (Contd.)
• Let us consider an example of an online shopping site. In this site, each of products has specific
product ID and product name. We can search for product either by using name of product or by
product ID. Here, we consider search field that accepts only valid product ID or product name.
• Let us consider set of products with product IDs and user want to search for Mobiles. Below is table
of some products with their product Id.

• If the product ID entered by user is invalid then application will redirect customer or user to error
page. If product ID entered by user is valid i.e. 45 for mobile, then equivalence partitioning method
will show a valid product ID.
Boundary Value Analysis
• It’s widely recognized that input values at the extreme ends of input domain
cause more errors in system.
• More application errors occur at the boundaries of input domain.
• ‘Boundary value analysis’ testing technique is used to identify errors at
boundaries rather than finding those exist in center of input domain.
• Boundary value analysis is a next part of Equivalence partitioning for designing
test cases where test cases are selected at the edges of the equivalence classes.
Boundary Value Analysis
(Contd.)
• Test cases for input box accepting numbers between
1 and 1000 using Boundary value analysis:
1) Test cases with test data exactly as the input
boundaries of input domain i.e. values 1 and 1000 in
our case.
2) Test data with values just below the extreme edges
of input domains i.e. values 0 and 999.
3) Test data with values just above the extreme edges
of input domain i.e. values 2 and 1001.
• Boundary value analysis is often called as a part of stress and
negative testing.
 Boundary Value Analysis

• For each range [R1, R2] listed in either the input or

output specifications, choose five cases: R1 R2
• Values less than R1
• Values equal to R1
• Values greater than R1 but less than R2
• Values equal to R2
• Values greater than R2
Cause-Effect Graphs
• This is basically a hardware testing technique adapted to software
testing.
• It considers only the desired external behaviour of a system.
• This is a testing technique that aids in selecting test cases that
logically relate Causes (inputs) to Effects (outputs) to produce test
cases.
• A “Cause” represents a distinct input condition that brings about an
internal change in the system.
Cause-Effect Graphs (Contd.)
• An “Effect” represents an output condition, a system transformation or a state
resulting from a combination of causes.
• According to Myer Cause & Effect Graphing is done through the following steps:
• Step – 1: For a module, identify the input conditions (causes) and actions (effect).
• Step – 2: Develop a cause-effect graph.
• Step – 3: Transform cause-effect graph into a decision table.
• Step – 4: Convert decision table rules to test cases. Each column of the decision
table represents a test case.
Cause-Effect Graphs (Contd.)
• Basic symbols used in Cause-effect graphs are as under:
Cause-Effect Graphs (Contd.)
• Consider each node as having the value 0 or 1 where 0 represents the 'absent
state' and 1 represents the 'present state'.
• Then the identity function states that if c1 is 1, e1 is 1 or we can say if c0 is 0, e0 is
0.
• The NOT function states that if C1 is 1, e1 is 0 and vice-versa. Similarly, OR
function states that if C1 or C2 or C3 is 1, e1 is 1 else e1 is 0.
• The AND function states that if both C, and C2 are 1, e1 is 1; else e1 is 0.
• The AND and OR functions are allowed to have any number of inputs.
 Cause-Effect Graphs (Contd.)
EXAMPLE:
The character in column1 must be A or B. The character in column 2 must be a digit. If these 2 hold
then file update is made. if the character in column1 is incorrect, message x is issued. If character in
column2 is not a digit, message y is issued.

Causes are
c1: character in column1 is A
c2: character in column1 is B
c3: character in column2 is a digit

Effects are:
Cause-Effect Graphs (Contd.)
Cause-Effect Graphs (Contd.)
Cause-Effect Graphs (Contd.)
Coverage Metrics: White Box Testing Techniques

• Coverage metrics
• Statement coverage: all statements in the programs should
be executed at least once
• Branch coverage: all branches in the program should be
executed at least once
• Path coverage: all execution paths in the program should
be executed at least once
• The best case would be to execute all paths through
the code
Read P
Read Q
IF P+Q > 100 THEN
Print “Large”
ENDIF
If P > 50 THEN
Print “P Large”
ENDIF
Statement Coverage (SC):
To calculate Statement Coverage, find out the shortest number of paths following which all the
nodes will be covered. Here by traversing through path 1A-2C-3D-E-4G-5H all the nodes are
covered. So by traveling through only one path all the nodes 12345 are covered, so the Statement
coverage in this case is 1.
Branch Coverage (BC):
To calculate Branch Coverage, find out the minimum number of paths which will ensure covering
of all the edges. In this case there is no single path which will ensure coverage of all the edges at
one go. By following paths 1A-2C-3D-E-4G-5H, maximum numbers of edges (A, C, D, E, G and H)
are covered but edges B and F are left. To covers these edges we can follow 1A-2B-E-4F. By the
combining the above two paths we can ensure of traveling through all the paths. Hence Branch
Coverage is 2. The aim is to cover all possible true/false decisions.
Path Coverage (PC):
Path Coverage ensures covering of all the paths from start to end.
All possible paths are-
1A-2B-E-4F
1A-2B-E-4G-5H
1A-2C-3D-E-4G-5H
1A-2C-3D-E-4F
So path coverage is 4.
Thus for the above example SC=1, BC=2 and PC=4.
 Statement Coverage

areTheyPositive(int x, int y) Following test set will give us statement

{ coverage:
if (x >= 0) T1 = {(x=12,y=5), (x=1,y=35),
print(“x is positive”); (x=115,y=13),(x=91,y=2)}
else
print(“x is negative”); There are smaller test cases which will
if (y >= 0) give us statement coverage too:
print(“y is positive”); T2 = {(x=12,y=5), (x=1,y=35)}
else
print(“y is negative”);
There is a difference between these two
}
test sets though
 Control Flow Graphs (CFGs)
• Nodes in the control flow graph are basic blocks
• A basic block is a sequence of statements always entered at the beginning
of the block and exited at the end
• Edges in the control flow graph represent the control flow

if (x < y) { B0 (x < y)
x = 5 * y; Y N
x = x + 3;
} x = 5 * y B1 B2 y = 5
else x = x + 3
y = 5;
x = x+y;

x = x+y B3

• Each block has a sequence of statements

• No jump from or to the middle of the block
• Once a block starts executing, it will execute till the end
 Branch Coverage
• Construct the control flow graph

• Select a test set T such that by executing program P for each test case
d in T, each edge of P’s control flow graph is traversed at least once

B0
(x < 0)

true false
B1 Test set {x=1} does not
x := -x execute this edge, hence, it
does not give branch coverage

Test set {x=1, x=2}gives

B2 both statement and branch
z := x coverage
 Statement vs. Branch
Coverage
assignAbsolute(int x)
{ Consider this program segment, the test set
if (x < 0) T = {x = 1} will give statement coverage,
x := -x; however not branch coverage
z := x;
}
B0
Control Flow Graph: (x < 0)
true false
B1 Test set {x = 1} does not
x := -x execute this edge, hence, it
does not give branch coverage

B2
z := x
 Path Coverage
• Select a test set T such that by executing program P for
each test case d in T, all paths leading from the initial to
the final node of P’s control flow graph are traversed
 Path Coverage
B0
areTheyPositive(int x, int y)
(x >= 0)
{
if (x >= 0) true false
print(“x is positive”); B1 B2
else print(“x is p”) print(“x is n”)
print(“x is negative”);
if (y >= 0)
print(“y is positive”); B3
else (y >= 0)
print(“y is negative”); true false
} B4 B5
Test set: print(“y is p”) print(“y is n”)
T2 = {(x = 12,y =  5), (x =  1,y = 35)}
gives both branch and statement B6
coverage but it does not give path coverage
return
Set of all execution paths: {(B0,B1,B3,B4,B6), (B0,B1,B3,B5,B6), (B0,B2,B3,B4,B6),
(B0,B2,B3,B5,B6)}
Test set T2 executes only paths: (B0,B1,B3,B5,B6) and (B0,B2,B3,B4,B6)
 Path Coverage
B0
areTheyPositive(int x, int y)
(x >= 0)
{
if (x >= 0) true false
print(“x is positive”); B1 B2
else print(“x is p”) print(“x is n”)
print(“x is negative”);
if (y >= 0) B3
print(“y is positive”);
else (y >= 0)
print(“y is negative”); true false
} B4 B5
print(“y is p”) print(“y is n”)
Test set:
T1 = {(x=12,y=5), (x=1,y=35),
B6
(x=115,y=13),(x=91,y=2)}
return
gives both branch, statement and path
coverage
Cyclomatic Complexity
• 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 second command might immediately follow the first
command.
• 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
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
Cyclomatic Complexity
A = 10
IF B > C THEN
A=B
ELSE
A=C
ENDIF
Print A
Print B
Print C
Cyclomatic Complexity
Cyclomatic Complexity
• The cyclomatic complexity calculated for above code
will be from control flow graph. The graph shows seven
shapes(nodes), seven lines(edges), hence cyclomatic
complexity is 7-7+2 = 2.
Cyclomatic
Complexity