Unit - 3 Software Testing

White Box Testing

WHITE BOX TESTING (also known as Clear Box Testing, Open Box Testing, Glass Box Testing,
Transparent Box Testing, Code-Based Testing or Structural Testing) is a software testing
method in which the internal structure/design/implementation of the item being tested is
known to the tester. The tester chooses inputs to exercise paths through the code and
determines the appropriate outputs. Programming know-how and the implementation
knowledge is essential. White box testing is testing beyond the user interface and into the nitty-
gritty of a system.
This method is named so because the software program, in the eyes of the tester, is like a
white/transparent box; inside which one clearly sees.
Definition by ISTQB
 white-box testing: Testing based on an analysis of the internal structure of the
component or system.
 white-box test design technique: Procedure to derive and/or select test cases based on
an analysis of the internal structure of a component or system.
Example
A tester, usually a developer as well, studies the implementation code of a certain field on a
webpage, determines all legal (valid and invalid) AND illegal inputs and verifies the outputs
against the expected outcomes, which is also determined by studying the implementation code.
White Box Testing is like the work of a mechanic who examines the engine to see why the car is
not moving.
Levels Applicable To
White Box Testing method is applicable to the following levels of software testing:
 Unit Testing: For testing paths within a unit.
 Integration Testing: For testing paths between units.
 System Testing: For testing paths between subsystems.
However, it is mainly applied to Unit Testing.
Advantages
  Testing can be commenced at an earlier stage. One need not wait for the GUI to be
available.
 Testing is more thorough, with the possibility of covering most paths.
Disadvantages
 Since tests can be very complex, highly skilled resources are required, with a thorough
knowledge of programming and implementation.
 Test script maintenance can be a burden if the implementation changes too frequently.
 Since this method of testing is closely tied to the application being tested, tools to cater
to every kind of implementation/platform may not be readily available.
White Box Testing is contrasted with Black Box Testing. Read the Differences between Black Box
Testing and White Box Testing.

Difference between Black Box testing and White Box testing

Parameter Black Box testing White Box testing

Definition It is a testing approach which is used to test the It is a testing approach in which
software without the knowledge of the internal internal structure is known to the
structure of program or application. tester.

Alias It also knowns as data-driven, box testing, data-, and It is also called structural testing, clear
functional testing. box testing, code-based testing, or
glass box testing.

Base of Testing Testing is based on external expectations; internal Internal working is known, and the
behavior of the application is unknown. tester can test accordingly.

Usage This type of testing is ideal for higher levels of testing Testing is best suited for a lower level
like System Testing, Acceptance testing. of testing like Unit Testing, Integration
testing.

Programming Programming knowledge is not needed to perform Programming knowledge is required

knowledge Black Box testing. to perform White Box testing.

Implementation Implementation knowledge is not requiring doing Complete understanding needs to

Parameter Black Box testing White Box testing

knowledge Black Box testing. implement WhiteBox testing.

Automation Test and programmer are dependent on each other, White Box testing is easy to automate.
so it is tough to automate.

Objective The main objective of this testing is to check what The main objective of White Box
functionality of the system under test. testing is done to check the quality of
the code.

Basis for test cases Testing can start after preparing requirement Testing can start after preparing for
specification document. Detail design document.

Tested by Performed by the end user, developer, and tester. Usually done by tester and
developers.

Granularity Granularity is low. Granularity is high.

Testing method It is based on trial and error method. Data domain and internal boundaries
can be tested.

Time It is less exhaustive and time-consuming. Exhaustive and time-consuming

method.

Algorithm test Not the best method for algorithm testing. Best suited for algorithm testing.

Code Access Code access is not required for Black Box Testing. White box testing requires code
access. Thereby, the code could be
stolen if testing is outsourced.

Benefit Well suited and efficient for large code segments. It allows removing the extra lines of
code, which can bring in hidden
defects.

