Unit 4

Software Testing
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
under estimated.
• 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.
• Let us see the seven different testing principles, one by one:
1. Testing shows the presence of defects
2. Exhaustive Testing is not possible
3. Early Testing
4. Defect Clustering
5. Pesticide Paradox
6. Testing is context-dependent
7. Absence of errors fallacy
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.
• But at the time of deployment in the production server, if the end-user encounters those bugs
which are not found in the testing process.
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’s or the applications 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 known 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.
 Test process in software
development
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
• STUBS
 Drivers and Stubs

Module
Driver Stub
procedure Under Test procedure
call call

access to global
variables

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

 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
Bottom Up Integration Testing :

• In this Bottom Up approach the lower level modules are tested first
after lower level modules the higher level modules are tested.
• Then these modules undergo for integration accordingly.
• Here the lower level modules refers to sub modules and higher level
modules refers to main modules.
• This approach uses test drivers which are mainly used to initiate and
pass the required data to the sub modules means from higher level
module to lower level module if required.
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 Testing

• Top Down Integration testing which is also known as Incremental

integration testing.
• In this Top Down approach the higher level modules are tested first
after higher level modules the lower level modules are tested.
• Then these modules undergo for integration accordingly. Here the
higher level modules refers to main module and lower level modules
refers to sub modules.
• This approach uses Stubs which are mainly used to simulate the
submodule, if the invoked sub module is not developed this Stub
works as a momentary replacement.
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
• 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.
• This verification activity is equally important and may improve the quality of the final product.
• 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.
• 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.
System Testing Types
• Regression Testing
• Load Testing
• Smoke Testing
• Usability Testing
• Security Testing
• Performance Testing
• Stress Testing
System Testing: Regression Testing
• REGRESSION TESTING is a type of software testing that intends to ensure that changes
(enhancements or defect fixes) to the software have not adversely affected it. Rerunning of tests
can be on both functional and non-functional tests.
• Reasons for Regression Testing
The need for Regression Testing could arise due to any of the changes below:
i. Defect fix
ii. New feature
iii. Change in an existing feature
iv. Code refactoring
v. Change in technical design / architecture
vi. Change in configuration / environment (hardware, software, network)
Smoke Testing

• Smoke testing, also known as “Build Verification Testing” or “Build Acceptance Testing,” is a type of software
testing that is typically performed at the beginning of the development process to ensure that the most critical
functions of a software application are working correctly. It is used to quickly identify and fix any major issues
with the software before more detailed testing is performed. The goal of smoke testing is to determine whether
the build is stable enough to proceed with further testing.Smoke testing covers most of the major functions of
the software but none of them in depth.
• The result of this test is used to decide whether to proceed with further testing.
• If the smoke test passes, go ahead with further testing. If it fails, halt further tests and ask for a new build with
the required fixes.
• If an application is badly broken, detailed testing might be a waste of time and effort.
• Smoke test helps in exposing integration and major problems early in the cycle.
• It can be conducted on both newly created software and enhanced software.
• Smoke test is performed manually or with the help of automation tools/scripts. If builds are prepared
frequently, it is best to automate smoke testing.
Usability Testing
• USABILITY TESTING is a type of software testing done from an end-user’s perspective to
determine if the system is easily usable. It falls under non-functional testing.
• Usability Testing uses the Black Box Testing method where internal structure of the system is
unknown and is always executed manually because of the need for human interaction and
perception.
Security Testing
• SECURITY TESTING is a type of software testing that intends to uncover vulnerabilities of the
system and determine that its data and resources are protected from possible intruders. It is a
type of non-functional testing.
• There are four main focus areas to be considered in security testing (Especially for web
sites/applications):
• Network security: This involves looking for vulnerabilities in the network infrastructure
(resources and policies).
• System software security: This involves assessing weaknesses in the various software (operating
system, database system, and other software) the application depends on.
• Client-side application security: This deals with ensuring that the client (browser or any such
tool) cannot be manipulated.
• Server-side application security: This involves making sure that the server code and its
technologies are robust enough to fend off any intrusion.
Performance Testing
• PERFORMANCE TESTING is a type of software testing that intends to determine how a system
performs in terms of responsiveness and stability under a certain load. It is a type of non-
functional testing.
• Performance Testing mainly focuses on the following software quality attributes:
• Responsiveness: The ability of software to respond quickly or complete assigned tasks within a
reasonable time.
• Concurrency: The ability of software to service multiple requests to the same resources at the
same time.
• Reliability: The ability of software to perform a required function under stated conditions for the
stated period of time without any errors.
• Stability: The ability of software to remain stable under varying loads or over time.
• Scalability: The measure of software’s ability to increase or decrease in performance in response
to changes in software’s processing demands.
LOAD Testing
• Load testing is used to identify whether the infrastructure used for hosting the application
is sufficient or not
• It is used to find if the performance of the application is sustainable when it is at the peak of its
user load
• It tells us how many simultaneous users can the application handle and the scale of the
application required in terms of hardware, network capacity etc., so that more users could access
the application
• It helps to identify the maximum operating capacity of an application as well as
any bottlenecks and determine which element is causing degradation. E.g. If the number of
users are increased then how much CPU, memory will be consumed, what is the network and
bandwidth response time.
Stress Testing
• It is a type of non-functional testing
• It involves testing beyond normal operational capacity, often to a breaking point, in order to
observe the results
• It is a form of software testing that is used to determine the stability of a given system
• It put greater emphasis on robustness, availability and error handling under a heavy load, rather
than on what would be considered correct behavior under normal circumstances
• The goals of such tests may be to ensure the software does not crash in conditions of insufficient
computational resources (such as memory, disk space, network request etc)
• Stress testing is also called fatigue testing
• The main purpose of stress testing: Make sure that the system fails and recovers easily, this
quality is also known as recoverability.
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.
 Black-Box Testing Techniques

