Unit -4

Software Testing: Testing Objectives, Unit Testing, Integration Testing, Acceptance

Testing, Regression Testing, Testing for Functionality and Testing for Performance,
TopDown and BottomUp Testing Strategies: Test Drivers and Test Stubs, Structural
Testing (White Box 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.

Software Testing

Testing is the process of evaluating a system or its component(s) with the intent
to find whether it satisfies the specified requirements or not. In simple words,
testing is executing a system in order to identify any gaps, errors, or missing
requirements in contrary to the actual requirements.

According to ANSI/IEEE 1059 standard, Testing can be defined as - A process

of analyzing a software item to detect the differences between existing and
required conditions (that is defects/errors/bugs) and to evaluate the features of the
software item.

Testing Objective:
The main objectives and purposes of software testing are to
• Find defects in the software product that may have occurred during the
development of the software due to human error.
• Gain confidence and conclude the quality of the software developed.
• Prevent future defects from occurring.
• Identify the errors, faults, or missing requirements in contrast to actual
requirements.
• Measure the specification, functionality, and performance of a software
program or application.

Software Testing - Types of Testing

Manual Testing

Manual testing includes testing a software manually, i.e., without using any
automated tool or any script. In this type, the tester takes over the role of an end-
user and tests the software to identify any unexpected behavior or bug. There are
different stages for manual testing such as unit testing, integration testing, system
testing, and user acceptance testing.
Testers use test plans, test cases, or test scenarios to test a software to ensure the
completeness of testing. Manual testing also includes exploratory testing, as
testers explore the software to identify errors in it.

Automation Testing

Automation testing, which is also known as Test Automation, is when the tester
writes scripts and uses another software to test the product. This process involves
automation of a manual process. Automation Testing is used to re-run the test
scenarios that were performed manually, quickly, and repeatedly.

Software Testing – Methods

There are different methods that can be used for software testing
Black-Box Testing

The technique of testing without having any knowledge of the interior workings
of the application is called black-box testing. The tester is oblivious to the system
architecture and does not have access to the source code. Typically, while
performing a black-box test, a tester will interact with the system's user interface
by providing inputs and examining outputs without knowing how and where the
inputs are worked upon.

The following table lists the advantages and disadvantages of black-box testing.

Advantages Disadvantages
Limited coverage, since only a
Well suited and efficient for large code selected number of test
segments. scenarios is actually
performed.

Inefficient testing, due to the

fact that the tester only has
Code access is not required.
limited knowledge about an
application.
Clearly separates user's perspective from Blind coverage, since the tester
the developer's perspective through visibly cannot target specific code
defined roles. segments or error prone areas.

Large numbers of moderately skilled The test cases are difficult to

testers can test the application with no design.
 knowledge of implementation,
programming language, or operating
systems.
White-Box Testing

White-box testing is the detailed investigation of internal logic and structure of

the code. White-box testing is also called glass testing or open-box testing. In
order to perform white-box testing on an application, a tester needs to know the
internal workings of the code.

The tester needs to have a look inside the source code and find out which
unit/chunk of the code is behaving inappropriately.

The following table lists the advantages and disadvantages of white-box testing.

Advantages Disadvantages

As the tester has knowledge of the

source code, it becomes very easy Due to the fact that a skilled tester is
to find out which type of data can needed to perform white-box testing,
help in testing the application the costs are increased.
effectively.

Sometimes it is impossible to look

into every nook and corner to find out
It helps in optimizing the code. hidden errors that may create
problems, as many paths will go
untested.

It is difficult to maintain white-box

Extra lines of code can be removed testing, as it requires specialized tools
which can bring in hidden defects. like code analyzers and debugging
tools.

Due to the tester's knowledge about

the code, maximum coverage is
attained during test scenario
writing.
Grey-Box Testing

Grey-box testing is a technique to test the application with having a limited

knowledge of the internal workings of an application. In software testing, the
phrase the more you know, the better carries a lot of weight while testing an
application.

Mastering the domain of a system always gives the tester an edge over someone
with limited domain knowledge. Unlike black-box testing, where the tester only
tests the application's user interface; in grey-box testing, the tester has access to
design documents and the database. Having this knowledge, a tester can prepare
better test data and test scenarios while making a test plan.

Advantages Disadvantages

Since the access to source code is

Offers combined benefits of black-
not available, the ability to go over
box and white-box testing wherever
the code and test coverage is
possible.
limited.

Grey box testers don't rely on the

The tests can be redundant if the
source code; instead, they rely on
software designer has already run a
interface definition and functional
test case.
specifications.

Based on the limited information Testing every possible input stream

available, a grey-box tester can is unrealistic because it would take
design excellent test scenarios an unreasonable amount of time;
especially around communication therefore, many program paths will
protocols and data type handling. go untested.
The test is done from the point of
view of the user and not the
designer.
A Comparison of Testing Methods

The following table lists the points that differentiate black-box testing, grey-box
testing, and white-box testing.
 Black-Box Testing Grey-Box Testing White-Box Testing

The tester has limited Tester has full

The internal workings
knowledge of the knowledge of the
of an application need
internal workings of the internal workings of
not be known.
application. the application.

Also known as
Also known as closed- translucent testing, as Also known as clear-
box testing, data-driven the tester has limited box testing, structural
testing, or functional knowledge of the testing, or code-based
testing. insides of the testing.
application.

Performed by end-users Performed by end-users Normally done by

and also by testers and and also by testers and testers and
developers. developers. developers.

Testing is based on
Testing is done on the Internal workings are
external expectations -
basis of high-level fully known and the
Internal behaviour of
database diagrams and tester can design test
the application is
data flow diagrams. data accordingly.
unknown.

The most exhaustive

It is exhaustive and the Partly time-consuming
and time-consuming
least time-consuming. and exhaustive.
type of testing.

Not suited for Not suited for algorithm Suited for algorithm
algorithm testing. testing. testing.

This can only be done Data domains and Data domains and
by trial-and-error internal boundaries can internal boundaries
method. be tested, if known. can be better tested.
 Software Testing - Levels

Levels of testing include different methodologies that can be used while

conducting software testing. The main levels of software testing are −

• Functional Testing
• Non-functional Testing
Functional Testing

This is a type of black-box testing that is based on the specifications of the

software that is to be tested. The application is tested by providing input and then
the results are examined that need to conform to the functionality it was intended
for. Functional testing of a software is conducted on a complete, integrated
system to evaluate the system's compliance with its specified requirements.

There are five steps that are involved while testing an application for
functionality.

Steps Description

The determination of the functionality that the intended application

I
is meant to perform.

The creation of test data based on the specifications of the

II
application.

The output based on the test data and the specifications of the
III
application.

IV The writing of test scenarios and the execution of test cases.

The comparison of actual and expected results based on the

V
executed test cases.

An effective testing practice will see the above steps applied to the testing policies
of every organization and hence it will make sure that the organization maintains
the strictest of standards when it comes to software quality.
Unit Testing

This type of testing is performed by developers before the setup is handed over
to the testing team to formally execute the test cases. Unit testing is performed by
the respective developers on the individual units of source code assigned areas.
The developers use test data that is different from the test data of the quality
assurance team.

The goal of unit testing is to isolate each part of the program and show that
individual parts are correct in terms of requirements and functionality.

Limitations of Unit Testing

Testing cannot catch each and every bug in an application. It is impossible to

evaluate every execution path in every software application. The same is the case
with unit testing.

There is a limit to the number of scenarios and test data that a developer can use
to verify a source code. After having exhausted all the options, there is no choice
but to stop unit testing and merge the code segment with other units.

Integration Testing

Integration testing is defined as the testing of combined parts of an application to

determine if they function correctly. Integration testing can be done in two ways:
Bottom-up integration testing and Top-down integration testing.

Integration Testing Method

Bottom-up integration
1 This testing begins with unit testing, followed by tests of progressively
higher-level combinations of units called modules or builds.

Top-down integration
2 In this testing, the highest-level modules are tested first and
progressively, lower-level modules are tested thereafter.

In a comprehensive software development environment, bottom-up testing is

usually done first, followed by top-down testing. The process concludes with
multiple tests of the complete application, preferably in scenarios designed to
mimic actual situations.
Stubs and Drivers:

The Stubs and Drivers are considered as elements which are equivalent
to to-do modules that could be replaced if modules are in their
developing stage, missing or not developed yet, so that necessity of such
modules could be met. Drivers and stubs simulate features and
functionalities, and have ability to serve features that a module can
provide. This reduces useless delay in testing and makes the testing
process faster.
Stubs are mainly used in Top-Down integration testing while the Drivers
are used in Bottom-up integration testing, thus increasing the efficiency of
testing process.
1.Stubs:
Stubs are developed by software developers to use them in place of
modules, if the respective modules aren’t developed, missing in
developing stage, or are unavailable currently while Top-down testing of
modules. A Stub simulates module which has all the capabilities of the
unavailable module. Stubs are used when the lower-level modules are
needed but are unavailable currently.
Stubs are divided into four basic categories based on what they do :
• Shows the traced messages,
• Shows the displayed message if any,
• Returns the corresponding values that are utilized by modules,
• Returns the value of the chosen parameters(arguments) that
were used by the testing modules.
2.Drivers:
Drivers serve the same purpose as stubs, but drivers are used in Bottom-
up integration testing and are also more complex than stubs. Drivers are
also used when some modules are missing and unavailable at time of
testing of a specific module because of some unavoidable reasons, to act
in absence of required module. Drivers are used when high-level modules
are missing and can also be used when lower-level modules are missing.
Ex : Suppose, you are told to test a website whose corresponding primary
modules are, where each of them is interdependent on each other, as
follows:
• Module-A : Login page website,
• Module-B : Home page of the website
 • Module-C : Profile setting
• Module-D : Sign-out page
It’s always considered good practice to begin development of all modules
parallelly because as soon as each gets developed they can be integrated
and could be tested further as per their corresponding interdependencies
order with a module. But in some cases, if any one of them is in developing
stage or not available in the testing process of a specific module, stubs or
drivers could be used instead.
Assume Module-A is developed. As soon as it’s developed, it undergoes
testing, but it requires Module-B, which isn’t developed yet. So in this
case, we can use the Stubs or Drivers that simulate all features and
functionality that might be shown by actual Module-B. So, we can
conclude that Stubs and drivers are used to fulfill the necessity of
unavailable modules. Similarly, we may also use Stubs or Drivers in place
of Module-C and Module-D if they are too not available.
Do both drivers and Stubs serve the same functionality?
Yes, we can say both serve the same feature and are used in the absence
of a module (M1) that has interdependencies with an
other module(M2) that is need to be test, so we use drivers or stubs in
order to fulfill module(M1)’s unavailability’s and to serve its functionality.
Difference between Stubs and Drivers :

S.No. Stubs Drivers

Stubs are used in Top-Down Drivers are used in Bottom-Up

1.
Integration Testing. Integration Testing.

Stubs are basically known as a “called While, drivers are the “calling
2. programs” and are used in the Top- program” and are used in bottom-up
down integration testing. integration testing.

Stubs are similar to the modules of the While drivers are used to invoking
3. software, that are under development the component that needs to be
process. tested.

While drivers are mainly used in

Stubs are basically used in the place of high-level modules and in
4.
unavailability of low-level modules. some situation as well as for low-
level modules.

Stubs are taken into use to test the Whereas the drivers are used if the
5. feature and functionality of the main module of the software isn’t
modules. developed for testing.

The drivers are taken into concern if

The stubs are taken into concern if
testing of lower-levels of the
testing of upper-levels of the modules
6. modules are done and the upper-
are done and the lower-levels of the
levels of the modules are under
modules are under developing process.
developing process.

Stubs are used when lower-level of Drivers are used when higher-level
modules are missing or in a partially of modules are missing or in a
7.
developed phase, and we want to test partially developed phase, and we
the main module. want to test the lower(sub)- module.
System Testing

System testing tests the system as a whole. Once all the components are
integrated, the application as a whole is tested rigorously to see that it meets the
specified Quality Standards. This type of testing is performed by a specialized
testing team.

System testing is important because of the following reasons −

• System testing is the first step in the Software Development Life Cycle,
where the application is tested as a whole.
• The application is tested thoroughly to verify that it meets the functional
and technical specifications.
• The application is tested in an environment that is very close to the
production environment where the application will be deployed.
• System testing enables us to test, verify, and validate both the business
requirements as well as the application architecture.
Regression Testing

Whenever a change in a software application is made, it is quite possible that

other areas within the application have been affected by this change. Regression
testing is performed to verify that a fixed bug hasn't resulted in another
functionality or business rule violation. The intent of regression testing is to
ensure that a change, such as a bug fix should not result in another fault being
uncovered in the application.

Regression testing is important because of the following reasons −

• Minimize the gaps in testing when an application with changes made has
to be tested.
• Testing the new changes to verify that the changes made did not affect any
other area of the application.
• Mitigates risks when regression testing is performed on the application.
• Test coverage is increased without compromising timelines.
• Increase speed to market the product.
Acceptance Testing

This is arguably the most important type of testing, as it is conducted by the

Quality Assurance Team who will gauge whether the application meets the
intended specifications and satisfies the client’s requirement. The QA team will
have a set of pre-written scenarios and test cases that will be used to test the
application.
More ideas will be shared about the application and more tests can be performed
on it to gauge its accuracy and the reasons why the project was initiated.
Acceptance tests are not only intended to point out simple spelling mistakes,
cosmetic errors, or interface gaps, but also to point out any bugs in the application
that will result in system crashes or major errors in the application.

By performing acceptance tests on an application, the testing team will reduce

how the application will perform in production. There are also legal and
contractual requirements for acceptance of the system.

Alpha Testing

This test is the first stage of testing and will be performed amongst the teams
(developer and QA teams). Unit testing, integration testing and system testing
when combined together is known as alpha testing. During this phase, the
following aspects will be tested in the application −

• Spelling Mistakes
• Broken Links
• Cloudy Directions
• The Application will be tested on machines with the lowest specification
to test loading times and any latency problems.
Beta Testing

This test is performed after alpha testing has been successfully performed. In beta
testing, a sample of the intended audience tests the application. Beta testing is
also known as pre-release testing. Beta test versions of software are ideally
distributed to a wide audience on the Web, partly to give the program a "real-
world" test and partly to provide a preview of the next release. In this phase, the
audience will be testing the following −

• Users will install, run the application and send their feedback to the project
team.
• Typographical errors, confusing application flow, and even crashes.
• Getting the feedback, the project team can fix the problems before
releasing the software to the actual users.
• The more issues you fix that solve real user problems, the higher the quality
of your application will be.
• Having a higher-quality application when you release it to the general
public will increase customer satisfaction.
Non-Functional Testing

This section is based upon testing an application from its non-functional

attributes. Non-functional testing involves testing a software from the
requirements which are nonfunctional in nature but important such as
performance, security, user interface, etc.

Some of the important and commonly used non-functional testing types are
discussed below.

Performance Testing

It is mostly used to identify any bottlenecks or performance issues rather than

finding bugs in a software. There are different causes that contribute in lowering
the performance of a software −

• Network delay
• Client-side processing
• Database transaction processing
• Load balancing between servers
• Data rendering

Performance testing is considered as one of the important and mandatory testing

type in terms of the following aspects −

• Speed (i.e. Response Time, data rendering and accessing)

• Capacity
• Stability
• Scalability

Performance testing can be either qualitative or quantitative and can be divided

into different sub-types such as Load testing and Stress testing.

Load Testing

It is a process of testing the behavior of a software by applying maximum load in

terms of software accessing and manipulating large input data. It can be done at
both normal and peak load conditions. This type of testing identifies the
maximum capacity of software and its behavior at peak time.

Most of the time, load testing is performed with the help of automated tools such
as Load Runner, AppLoader, IBM Rational Performance Tester, Apache JMeter,
Silk Performer, Visual Studio Load Test, etc.
Virtual users (VUsers) are defined in the automated testing tool and the script is
executed to verify the load testing for the software. The number of users can be
increased or decreased concurrently or incrementally based upon the
requirements.

Stress Testing

Stress testing includes testing the behavior of a software under abnormal

conditions. For example, it may include taking away some resources or applying
a load beyond the actual load limit.

The aim of stress testing is to test the software by applying the load to the system
and taking over the resources used by the software to identify the breaking point.
This testing can be performed by testing different scenarios such as −

• Shutdown or restart of network ports randomly

• Turning the database on or off
• Running different processes that consume resources such as CPU,
memory, server, etc.
Usability Testing

Usability testing is a black-box technique and is used to identify any error(s) and
improvements in the software by observing the users through their usage and
operation.

According to Nielsen, usability can be defined in terms of five factors, i.e.

efficiency of use, learn-ability, memory-ability, errors/safety, and satisfaction.
According to him, the usability of a product will be good and the system is usable
if it possesses the above factors.

Nigel Bevan and Macleod considered that usability is the quality requirement that
can be measured as the outcome of interactions with a computer system. This
requirement can be fulfilled and the end-user will be satisfied if the intended goals
are achieved effectively with the use of proper resources.

Molich in 2000 stated that a user-friendly system should fulfill the following five
goals, i.e., easy to Learn, easy to remember, efficient to use, satisfactory to use,
and easy to understand.

In addition to the different definitions of usability, there are some standards and
quality models and methods that define usability in the form of attributes and sub-
attributes such as ISO-9126, ISO-9241-11, ISO-13407, and IEEE std.610.12, etc.
UI vs Usability Testing

UI testing involves testing the Graphical User Interface of the Software. UI

testing ensures that the GUI functions according to the requirements and tested
in terms of color, alignment, size, and other properties.

On the other hand, usability testing ensures a good and user-friendly GUI that can
be easily handled. UI testing can be considered as a sub-part of usability testing.

Security Testing

Security testing involves testing a software in order to identify any flaws and gaps
from security and vulnerability point of view. Listed below are the main aspects
that security testing should ensure −

• Confidentiality
• Integrity
• Authentication
• Availability
• Authorization
• Non-repudiation
• Software is secure against known and unknown vulnerabilities
• Software data is secure
• Software is according to all security regulations
• Input checking and validation
• SQL insertion attacks
• Injection flaws
• Session management issues
• Cross-site scripting attacks
• Buffer overflows vulnerabilities
• Directory traversal attacks
Portability Testing

Portability testing includes testing a software with the aim to ensure its reusability
and that it can be moved from another software as well. Following are the
strategies that can be used for portability testing −

• Transferring an installed software from one computer to another.

• Building executable (.exe) to run the software on different platforms.

Portability testing can be considered as one of the sub-parts of system testing, as

this testing type includes overall testing of a software with respect to its usage
over different environments. Computer hardware, operating systems, and
browsers are the major focus of portability testing. Some of the pre-conditions
for portability testing are as follows −

• Software should be designed and coded, keeping in mind the portability

requirements.
• Unit testing has been performed on the associated components.
• Integration testing has been performed.
• Test environment has been established.

Boundary Value Analysis

Boundary Value Analysis is based on testing the boundary values of

valid and invalid partitions. The behavior at the edge of the equivalence
partition is more likely to be incorrect than the behavior within the
partition, so boundaries are an area where testing is likely to yield
defects.
It checks for the input values near the boundary that have a higher
chance of error. Every partition has its maximum and minimum values
and these maximum and minimum values are the boundary values of a
partition.
Note:
A boundary value for a valid partition is a valid boundary value.
•
• A boundary value for an invalid partition is an invalid boundary
value.
• For each variable we check-
• Minimum value.
• Just above the minimum.
• Nominal Value.
• Just below Max value.
• Max value.
Example: Consider a system that accepts ages from 18 to 56.
Boundary Value Analysis(Age accepts 18 to 56)

Invalid Valid Invalid

(min-1) (min, min + 1, nominal, max – 1, max) (max + 1)
 Boundary Value Analysis(Age accepts 18 to 56)

17 18, 19, 37, 55, 56 57

Valid Test cases: Valid test cases for the above can be any value entered
greater than 17 and less than 57.
• Enter the value- 18.
• Enter the value- 19.
• Enter the value- 37.
• Enter the value- 55.
• Enter the value- 56.
Invalid Testcases: When any value less than 18 and greater than 56 is
entered.
• Enter the value- 17.
• Enter the value- 57.
Single Fault Assumption: When more than one variable for the same
application is checked then one can use a single fault assumption.
Holding all but one variable to the extreme value and allowing the
remaining variable to take the extreme value. For n variable to be
checked:
Maximum of 4n+1 test cases
Problem: Consider a Program for determining the Previous Data.
Input: Day, Month, Year with valid ranges as-
1 ≤ Month≤12
1 ≤ Day ≤31
1900 ≤ Year ≤ 2000
Design Boundary Value Test Cases.
Solution: Taking the year as a Single Fault Assumption i.e. year will be
having values varying from 1900 to 2000 and others will have nominal
values.
Test Cases Month Day Year Output

1 6 15 1990 14 June 1990

2 6 15 1901 14 June 1901

Test Cases Month Day Year Output

3 6 15 1960 14 June 1960

4 6 15 1999 14 June 1999

5 6 15 2000 14 June 2000

Taking Day as Single Fault Assumption i.e. Day will be having values
varying from 1 to 31 and others will have nominal values.

Test Case Month Day Year Output

6 6 1 1960 31 May 1960

7 6 2 1960 1 June 1960

8 6 30 1960 29 June 1960

9 6 31 1960 Invalid day

Taking Month as Single Fault Assumption i.e. Month will be having

values varying from 1 to 12 and others will have nominal values.

Test Case Month Day Year Output

10 1 15 1960 14 Jan 1960

11 2 15 1960 14 Feb 1960

12 11 15 1960 14 Nov 1960

13 12 15 1960 14 Dec 1960

For the n variable to be checked Maximum of 4n + 1 test case will be

required. Therefore, for n = 3, the maximum test cases are-
4 × 3 + 1 =13
The focus of BVA: BVA focuses on the input variable of the function.
Let’s define two variables X1 and X2, where X1 lies between a and b and
X2 lies between c and d.

Showing legitimate domain

The idea and motivation behind BVA are that errors tend to occur near
the extremes of the variables. The defect on the boundary value can be
the result of countless possibilities.

Equivalence Partitioning Method

Equivalence Partitioning Method is also known as Equivalence class
partitioning (ECP). It is a software testing technique or black-box
testing that divides input domain into classes of data, and with the help
of these classes of data, test cases can be derived. An ideal test case
identifies class of error that might require many arbitrary test cases to be
executed before general error is observed.
In equivalence partitioning, equivalence classes are evaluated for given
input conditions. Whenever any input is given, then type of input
condition is checked, then for this input conditions, Equivalence class
represents or describes set of valid or invalid states.
Guidelines for Equivalence 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.

Example-1:
Let us consider an example of any college admission process. There is a
college that gives admissions to students based upon their percentage.
Consider percentage field that will accept percentage only between 50
to 90 %, more and even less than not be accepted, and application will
redirect user to an error page. If percentage entered by user is less than
50 %or more than 90 %, that equivalence partitioning method will show
an invalid percentage. If percentage entered is between 50 to 90 %, then
equivalence partitioning method will show valid percentage.
Example 2:
Let us consider an example of an online shopping site. In this site, each of
products has a 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 a set of products with product IDs and users wants to
search for Mobiles. Below is a table of some products with their product
Id.

Product Product ID

Mobiles 45

Laptops 54

Pen Drives 67

Keyboard 76

Headphones 34
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.

Example-3 :
Let us consider an example of software application. There is function of
software application that accepts only particular number of digits, not
even greater or less than that particular number.
Consider an OTP number that contains only 6 digit number, greater and
even less than six digits will not be accepted, and the application will
redirect customer or user to error page. If password entered by user is
less or more than six characters, that equivalence partitioning method
will show an invalid OTP. If password entered is exactly six characters,
then equivalence partitioning method will show valid OTP.
Example 4:
Consider the program for the determination of nature of roots of a quadratic equation as.
Identify the equivalence class test cases for output and input domains.
Output domain equivalence class test cases can be identified as follows:
Cause Effect Graphing based technique is a technique in which a graph
is used to represent the situations of combinations of input conditions.
The graph is then converted to a decision table to obtain the test cases.
Cause-effect graphing technique is used because boundary value
analysis and equivalence class partitioning methods do not consider the
combinations of input conditions. But since there may be some critical
behaviour to be tested when some combinations of input conditions are
considered, that is why cause-effect graphing technique is used.
Steps used in deriving test cases using this technique are:
1. Division of specification:
Since it is difficult to work with cause-effect graphs of large
specifications as they are complex, the specifications are divided
into small workable pieces and then converted into cause-effect
graphs separately.
2. Identification of cause and effects:
This involves identifying the causes(distinct input conditions)
and effects(output conditions) in the specification.
3. Transforming the specifications into a cause-effect graph:
The causes and effects are linked together using Boolean
expressions to obtain a cause-effect graph. Constraints are also
added between causes and effects if possible.
4. Conversion into decision table:
The cause-effect graph is then converted into a limited entry
 decision table. If you’re not aware of the concept of decision
tables, check out this link.
5. Deriving test cases:
Each column of the decision-table is converted into a test case.
Basic Notations used in Cause-effect graph:
Here c represents cause and e represents effect.
The following notations are always used between a cause and an effect:
1. Identity Function: if c is 1, then e is 1. Else e is 0.

2. NOT Function: if c is 1, then e is 0. Else e is 1.

3. OR Function: if c1 or c2 or c3 is 1, then e is 1. Else e is 0.

 4. AND Function: if both c1 and c2 and c3 is 1, then e is 1. Else e is
0.

To represent some impossible combinations of causes or impossible

combinations of effects, constraints are used. The
following constraints are used in cause-effect graphs:
1. Exclusive constraint or E-constraint: This constraint exists
between causes. It states that either c1 or c2 can be 1, i.e., c1
and c2 cannot be 1 simultaneously.

2. Inclusive constraint or I-constraint: This constraint exists

between causes. It states that atleast one of c1, c2 and c3 must
always be 1, i.e., c1, c2 and c3 cannot be 0 simultaneously.
 3. One and Only One constraint or O-constraint: This constraint
exists between causes. It states that one and only one of c1 and
c2 must be 1.

4. Requires constraint or R-constraint: This constraint exists

between causes. It states that for c1 to be 1, c2 must be 1. It is
impossible for c1 to be 1 and c2 to be 0.

5. Mask constraint or M-constraint: This constraint exists between

effects. It states that if effect e1 is 1, the effect e2 is forced to be
0.

Myers explained this effectively with following example. “The characters in

column 1 must be an A or B. The character in column 2 must be a digit. In this
situation, the file update is made. If the character in column 1 is incorrect,
message x is issued. If the character in column 2 is not a digit, message y is
issued”. The causes are
c1: character in column 1 is A
c2: character in column 1 is B
c3: character in column 2 is a digit and the effects are
e1: update made
e2: message x is issued
e3: message y is issued

Sample cause effect graph

Sample cause effect graph with exclusive constraint

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
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