Skill level Low skilled testers can test the application with no Need an expert tester with vast
knowledge of the implementation of programming experience to perform white box
language or operating system. testing.

Techniques Equivalence partitioning is Black box testing technique Statement Coverage, Branch
is used for Blackbox testing. coverage, and Path coverage are
Parameter Black Box testing White Box testing

White Box testing technique.

Equivalence partitioning divides input values into valid
and invalid partitions and selecting corresponding Statement Coverage validates
values from each partition of the test data. whether every line of the code is
executed at least once.
Boundary value analysis
Branch coverage validates whether
checks boundaries for input values. each branch is executed at least once

Path coverage method tests all the

paths of the program.

Drawbacks Update to automation test script is essential if you to Automated test cases can become
modify application frequently. useless if the code base is rapidly
changing.

Static Testing is a form of software testing where the actual program or application is not used.
This testing method requires programmers to manually read their own code to find
any errors. Static testing is a stage of White Box Testing and is also called Dry Run Testing.
In Static Testing code is not executed. It can be done manually or by a set of tools. It does not
need computer as the testing of program is done without executing the program. For
example: reviewing, walk through, inspection, etc. This type of testing checks the code,
requirement documents and design documents and puts review comments on the work
document.
The purpose of Static testing is to improve the quality of the software by finding out the errors,
code flaws and potentially malicious code in the software application. It starts earlier in
development life cycle and hence it is also called Verification Testing. Static testing can be done
on work documents like requirement specifications, design documents, source code, test plans,
test scripts and test cases, web page content. It is a continuous activity and not done just by
testers.

Dynamic Testing is a kind of software testing technique by using which the dynamic behavior of
the code is analyzed. Dynamic testing is done when the code is in operation mode. And is
performed in run time environment. It is a method of assessing the feasibility of a software
program by giving input and examining output. Dynamic testing is the Validation part of
Verification and Validation process.
Dynamic testing refers to the examination of the physical response from the system to variables
that are not constant and change with time. In dynamic testing the software must actually be
compiled and run. It is a method of assessing the feasibility of a software program by giving
input and examining output and checking if the output is as expected. This is done by executing
specific test caseswhich can be done test manually or with the use of an automated
process. Unit tests, integration tests, system tests and acceptance tests utilize dynamic testing.
The main aim of the Dynamic tests is to ensure that software works properly during and after
the installation of the software ensuring a stable application without any major flaws.
Static Testing Techniques:
 Informal Reviews: This is one of the type of review which doesn't follow any process to
find errors in the document. Under this technique, you just review the document and give
informal comments on it.
 Technical Reviews: A team consisting of your peers, review the technical specification
of the software product and checks whether it is suitable for the project. They try to find any
discrepancies in the specifications and standards followed. This review concentrates mainly on
the technical documentation related to the software such as Test Strategy, Test Plan and
requirement specification documents.
 Walkthrough: The author of the work product explains the product to his team.
Participants can ask questions if any. A meeting is led by the author. Scribe makes note of
review comments
 Inspection: The main purpose is to find defects and meeting is led by a trained
moderator. This review is a formal type of review where it follows a strict process to find the
defects. Reviewers have a checklist to review the work products.They record the defect and
inform the participants to rectify those errors.
 Static code Review: This is a systematic review of the software source code without
executing the code. It checks the syntax of the code, coding standards, code optimization, etc.
This is also termed as white box testing.This review can be done at any point during
development.
Dynamic Testing Techniques:

 Unit Testing: Under Unit Testing, individual units or modules are tested by the
developers. It involves testing of source code by developers.
 Integration Testing: Individual modules are grouped together and tested by the
developers. The purpose is to determine what modules are working as expected once they are
integrated.
 System Testing: System Testing is performed on the whole system by checking whether
the system or application meets the requirement specification document.
Also, Non-functional testing like performance, Security Testing fall under the category of
dynamic testing.
Difference between Static Testing And Dynamic Testing