Following are main techniques to black-box testing.

• Equivalence Class Partitioning

• Boundary Value Analysis
• Cause-Effect Graphs.
 Equivalence Class Partitioning

• 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.
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.
 BOUNDARY VALUE ANALYSIS
• Focus on input values and design test cases with input values that are
on or close to boundary values.

• In boundary value analysis, we select values on or close to boundaries

and all input values may have one of the following:
(i) Minimum value
(ii) Just above minimum value
(iii) Maximum value
(iv) Just below maximum value
(v) Nominal (Average) value
• Suppose there is a program ‘Square’ which takes ‘x’ as an input and prints the square of ‘x’ as output.
The range of ‘x’ is from 1 to 100.
One possibility is to give all values from 1 to 100 one by one to the program and see the observed behavior.

There is no need to select all 100 inputs and execute the program one by
one for all 100 inputs.
The number of inputs selected by BVA technique is 4n + 1 where ‘n’ is
the number of inputs.
• Consider a program ‘Addition’ with two input values x and y and it gives the
addition of x and y as an output. The range of both input values are given as:
x ranges from 100 to 300
y ranges from 200 to 400

We also consider ‘single fault’ assumption theory of reliability which says that failures
are rarely the result of the simultaneous occurrence of two (or more) faults.
• Normally, one fault is responsible for one failure.
• With this theory in mind, we select one input value on boundary (minimum), just
above boundary (minimum +), just below boundary (maximum –), on boundary
(maximum), nominal (average) and other n-1 input values as nominal values.
Test Cases
 CAUSE-EFFECT GRAPHING TECHNIQUE

• For small programs

• Considers the combinations of various inputs which were not

available in earlier discussed techniques like boundary value

analysis and equivalence class testing.

• Two new terms are used here and these are causes and effects,

which are nothing but inputs and outputs respectively.

Steps for the generation of test cases
Identification of Causes and Effects
• The SRS document is used for the identification of causes and effects.
• Causes which are inputs to the program and effects which are outputs
of the program can easily be identified after reading the SRS
document.
• A list is prepared for all causes and effects.
 Design of Cause-Effect Graph
• The relationship amongst causes and effects are established using cause-effect graph. The
basic notations of the graph are

The purpose of four functions is given as:

(a) Identity: This function states that if c1 is 1, then e1 is 1; else e1 is 0.
(b) NOT: This function states that if c1 is 1, then e1 is 0; else e1 is 1.
(c) AND: This function states that if both c1 and c2 are 1, then e1 is 1; else e1 is 0.
(d) OR: This function states that if either c1 or c2 is 1, then e1 is 1; else e1 is 0.

The AND and OR functions are allowed to have any number of inputs.
 Design of Limited Entry Decision Table
• The cause-effect graph represents the relationships amongst the causes
and effects.
• This graph may also help us to understand the various
conditions/combinations amongst the causes and effects.
• These conditions/combinations are converted into the limited entry
decision table.
• Each column of the table represents a test case.
Writing of Test Cases
• Each column of the decision table represents a rule and gives us a test
case.
• We may reduce the number of columns with the proper selection of
various conditions and expected actions.
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.
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.
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.
1.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.

2.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.
Example
Let us take an example of a problem statement which says the first
column should have the value X or Y. The second column should hold
only digits. If both these conditions are satisfied, then a file should be
modified. If the first column does not hold the values either X or Y, then
the message M1 is generated. If the second column is fed with no
digits, then the message M2 is generated.