Statement coverage
The statement coverage is also known as line coverage or segment coverage. The statement
coverage covers only the true conditions. Through statement coverage we can identify the
statements executed and where the code is not executed because of blockage.
 In this process each and every line of code needs to be checked and executed
The statement coverage can be calculated as shown below:

To understand the statement coverage in a better way let us take an example which is basically
a pseudo-code. It is not any specific programming language, but should be readable and
understandable to you, even if you have not done any programming yourself.
Consider code sample 4.1 :
READ X
READ Y
I F X>Y THEN Z = 0
ENDIF
Code sample 4.1
To achieve 100% statement coverage of this code segment just one test case is required, one
which ensures that variable A contains a value that is greater than the value of variable Y, for
example, X = 12 and Y = 10. Note that here we are doing structural test design first, since we
are choosing our input values in order ensure statement coverage.
Now, let’s take another example where we will measure the coverage first. In order to simplify
the example, we will regard each line as a statement. A statement may be on a single line, or it
may be spread over several lines. One line may contain more than one statement, just one
statement, or only part of a statement. Some statements can contain other statements inside
them. In code sample 4.2, we have two read statements, one assignment statement, and then
one IF statement on three lines, but the IF statement contains another statement (print) as part
of it.
1 READ X
2 READ Y
3 Z =X + 2*Y
4 IF Z> 50 THEN
5 PRINT large Z
6 ENDIF
Code sample 4.2
Although it isn’t completely correct, we have numbered each line and will regard each line as a
statement. Let’s analyze the coverage of a set of tests on our six-statement program:
TEST SET 1
Test 1_1: X= 2, Y = 3
Test 1_2: X =0, Y = 25
Test 1_3: X =47, Y = 1
Which statements have we covered?
 In Test 1_1, the value of Z will be 8, so we will cover the statements on lines 1 to 4
and line 6.
 In Test 1_2, the value of Z will be 50, so we will cover exactly the same statements as
Test 1_1.
 In Test 1_3, the value of Z will be 49, so again we will cover the same statements.
Since we have covered five out of six statements, we have 83% statement coverage (with three
tests). What test would we need in order to cover statement 5, the one statement that we
haven’t exercised yet? How about this one:
Test 1_4: X = 20, Y = 25
This time the value of Z is 70, so we will print ‘Large Z’ and we will have exercised all six of the
statements, so now statement coverage = 100%. Notice that we measured coverage first, and
then designed a test to cover the statement that we had not yet covered.
Note that Test 1_4 on its own is more effective which helps in achieving 100% statement
coverage, than the first three tests together. Just taking Test 1_4 on its own is also more
efficient than the set of four tests, since it has used only one test instead of four. Being more
effective and more efficient is the mark of a good test technique
Advantage of statement coverage:
 It verifies what the written code is expected to do and not to do
 It measures the quality of code written
 It checks the flow of different paths in the program and it also ensure that whether
those path are tested or not.
Disadvantage of statement coverage:
 It cannot test the false conditions.
 It does not report that whether the loop reaches its termination condition.
 It does not understand the logical operators.
Branch Coverage or Decision Coverage
 Branch coverage is also known as Decision coverage or all-edges coverage.
 It covers both the true and false conditions unlikely the statement coverage.
 A branch is the outcome of a decision, so branch coverage simply measures which
decision outcomes have been tested. This sounds great because it takes a more in-depth view
of the source code than simple statement coverage
 A decision is an IF statement, a loop control statement (e.g. DO-WHILE or REPEAT-
UNTIL), or a CASE statement, where there are two or more outcomes from the statement. With
an IF statement, the exit can either be TRUE or FALSE, depending on the value of the logical
condition that comes after IF
The decision coverage can be calculated as given below:

In the previous section we saw that just one test case was required to achieve 100% statement
coverage. However, decision coverage requires each decision to have had both a True and False
outcome. Therefore, to achieve 100% decision coverage, a second test case is necessary where
A is less than or equal to B which ensures that the decision statement ‘IF A > B’ has a False
outcome. So one test is sufficient for 100% statement coverage, but two tests are needed for
100% decision coverage. It is really very important to note that 100% decision coverage
guarantees 100% statement coverage, but not the other way around.
1 READ A
2 READ B
3 C = A – 2 *B
4 IFC <0THEN
5 PRINT “C negative”
6 ENDIF
Code sample 4.3
Let’s suppose that we already have the following test, which gives us 100% statement coverage
for code sample 4.3.
TEST SET 2 Test 2_1: A = 20, B = 15
The value of C is -10, so the condition ‘C < 0’ is True, so we will print ‘C negative’ and we have
executed the True outcome from that decision statement. But we have not executed the False
outcome of the decision statement. What other test would we need to exercise the False
outcome and to achieve 100% decision coverage?
Before we answer that question, let’s have a look at another way to represent this code.
Sometimes the decision structure is easier to see in a control flow diagram (see Figure 4.4).

The dotted line shows where Test 2_1 has gone and clearly shows that we haven’t yet had a
test that takes the False exit from the IF statement.
Let’s modify our existing test set by adding another test:
TEST SET 2
Test 2_1: A = 20, B = 15
Test 2_2: A = 10, B = 2
This now covers both of the decision outcomes, True (with Test 2_1) and False (with Test 2_2).
If we were to draw the path taken by Test 2_2, it would be a straight line from the read
statement down the False exit and through the ENDIF. We could also have chosen other
numbers to achieve either the True or False outcomes.
Advantages of decision coverage:
 To validate that all the branches in the code are reached
 To ensure that no branches lead to any abnormality of the program’s operation
 It eliminate problems that occur with statement coverage testing
Disadvantages of decision coverage:
 This metric ignores branches within boolean expressions which occur due to short-
circuit operators.
Path Testing?
Path testing is a structural testing method that involves using the source code of a program in
order to find every possible executable path. It helps to determine all faults lying within a piece
of code. This method is designed to execute all or selected path through a computer program.
Any software program includes, multiple entry and exit points. Testing each of these points is a
challenging as well as time-consuming. In order to reduce the redundant tests and to achieve
maximum test coverage, basis path testing is used.
What is Basis Path Testing?
The basis path testing is same, but it is based on a White Box Testing method, that defines test
cases based on the flows or logical path that can be taken through the program. In software
engineering, Basis path testing involves execution of all possible blocks in a program and
achieves maximum path coverage with the least number of test cases. It is a hybrid of branch
testing and path testing methods.
The objective behind basis path in software testing is that it defines the number of independent
paths, thus the number of test cases needed can be defined explicitly (maximizes the coverage
of each test case).
Here we will take a simple example, to get a better idea what is basis path testing include
In the above example, we can see there are few conditional statements that is executed
depending on what condition it suffice. Here there are 3 paths or condition that need to be
tested to get the output,
 Path 1: 1,2,3,5,6, 7
 Path 2: 1,2,4,5,6, 7
 Path 3: 1, 6, 7
Steps for Basis Path testing
The basic steps involved in basis path testing include
 Draw a control graph (to determine different program paths)
 Calculate Cyclomatic complexity (metrics to determine the number of independent
paths)
 Find a basis set of paths
 Generate test cases to exercise each path
Advantages of Basic Path Testing
 It helps to reduce the redundant tests
 It focuses attention on program logic
 It helps facilitates analytical versus arbitrary case design
 Test cases which exercise basis set will execute every statement in a program at least
once
Path Testing Techniques:
 Control Flow Graph (CFG) - The Program is converted into Flow graphs by representing
the code into nodes, regions and edges.
 Decision to Decision path (D-D) - The CFG can be broken into various Decision to
Decision paths and then collapsed into individual nodes.
 Independent (basis) paths - Independent path is a path through a DD-path graph which