To solve this problem using a control flow graph, we would first

summarize the different conditions, and the events.
•Condition 1 denoted by C1 refers to column 1 holding value X.
•Condition 2 denoted by C2 refers to column 1 holding value Y.
•Condition 3 denoted by C3 refers to column 2 holding a digit.
•Effect 1 denoted by E1 refers to modification of a file. The effect E1 should come true for the condition →
(C1 V C2) /\ C3.
•Effect 2 denoted by E2 refers to the message M1.
•Effect 3 denoted by E3 refers to the message M2.
 White Box/Structural Testing
• Structural testing is considered more technical than
functional testing.
• It attempts to design test cases from the source code
and not from the specifications.
• The source code becomes the base document which is
examined thoroughly in order to understand the
internal structure and other implementation details.
• It also gives insight in to the source code which may
be used as an essential knowledge for the design of
test cases.
• Structural testing techniques are also known as
white box testing techniques due to consideration of
internal structure and other implementation details of
the program.
• Many structural testing techniques are available and
some of them are like control flow testing, data flow
testing, slice based testing and mutation testing.
 CONTROL FLOW TESTING
• This technique is very popular due to its simplicity and effectiveness.
We identify paths of the program and write test cases to execute
those paths.
• As we all know, path is a sequence of statements that begins at an
entry and ends at an exit.
• There may be too many paths in a program and it may not be feasible
to execute all of them.
• As the number of decisions increase in the program, the number of
paths also increase accordingly.
• Every path covers a portion of the program.
• We define ‘coverage’ as a ‘percentage of source code that has been
tested with respect to the total source code available for testing’.
• The most reasonable level may be to test every statement of a
program at least once before the completion of testing.
• We may write test cases that ensure the execution of every
statement.
If we stop testing without achieving this level (every statement
execution), we do unacceptable and intolerable activity which may
lead to dangerous results in future.
• Problem-01:
•
• Calculate cyclomatic complexity for the given code-

• IF A = 354
Cyclomatic Complexity
• THEN IF B > C
=P+1
• THEN A = B =2+1
=3
• ELSE A = C

• END IF

• END IF

• PRINT A
Problem-02:

Calculate cyclomatic complexity for the given code-