cannot be reproduced from other paths by other methods.

Control Flow Testing

Control flow testing uses the control structure of a program to develop the test cases for the
program.
The test cases are developed to sufficiently cover the whole control structure of the program.
The control structure of a program can be represented by the control flow graph of the
program.
Control Flow Graph 
The control flow graph G = (N, E) of a program consists of a set of nodes N and a set of edge E. 
Each node represents a set of program statements. There are five types of nodes. There is a
unique entry node and a unique exit node.  There is an edge from node n1 to node n2 if the
control may flow from the last statement in n1 to the first statement in n2 .
Elements of a Control Flow Graph
• Three kinds of nodes: – Statement nodes: single-entry-single-exit sequences of statements –
Predicate (decision) nodes: conditions for branching – Auxiliary nodes: (optional) for easier
understanding of conditional flow constructs (e.g. merge points for IF) • Edges: show possible
flow of control
Control Flow Graph: Nodes  A decision node contains a conditional statement that creates 2 or
more control branches (e.g. if or switch statements).  A merge node usually does not contain
any statement and is used to represent a program point where multiple control branches
merge.  A statement node contains a sequence of statements. The control must enter from
the first statement and exit from the last statement.

https://www.cs.ccu.edu.tw/~naiwei/cs5812/st4.pdf

Condition coverage?
FacebookLinkedInTwitterEmail
This is closely related to decision coverage but has better sensitivity to the control flow.
However, full condition coverage does not guarantee full decision coverage.
 Condition coverage reports the true or false outcome of each condition.
 Condition coverage measures the conditions independently of each other.
Condition coverage
Simple example
Assume we want to test the following code extract:

if ( (A || B) && C )
{
/* instructions */
}
else
{
/* instructions */
}

where A, B and C represent atomic boolean expressions (i.e. not divisible in other boolean sub-
expressions).
In order to ensure Condition coverage criteria for this example, A, B and C should be evaluated
at least one time "true" and one time "false" during testes
So, in our example, the 3 following testes would be sufficient to valid Condition coverage:

A = true / B = not eval / C = false

A = false / B = true / C = true
A = false / B = false / C = not eval

Mutation Testing
Mutation Testing is a type of software testing where we mutate (change) certain statements in
the source code and check if the test cases are able to find the errors. It is a type of White Box
Testing which is mainly used for Unit Testing. The changes in mutant program are kept
extremely small, so it does not affect the overall objective of the program.
The goal of Mutation Testing is to assess the quality of the test cases which should be robust
enough to fail mutant code. This method is also called as Fault-based testing strategy as it
involves creating a fault in the program
How to execute Mutation Testing?
Following are the steps to execute mutation testing(mutation analysis):
Step 1: Faults are introduced into the source code of the program by creating many versions
called mutants. Each mutant should contain a single fault, and the goal is to cause the mutant
version to fail which demonstrates the effectiveness of the test cases.
Step 2: Test cases are applied to the original program and also to the mutant program. A Test
Case should be adequate, and it is tweaked to detect faults in a program.
Step 3: Compare the results of an original and mutant program.
Step 4: If the original program and mutant programs generate the different output, then that
the mutant is killed by the test case. Hence the test case is good enough to detect the change
between the original and the mutant program.
Step 5: If the original program and mutant program generate the same output, Mutant is kept
alive. In such cases, more effective test cases need to be created that kill all mutants.
How to Create Mutant Programs?
 A mutation is nothing but a single syntactic change that is made to the program statement.
Each mutant program should differ from the original program by one mutation.
Original Program Mutant Program
If (x>y) If(x<y)

Print "Hello" Print "Hello"

Else Else

Print "Hi" Print "Hi"

What to change in a Mutant Program?

There are several techniques that could be used to generate mutant programs. Let's look at
them
Expression Modification
Operand replacement operators Statement modification Operators
Operators
Replace the operand with another Replace an operator or insertion of Programmatic statements are
operand (x with y or y with x) or with new operators in a program modified to create mutant
the constant value. statement. programs.
Example- Example- Example-

If(x>y) replace x and y values If(x==y) Delete the else part in an if-else
statement
If(5>y) replace x by constant 5 We can replace == into >= and
have mutant program as Delete the entire if-else statement
 Expression Modification
Operand replacement operators Statement modification Operators
Operators
to check how a program behaves
If(x>=y) and inserting ++ in the
statement Some of sample mutation operators:
 GOTO label replacement
If(x==++y)  Return statement
replacement
 Statement deletion
 Unary operator insertion
(Like - and ++)
 Logical connector
replacement
 Comparable array name
replacement
 Removing of else part in the
if-else statement
 Adding or replacement of
operators
 Statement replacement by
changing the data
 Data Modification for the
variables
 Modification of data types in
the program
Automation of Mutation Testing:
Mutation testing is extremely time consuming and complicated to execute manually. To speed
up the process, it is advisable to go for automation tools. Automation tools reduce the cost of
testing as well.
List of tools available -
 Stryker
 PIT Testing
Types of Mutation Testing
In Software Engineering, Mutation testing could be fundamentally categorized into 3 types–
statement mutation, decision mutation, and value mutation.
1. Statement Mutation - developer cut and pastes a part of a code of which the outcome
may be a removal of some lines
2. Value Mutation- values of primary parameters are modified
3. Decision Mutation- control statements are to be changed
Mutation Score:
The mutation score is defined as the percentage of killed mutants with the total number of
mutants.
 Mutation Score = (Killed Mutants / Total number of Mutants) * 100

Test cases are mutation adequate if the score is 100%. Experimental results have shown that
mutation testing is an effective approach for measuring the adequacy of the test cases. But, the
main drawback is that the high cost of generating the mutants and executing each test case
against that mutant program.
Advantages of Mutation Testing:
Following are the advantages of Mutation Testing:
 It is a powerful approach to attain high coverage of the source program.
 This testing is capable comprehensively testing the mutant program.
 Mutation testing brings a good level of error detection to the software developer.
 This method uncovers ambiguities in the source code and has the capacity to detect all
the faults in the program.
 Customers are benefited from this testing by getting a most reliable and stable system.
Disadvantages of Mutation Testing:
On the other side, the following are the disadvantages of Mutant testing:
 Mutation testing is extremely costly and time-consuming since there are many mutant
programs that need to be generated.
 Since its time consuming, it's fair to say that this testing cannot be done without an
automation tool.
 Each mutation will have the same number of test cases than that of the original
program. So, a large number of mutant programs may need to be tested against the original
test suite.
 As this method involves source code changes, it is not at all applicable for Black Box
Testing.
Black Box Testing?
Black box testing, which is also known as behavioral, opaque-box, closed-box, specification-
based or eye-to-eye testing, is a Software Testing method that analyses the functionality of a
software/application without knowing much about the internal structure/design of the item
that is being tested and compares the input value with the output value.
The main focus in black box testing is on the functionality of the system as a whole. The
term ‘behavioral testing' is also used for black box testing. Behavioral test design is slightly
different from the black-box test design because the use of internal knowledge isn't strictly
forbidden, but it's still discouraged.
Each testing method has its own advantages and disadvantages. There are some bugs that
cannot be found using the only black box or only white box technique. Majority of the
applications are tested by black box method. We need to cover the majority of test cases so
that most of the bugs will get discovered by a black-box method.
This testing occurs throughout the software development and Testing life cycle i.e in Unit,
Integration, System, Acceptance, and regression testing stages.
This can be both functional or non-functional.

Advantages
 Tests are done from a user’s point of view and will help in exposing discrepancies in the
specifications.
 Tester need not know programming languages or how the software has been