{ int i, j, k;
for (i=0 ; i<=N ; i++) Cyclomatic Complexity
p[i] = 1; =P+1
for (i=2 ; i<=N ; i++)
{ =3+1
k = p[i]; j=1; =4
while (a[p[j-1]] > a[k] {
p[j] = p[j-1];
j--;
}
p[j]=k;
}
Problem-03:

Calculate cyclomatic complexity for the given code-

begin int x, y, power;
float z;
input(x, y);
if(y<0) Cyclomatic Complexity
power = -y;
else power = y; = P + 1
z=1; =3+1
while(power!=0)
=4
{ z=z*x;
power=power-1;
} if(y<0)
z=1/z;
output(z);
end
 The cyclomatic complexity of this graph is:

• V(G) = e – n + 2P = 16 – 15 + 2 = 3 [e=
edges, n=nodes]
(P indicates number
of connected components)
• V(G) = no. of regions = 3
• V(G) =π + 1 = 2 + 1 = 3
 Independent Paths
• An independent path in a graph is a path that has at least one new
node or edge in its sequence from the initial node to its final node.
• If there is no repetition of an edge in a path from the initial node to
the final node, then the path is called a simple path.
• The number of edges in a path is called the length of the path.
Hence, independent paths are three and are given as:
(i) 1–7, 10, 13–15
(ii) 1–7, 10–15
(iii) 1–10, 13–15
And not 1-15
1. Statement Coverage

For a=9, b=8, c=7 All

statements are executed
and we have achieved
100% statement
coverage
by only one test case.
The total paths of this
program graph are given
as:
(i) 1–7, 10, 13–15
(ii) 1–7, 10–15
(iii) 1–10, 13–15
(iv) 1–15
2. Branch Coverage/ Decision Coverage
We wish to test every ‘True’ and ‘False’ condition of
the program.
If we select a = 9, b =8, c = 7
We achieve 100% statement coverage and the path
followed is given as (all true conditions):
Path = 1–15
We also want to select all false conditions with the
following inputs:
a = 7, b = 8, c = 9, the path followed is
Path = 1–7, 10, 13–15
These two test cases out of four are sufficient to
guarantee 100% branch coverage.
The branch coverage does not guarantee 100%
path coverage but it does guarantee 100%
statement coverage.
 3. Condition Coverage
Condition coverage is better than branch coverage because we want to test every
condition at least once.
However, branch coverage can be achieved without testing every condition.
For condition at Step 7
There are four possibilities
namely:
(i) Both are true
(ii) First is true, second is false
(iii) First is false, second is true
(iv) Both are false
• We should write test cases for
every true and false condition.
Selected inputs may be given as:
(i) a = 9, b = 8, c = 7 (first possibility
when both are true)
(ii) a = 9, b = 8, c = 10 (second
possibility – first is true, second is
false)
(iii) a = 7, b = 8, c = 9 (third and
fourth possibilities- first is false,
statement number 7 is false)
• Hence, these three test cases out
of four are sufficient to ensure the
execution of every condition of the
program.
 4. Path Coverage
Here, we want to test every path of the program.
• There are too many paths in any program due to
loops and feedback connections.
• It may not be possible to achieve this goal of
executing all paths in many programs.
• If we do so, we may be confident about the
correctness of the program. If it is unachievable,
at least all independent paths should be
executed.
• The program given in Figure has four paths as
given as:
(i) 1–7, 10, 13–15
(ii) 1–7, 10–15
(iii) 1–10, 13–15
 Some paths are possible from the
program graph, but become
impossible when we give inputs as per
logic of the program. Hence, some
combinations may be found to be
impossible to create.
• Path testing guarantee statement coverage, branch coverage and condition
coverage. However, there are many paths in any program and it may not be
possible to execute all the paths.
• We should do enough testing to achieve a reasonable level of coverage. We
should execute at least (minimum level) all independent paths which are
also referred to as basis paths to achieve reasonable coverage.
• These paths can be found using any method of cyclomatic complexity.
Statement Coverage
Goal: Execute every line of code at least once.
To get 100% statement coverage:
•We must pass through both if blocks (line 7 and 10).
•So, the inputs must satisfy both:
•(a > b) && (a > c)
•(b > c)
📌 Test Case:
a = 5, b = 3, c = 2
•a > b → ✅
•a > c → ✅
•b > c → ✅
Both conditions are true → all lines will execute at least once
→ ✅ 100% statement coverage.
✅ Branch Coverage
Goal: Each if condition’s true and false paths must be
tested.
There are 2 if statements:
1.if((a > b) && (a > c))
2.if(b > c)
To achieve 100% branch coverage, we need:
•One test where the first condition is true, and one where
it’s false
•One test where the second condition is true, and one
where it’s false
📌 Test Cases:
1.a = 5, b = 3, c = 2 → Both conditions are true ✅
2.a = 1, b = 2, c = 3 → Both are false ❌
3.a = 4, b = 2, c = 5 → (a > b) = true, but (a > c) =
false → 1st block false, check short-circuit ✅
4.a = 4, b = 6, c = 5 → 1st block false, 2nd block true ✅
With the above, we cover both true and false branches of
both conditions → ✅ 100% branch coverage
✅ Condition Coverage
Goal: Each individual condition in a compound
expression is evaluated as true and false at least once.
From line 7:
c
if((a > b) && (a > c))
Two conditions here:
1.a > b
2.a > c
We must ensure:
•a > b is both true and false
•a > c is both true and false
📌 Test Cases:
•a = 5, b = 3, c = 2 → both true ✅
•a = 2, b = 4, c = 1 → a > b = false, a > c = true ✅
•a = 3, b = 2, c = 5 → a > b = true, a > c = false ✅
•a = 1, b = 2, c = 3 → both false ✅
Now each individual condition has been true and false at
least once → ✅ 100% condition coverage
❗ Path Coverage
Goal: Cover all possible execution paths.
Let’s count them:
Paths:
1.Line 7 true, Line 10 true → x and y modified
2.Line 7 true, Line 10 false → only x modified
3.Line 7 false, Line 10 true → only y modified
4.Line 7 false, Line 10 false → neither x nor y
modified
📌 We need at least 4 test cases to cover these 4
execution paths.
So to achieve 100% path coverage:
•You need the same test cases that fulfill branch
coverage, but each unique combination of
true/false branches must be tested.
Static testing
• Static testing is the form of software testing where you
do not execute the code being examined.
• This technique could be called non-execution technique.
• It is primarily syntax checking of the code or manually
reviewing the code, requirements documents, design
documents etc. to find errors.
Static testing (Contd.)
• From the black box testing point of view, static testing
involves reviewing requirements and specifications.
• This is done with an eye toward completeness or
appropriateness for the task at hand.
• This is the verification portion of Verification and
Validation.
• The fundamental objective of static testing technique is to
improve the quality of the software products by finding
errors in early stages of software development life cycle.
Static testing (Contd.)
• Following are the main Static Testing techniques used:
• Formal Technical Reviews
• Walkthrough
• Code Inspection
 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.
• 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.
Code Inspection (Contd.)
• 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