implemented.
 Tests can be conducted by a body independent from the developers, allowing for an
objective perspective and the avoidance of developer-bias.
 Test cases can be designed as soon as the specifications are complete.
Disadvantages
 Only a small number of possible inputs can be tested and many program paths will be
left untested.
 Without clear specifications, which is the situation in many projects, test cases will be
difficult to design.
 Tests can be redundant if the software designer/developer has already run a test case.
 Ever wondered why a soothsayer closes the eyes when foretelling events? So is almost
the case in Black Box Testing.
Types of Black Box Testing
Practically, there are several types of black box testing that are possible but if we consider the
major variant of it then below mentioned are the two fundamental ones.
#1) Functional Testing
This type deals with the functional requirements or specifications of an application. Here,
different actions or functions of the system are being tested by providing the input and
comparing the actual output with the expected output.
For Example, when we test a Dropdown list, we click on it and verify that it expands and all the
expected values are showing in the list.
Few major types of Functional Testing are:
 Smoke Testing
 Sanity Testing
 Integration Testing
 System Testing
 Regression Testing
 User Acceptance Testing
=> Read More on Functional Testing.
#2) Non-Functional Testing
Apart from the functionalities of the requirements, there are several non-functional aspects as
well that are required to be tested to improve the quality and performance of the application.
Few major types of Non-functional testing include:
 Usability Testing
 Load Testing
 Performance Testing
 Compatibility Testing
 Stress Testing
 Scalability Testing
=> Read More on Non-Functional Testing.
Black Box Testing Techniques
In order to systematically test a set of functions, it is necessary to design test cases. Testers can
create test cases from the requirement specification document using the following black box
testing techniques.
 Equivalence Partitioning
 Boundary Value Analysis
 Decision Table Testing
 State Transition Testing
 Error Guessing
 Graph-Based Testing Methods
 Comparison Testing
Let us understand each technique in detail.
#1) Equivalence Partitioning:
This technique is also known as Equivalence Class Partitioning (ECP). In this technique, input
values to the system or application are divided into different classes or groups based on its
similarity in the outcome.
Hence, instead of using each and every input value we can now use any one value from the
group/class to test the outcome. In this way, we can maintain the test coverage while we can
reduce a lot of rework and most importantly the time spent.
For Example:
As present in the above image, an “AGE” text field accepts only the numbers from 18 to 60.
There will be three set of classes or groups.
Two invalid classes will be:
a) Less than or equal to 17.
b) Greater than or equal to 61.
One valid class will be anything between 18 to 60.
We have thus reduced the test cases to only 3 test cases based on the formed classes thereby
covering all the possibilities. So, testing with anyone value from each set of the class is
sufficient to test the above scenario.
=> Recommended Read – What is Equivalence Partitioning?
#2) Boundary Value Analysis:
From the name itself, we can understand that in this technique we focus on the values at
boundaries as it is found that many applications have a high amount of issues on the
boundaries.
Boundary means the values near the limit where the behavior of the system changes. In
boundary value analysis both the valid inputs and invalid inputs are being tested to verify the
issues.
For Example:
If we want to test a field where values from 1 to 100 should be accepted then we choose the
boundary values: 1-1, 1, 1+1, 100-1, 100, and 100+1. Instead of using all the values from 1 to
100, we just use 0, 1, 2, 99, 100, and 101.
#3) Decision Table Testing:
As the name itself suggests that, wherever there are logical relationships like:
If
{
(Condition = True)
then action1 ;
}
else action2; /*(condition = False)*/
Then a tester will identify two outputs (action1 and action2) for two conditions (True and
False). So based on the probable scenarios a Decision table is carved to prepare a set of test
cases.
For Example:
Take an example of XYZ bank that provides interest rate for the Male senior citizen as 10% and
for rest of the people 9%.

In this example condition, C1 has two values as true and false, condition C2 also has two values
as true and false. The number of total possible combinations would then be four. This way we
can derive test cases using decision table.
#4) State Transition Testing:
State Transition Testing is a technique that is used to test the different states of the system
under test. The state of the system changes depending upon the conditions or events. The
events trigger states which become scenarios and a tester needs to test them.
A systematic state transition diagram gives a clear view of the state changes but it is effective
for simpler applications. More complex projects may lead to more complex transition diagrams
thus making it less effective.
For Example:

Cause-Effect Graphing:
It is a simple test design technique that requires distinguishing the cases (input conditions) and
outcomes (output conditions), drawing a Cause-Effect Graph, and forming test cases
accordingly.
Advantages and Disadvantages
Advantages:
 The tester need not have a technical background. It is important to test by being in the
user's shoes and think from the user’s point of view.
 Testing can be started once the development of the project/application is done. Both
the testers and developers work independently without interfering in each other’s space.
 It is more effective for large and complex applications.
 Defects and inconsistencies can be identified at the early stage of testing.
Disadvantages:
 Without any technical or programming knowledge, there are chances of ignoring
possible conditions of the scenario to be tested.
 In a stipulated time there are possibilities of testing less and skipping all possible inputs
and their output testing.
 A Complete Test Coverage is not possible for large and complex projects.

Pairwise Testing in Software Testing

Pairwise Testing is a test design technique that delivers hundred percent test coverage.
We need test cases with 100% test coverage in order to test any software application. This will
ensure that all possible combination of input and output parameters are well tested. Now a
quick question, is that possible to achieve 100% test coverage without writing verbose test
cases? Well, it’s possible if we practice “Pairwise Testing” or “All-Pairs testing” test
design. Pairwise Testing can be defined as a “black box testing” test design technique that
ensures almost hundred percent test coverage without writing verbose test cases and their
execution.
With this test design technique, the testing team can achieve maximum test coverage ensuring
high defect yield ratio and there is no need to test the application behavior against all possible
combinations of input and output parameters. Since a number of test cases are less, therefore,
test cases execution requires very less time and covers almost all possible scenarios.
In the black box testing approach, we test the application behavior for input parameters versus
output results obtained. Again, the application output depends on input parameters, static
values, state transitions and variables, output values, etc. Other approaches like boundary
value analysis, equivalence partitioning, etc. are beneficial but these techniques do not provide
maximum test coverage.
Advantages of Pairwise Testing:
 It reduces the number of test cases execution.
 It increases the test coverage up to 100 percentages.
 It increases the defect or bug yield ratio.
 It takes less time to complete the execution of the test suite.
 It reduces the overall testing budget for a project.

Disadvantages of Pairwise Testing:

 If values selected for the variables are inappropriate, it is no longer beneficial.
 The highly probable combination can be missed while selecting the test data. This may
result in a reduction of defect yield ratio.
 If variables combinations as test data are not understood correctly, such testing has no
use at all.

What is a Use Case?

A use case is a description of a particular use of the system by an actor or user. It is used widely
in developing tests at system or acceptance level.
What is Use Case Testing?
Use Case Testing is defined as a software testing technique, that helps identify test cases that
cover the entire system, on a transaction by transaction basis from start to the finishing point.
How to do Use Case Testing: Example
In a use-case, an actor is represented by "A" and system by "S". We create Use for a login
functionality of a Web Application as shown below
Main Success Scenario Step Description

A:Actor 1 A: Enter Agent Name & Password

S:System
2 S: Validate Password

3 S: Allow Account Access

Extensions 2a Password not valid

S: Display Message and ask for re-try 4 times

2b Password not valid 4 times

S: Close Application

 Consider the first step of an end to end scenario for a login functionality for our web
application where the Actor enters email and password.
 In the next step, the system will validate the password
 Next, if the password is correct, the access will be granted
 There can be an extension of this use case. In case password is not valid system will
display a message and ask for re-try four times
 If Password, not valid four times system will ban the IP address.