Unit - 2

TYPES OF TESTING
 Types of Testing
The categorization of software testing is a part of diverse testing
activities, such as test strategy, test deliverables, a defined test
objective, etc. And software testing is the execution of the software to
find defects.
The purpose of having a testing type is to confirm the AUT (Application
Under Test).
To start testing, we should have a requirement, application-ready,
necessary resources available. To maintain accountability, we should
assign a respective module to different test engineers.
The software testing mainly divided into two parts, which are as
follows:
1. Manual Testing
2. Automation Testing
What is Manual Testing?
Testing any software or an application according to the client's needs
without using any automation tool is known as manual testing.
In other words, we can say that it is a procedure of verification and
validation. Manual testing is used to verify the behavior of an
application or software in contradiction of requirements specification.
We do not require any precise knowledge of any testing tool to execute
the manual test cases. We can easily prepare the test document while
performing manual testing on any application.
Classification of Manual Testing:
In software testing, manual testing can be further classified into three
different types of testing, which are as follows:
1. Black Box Testing
2. White Box Testing
3. Grey Box Testing
 Black Box Testing
Another type of manual testing is black-box testing. In this testing,
the test engineer will analyze the software against requirements,
identify the defects or bug, and sends it back to the development
team.
Then, the developers will fix those defects, do one round of White
box testing, and send it to the testing team.
Here, fixing the bugs means the defect is resolved, and the
particular feature is working according to the given requirement.
The main objective of implementing the black box testing is to
specify the business needs or the customer's requirements.
In other words, we can say that black box testing is a process of
checking the functionality of an application as per the customer
requirement. The source code is not visible in this testing; that's
why it is known as black-box testing.
 Generic steps of black box testing
• The black box test is based on the specification of requirements, so it is
examined in the beginning.
• In the second step, the tester creates a positive test scenario and an
adverse test scenario by selecting valid and invalid input values to check
that the software is processing them correctly or incorrectly.
• In the third step, the tester develops various test cases such as decision
table, all pairs test, equivalent division, error estimation, cause-effect
graph, etc.
• The fourth phase includes the execution of all test cases.
• In the fifth step, the tester compares the expected output against the
actual output.
• In the sixth and final step, if there is any flaw in the software, then it is
cured and tested again.
 Test procedure

• The test procedure of black box testing is a kind of process in which

the tester has specific knowledge about the software's work, and it
develops test cases to check the accuracy of the software's
functionality.
• It does not require programming knowledge of the software. All test
cases are designed by considering the input and output of a particular
function.
• A tester knows about the definite output of a particular input, but not
about how the result is arising. There are various techniques used in
black box testing for testing like decision table technique, boundary
value analysis technique, state transition, All-pair testing, cause-effect
graph technique, equivalence partitioning technique, error guessing
technique, use case technique and user story technique. All these
techniques have been explained in detail within the tutorial.
 Test cases
• Test cases are created considering the specification of the
requirements.
• These test cases are generally created from working descriptions of
the software including requirements, design parameters, and other
specifications.
• For the testing, the test designer selects both positive test scenario by
taking valid input values and adverse test scenario by taking invalid
input values to determine the correct output.
• Test cases are mainly designed for functional testing but can also be
used for non-functional testing.
• Test cases are designed by the testing team, there is not any
involvement of the development team of software.
Techniques Used in Black Box Testing

1. Decision table technique in Black box testing:

• Decision table technique is one of the widely used case design techniques for
black box testing. This is a systematic approach where various input combinations
and their respective system behavior are captured in a tabular form.
• That's why it is also known as a cause-effect table. This technique is used to pick
the test cases in a systematic manner; it saves the testing time and gives good
coverage to the testing area of the software application.
• Decision table technique is appropriate for the functions that have a logical
relationship between two and more than two inputs.
• This technique is related to the correct combination of inputs and determines the
result of various combinations of input. To design the test cases by decision table
technique, we need to consider conditions as input and actions as output.
1.Condition Stubs : The conditions are listed in this
first upper left part of the decision table that is used
to determine a particular action or set of actions.
2.Action Stubs : All the possible actions are given in
the first lower left portion (i.e, below condition stub)
of the decision table.
3.Condition Entries : In the condition entry, the
values are inputted in the upper right portion of the
decision table. In the condition entries part of the
table, there are multiple rows and columns which are
known as Rule.
4.Action Entries : In the action entry, every entry has
some associated action or set of actions in the lower
right portion of the decision table and these values
are called outputs.
• Let's understand it by an example:
• Most of us use an email account, and when you want to
use an email account, for this you need to enter the email
and its associated password.
• If both email and password are correctly matched, the user
will be directed to the email account's homepage;
otherwise, it will come back to the login page with an error
message specified with "Incorrect Email" or "Incorrect
Password."
• Now, let's see how a decision table is created for the login
function in which we can log in by using email and
password. Both the email and the password are the
conditions, and the expected result is action.
• In the table, there are four conditions or test cases to test the login function. In
the first condition if both email and password are correct, then the user should
be directed to account's Homepage.
• In the second condition if the email is correct, but the password is incorrect then
the function should display Incorrect Password. In the third condition if the email
is incorrect, but the password is correct, then it should display Incorrect Email.
• Now, in fourth and last condition both email and password are incorrect then the
function should display Incorrect Email.
• In this example, all possible conditions or test cases have been included, and in
the same way, the testing team also includes all possible test cases so that
upcoming bugs can be cured at testing level.
• In order to find the number of all possible conditions, tester uses 2n formula
where n denotes the number of inputs; in the example there is the number of
inputs is 2 (one is true and second is false).
• Number of possible conditions = 2^ Number of Values of the second condition
Number of possible conditions =2^2 = 4
• While using the decision table technique, a tester determines the expected
output, if the function produces expected output, then it is passed in testing, and
if not then it is failed. Failed software is sent back to the development team to fix
the defect.
2. Boundary Value Analysis
• Boundary value analysis is one of the widely used case design
technique for black box testing. It is used to test boundary values
because the input values near the boundary have higher chances of
error.
• Whenever we do the testing by boundary value analysis, the tester
focuses on, while entering boundary value whether the software is
producing correct output or not.
• Boundary values are those that contain the upper and lower limit of a
variable. Assume that, age is a variable of any function, and its
minimum value is 18 and the maximum value is 30, both 18 and 30
will be considered as boundary values.
• The basic assumption of boundary value analysis is, the test cases
that are created using boundary values are most likely to cause an
error.
• There is 18 and 30 are the boundary values that's why tester pays
more attention to these values, but this doesn't mean that the middle
values like 19, 20, 21, 27, 29 are ignored. Test cases are developed for
each and every value of the range.
• Testing of boundary values is done by making valid and invalid
partitions. Invalid partitions are tested because testing of output in
adverse condition is also essential.
• Let's understand via practical:
• Imagine, there is a function that accepts a number
between 18 to 30, where 18 is the minimum and 30 is the
maximum value of valid partition, the other values of this
partition are 19, 20, 21, 22, 23, 24, 25, 26, 27, 28 and 29.
The invalid partition consists of the numbers which are
less than 18 such as 12, 14, 15, 16 and 17, and more than
30 such as 31, 32, 34, 36 and 40. Tester develops test
cases for both valid and invalid partitions to capture the
behavior of the system on different input conditions.
• The software system will be passed in the test if it accepts
a valid number and gives the desired output, if it is not,
then it is unsuccessful. In another scenario, the software
system should not accept invalid numbers, and if the
entered number is invalid, then it should display error
massage.
• If the software which is under test, follows all the testing
guidelines and specifications then it is sent to the
releasing team otherwise to the development team to fix
the defects.
3. State Transition Technique
• The general meaning of state transition is, different forms of the same
situation, and according to the meaning, the state transition method
does the same. It is used to capture the behavior of the software
application when different input values are given to the same
function.
• We all use the ATMs, when we withdraw money from it, it displays
account details at last. Now we again do another transaction, then it
again displays account details, but the details displayed after the
second transaction are different from the first transaction, but both
details are displayed by using the same function of the ATM.
• So the same function was used here but each time the output was
different, this is called state transition. In the case of testing of a
software application, this method tests whether the function is
following state transition specifications on entering different inputs.
• This applies to those types of applications that provide the specific
number of attempts to access the application such as the login
function of an application which gets locked after the specified
number of incorrect attempts. Let's see in detail, in the login function
we use email and password, it gives a specific number of attempts to
access the application, after crossing the maximum number of
attempts it gets locked with an error message.
Let see in the diagram:
• There is a login function
of an application which
provides a maximum
three number of
attempts, and after
exceeding three attempts,
it will be directed to an
error page.
State transition table:
STATE LOGIN VALIDATION REDIRECTED
S1 First Attempt Invalid S2
S2 Second Attempt Invalid S3
S3 Third Attempt Invalid S5
S4 Home Page
S5 Error Page

In the above state transition table, we see that state S1 denotes first
login attempt. When the first attempt is invalid, the user will be
directed to the second attempt (state S2). If the second attempt is also
invalid, then the user will be directed to the third attempt (state S3).
Now if the third and last attempt is invalid, then the user will be
directed to the error page (state S5). But if the third attempt is valid,
then it will be directed to the homepage (state S4).
Let's see state transition table if third attempt is valid:
STATE LOGIN VALIDATION REDIRECTED
S1 First Attempt Invalid S2
S2 Second Attempt Invalid S3
S3 Third Attempt Valid S4
S4 Home Page
S5 Error Page

By using the above state transition table we can perform testing of any
software application. We can make a state transition table by
determining desired output, and then exercise the software system to
examine whether it is giving desired output or not.
4.Equivalence Partitioning Technique
• Equivalence partitioning is a technique of software testing in which
input data is divided into partitions of valid and invalid values, and it
is mandatory that all partitions must exhibit the same behavior. If a
condition of one partition is true, then the condition of another equal
partition must also be true, and if a condition of one partition is false,
then the condition of another equal partition must also be false.
• The principle of equivalence partitioning is, test cases should be
designed to cover each partition at least once. Each value of every
equal partition must exhibit the same behavior as other.
• The equivalence partitions are derived from requirements and
specifications of the software. The advantage of this approach is, it
helps to reduce the time of testing due to a smaller number of test
cases from infinite to finite. It is applicable at all levels of the testing
process.
Examples of Equivalence Partitioning technique:
Assume that there is a function of a software application that accepts a
particular number of digits, not greater and less than that particular
number. For example, an OTP number which contains only six digits,
less or more than six digits will not be accepted, and the application
will redirect the user to the error page.
1. OTP Number = 6 digits
• A function of the software application accepts a 10 digit mobile number.
2. Mobile number = 10 digits

• In both examples, we can see that there is a partition of two equally valid and invalid
partitions, on applying valid value such as OTP of six digits in the first example and mobile
number of 10 digits in the second example, both valid partitions behave same, i.e.
redirected to the next page.
• Another two partitions contain invalid values such as 5 or less than 5 and 7 or more than 7
digits in the first example and 9 or less than 9 and 11 or more than 11 digits in the second
example, and on applying these invalid values, both invalid partitions behave same, i.e.
redirected to the error page.
• We can see in the example, there are only three test cases for each example and that is also
the principal of equivalence partitioning which states that this method intended to reduce
the number of test cases.
Why Black-box testing is required ?

• Black-box testing attempts to find errors in the following categories

• To test the modules independently
• To test the functional validity of the software so that incorrect or
• missing functions can be recognized
• To look for interface errors.
• To test the system behavior and check its performance
• To test the maximum load or stress on the system
• To test the software such that the user/customer accepts the system
• within defined acceptable limits
 White Box Testing
• white box testing which also known as glass box is testing,
structural testing, clear box testing, open box testing and
transparent box testing.
• It tests internal coding and infrastructure of a software
focus on checking of predefined inputs against expected
and desired outputs.
• It is based on inner workings of an application and
revolves around internal structure testing.
• In this type of testing programming skills are required to
design test cases.
• The primary goal of white box testing is to focus on the
flow of inputs and outputs through the software and
strengthening the security of the software.
• The term 'white box' is used because of the internal perspective of
the system.
• The clear box or white box or transparent box name denote the
ability to see through the software's outer shell into its inner
workings.
• Developers do white box testing. In this, the developer will test every
line of the code of the program.
• The developers perform the White-box testing and then send the
application or the software to the testing team, where they will
perform the black box testing and verify the application along with
the requirements and identify the bugs and sends it to the developer.
 Need of white box Testing
• white-box testing techniques are used for testing the module for initial stage testing.
• Black-box testing is the second stage for testing the software.
• Though test cases for black box can be designed earlier than white-box test cases, they cannot be
executed until the code is produced and checked using white-box testing techniques. Thus, white-
box testing is not an alternative but an essential stage.
• Since white-box testing is opposite to black-box testing, there are categories of bugs which can be
open by white-box testing, but not through black-box testing.
• There may be portions in the code which are not checked when executing functional test cases,
but these will be executed and tested by white-box testing.
• Errors which have come from the design phase will also be reflected in the code, therefore we
must execute white-box test cases for verification of code (unit verification).
• We often believe that a logical path is not likely to be executed when, infect, it may be executed
on a regular basis.
• White-box testing explores these paths too.
• Some typographical errors are not observed and go undetected and are not covered by black-box
testing techniques.
• White-box testing techniques help detect these errors.
Classification of White Box Testing
 Structural : Coverage, Path
• Structural testing, also known as glass box testing or white box testing
is an approach where the tests are derived from the knowledge of the
software's structure or internal implementation.
• The other names of structural testing includes clear box testing, open
box testing, logic driven testing or path driven testing.
Structural Testing Techniques:
• Statement Coverage - This technique is aimed at exercising all
programming statements with minimal tests.
• Branch Coverage - This technique is running a series of tests to
ensure that all branches are tested at least once.
• Path Coverage - This technique corresponds to testing all possible
paths which means that each statement and branch are covered.
1. Statement Coverage:
Statement coverage is one of the widely used software testing. It comes
under white box testing.
Statement coverage technique is used to design white box test cases. This
technique involves execution of all statements of the source code at least
once. It is used to calculate the total number of executed statements in the
source code out of total statements present in the source code.
Statement coverage derives scenario of test cases under the white box
testing process which is based upon the structure of the code.

Let's understand the process of calculating statement coverage by an

example:
• Here, we are taking source code to create two different scenarios according
to input values to check the percentage of statement coverage for each
scenario.
Source Code Structure:
• Take input of two values like a=0 and b=1.
• Find the sum of these two values.
• If the sum is greater than 0, then print "This is the positive result."
• If the sum is less than 0, then print "This is the negative result."
input (int a, int b)
{
Function to print sum of these integer values (sum = a+b)
If (sum>0)
{
Print (This is positive result)
} else
{
Print (This is negative result)
}
}
• So, this is the basic structure of the program, and that is the task it is
going to do.
• Now, let's see the two different scenarios and calculation of the
percentage of Statement Coverage for given source code.
Scenario 1:
If a = 5, b = 4
print (int a, int b) {
int sum = a + b;
if (sum>0)
print ("This is a positive result")
else
print ("This is negative result")
}
• In scenario 1, we can see the value of sum will be 9 that is greater
than 0 and as per the condition result will be "This is a positive
result." The statements highlighted in yellow color are executed
statements of this scenario.
• To calculate statement coverage of the first scenario, take the total
number of statements that is 7 and the number of used statements
that is 5.

Total number of statements = 7

Number of executed statements = 5
Statement coverage = 5/7*100
= 500/7
= 71%
Scenario 2:

If A = -2, B = -7
print (int a, int b) {
int sum = a + b;
if (sum>0)
print ("This is a positive result")
else
print ("This is negative result")
}
• In scenario 2, we can see the value of sum will be -9 that is less than 0 and
as per the condition, result will be "This is a negative result." The
statements highlighted in yellow color are executed statements of this
scenario.
• To calculate statement coverage of the first scenario, take the total number
of statements that is 7 and the number of used statements that is 6.
Total number of statements = 7,
Number of executed statements = 6
Statement coverage = 6/7*100
= 600/7
= 85%
But, we can see all the statements are covered in both scenario and
we can consider that the overall statement coverage is 100%.
So, the statement coverage technique covers dead code, unused
code, and branches.
2. Condition Coverage: • Result:
Condition coverage is also known as • In order to ensure complete Condition
Predicate Coverage in which each one coverage criteria for the above
of the Boolean expression have been example, A, B and C should be
evaluated to both TRUE and FALSE evaluated at least once against "true"
Example: and "false".
if ((A || B) && C) • So, in our example, the 3 following
tests would be sufficient for 100%
{ Condition coverage testing.
<< Few Statements >> • A = true | B = not eval | C = false
} • A = false | B = true | C = true
else • A = false | B = false | C = not eval
{
<< Few Statements >>
}
3. Loop Testing:
is a type of software testing type that is performed to validate the loops. It is
one of the type of Control Structure Testing. Loop testing is a white box
testing technique and is used to test loops in the program.
Objectives of Loop Testing:
The objective of Loop Testing is:
• To fix the infinite loop repetition problem.
• To know the performance.
• To identify the loop initialization problems.
• To determine the uninitialized variables.
Types of Loop Testing:
1. Simple Loop Testing
2. Nested Loop Testing
3. Concatenated Loop Testing
4. Unstructured Loop Testing
https://www.geeksforgeeks.org/loop-software-testing/
4. Branch Coverage:
Branch Coverage is a white box testing method in which every
outcome from a code module(statement or loop) is tested. The
purpose of branch coverage is to ensure that each decision
condition from every branch is executed at least once. It helps to
measure fractions of independent code segments and to find out
sections having no branches.
For example, if the outcomes are binary, you need to test both True
and False outcomes.
Example:
Demo(int a) { Value of Decision Branch
Test Case Output
If (a> 5) A Coverage Coverage
1 2 2 50% 33%
a=a*3
2 6 18 50% 67%
Print (a)
}
The formula to calculate Branch Coverage:
5. Path Coverage:
Path coverage is concerned with linearly independent
paths through the code. Testers draw a control flow
diagram of the code, such as the example below.
In this example, there are several possible paths
through the code:
• 1, 2
• 1, 3, 4, 5, 6, 8
• 1, 3, 4, 7, 6, 8 etc.
In a path coverage approach, the tester writers unit
tests to execute as many as possible of the paths
through the program’s control flow. The objective is to
identify paths that are broken, redundant, or inefficient.
• Basis Path Testing in software engineering is a White Box Testing method in which test
cases are defined based on flows or logical paths that can be taken through the
program.
• The objective of basis path testing is to define the number of independent paths, so the
number of test cases needed can be defined explicitly to maximize test coverage.
• 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 method of
branch testing and path testing methods
The guidelines for effectiveness of path testing are discussed below:
1) Path testing is based on control structure of the program for which flow graph is
prepared.
2) Path testing requires complete knowledge of the program’s structure.
3) Path testing is closer to the developer and used by him to test his module.
4) The effectiveness of path testing gets reduced with the increase in size of software
under test.
5) Choose enough paths in a program such that maximum logic coverage is achieved.
 Control Flow Testing
• Control flow testing is a testing technique that comes under white box testing.
• The aim of this technique is to determine the execution order of statements or
instructions of the program through a control structure.
• The control structure of a program is used to develop a test case for the
program.
• In this technique, a particular part of a large program is selected by the tester to
set the testing path. It is mostly used in unit testing. Test cases represented by
the control graph of the program.
• Control Flow Graph is formed from the node, edge, decision node, junction
node to specify all possible execution path.
Notations used for Control Flow Graph
1. Node
2. Edge
3. Decision Node
4. Junction node
Node
• It represents one or more procedural statements.
• The nodes are denoted by a circle.
• These are numbered or labeled.
Edges or links
• They represent the flow of control in a program.
• This is denoted by an arrow on the edge.
• An edge must terminate at a node.
Decision node
• A node with more than one arrow leaving it is called a decision node.
Junction node
• A node with more than one arrow entering it is called a junction.
Regions
• Areas bounded by edges and nodes are called regions.
• When counting the regions, the area outside the graph is also
considered a region.
Example:
Diagram - control flow graph
public class VoteEligiblityAge{

public static void main(String []args){

int n=45;
if(n>=18)
{
System.out.println("You are eligible for
voting");
} else
{
System.out.println("You are not eligible
for voting");
}
}
}
 Static Testing: Inspection, Walkthrough, Technical Review
• Static Testing is a type of a Software
Testing method which is performed to
check the defects in software without
actually executing the code of the software
application. Whereas in Dynamic Testing
checks the code is executed to detect the
defects.
• Static testing is performed in early stage of
development to avoid errors as it is easier
to find sources of failures and it can be
fixed easily. The errors that can’t not be
found using Dynamic Testing, can be easily
found by Static Testing.
1. Walkthrough:
• In walkthrough, author guides the review team via the document to
fulfill the common understanding and collecting the feedback.
• Walkthrough is not a formal process.
• In walkthrough, a review team does not require to do detailed study
before meeting while authors are already in the scope of preparation.
• Walkthrough is useful for higher-level documents i.e, requirement
specification and architectural documents.
Goals Of Walkthrough:
• Make the document available for the stakeholders both outside and
inside the software discipline for collecting the information about the
topic under documentation.
• Describe and evaluate the content of the document.
• Study and discuss the validity of possible alternatives and proposed
solutions.
Structured Walkthrough Participants:
• Author - The Author of the document under review.
• Presenter - The presenter usually develops the agenda for
the walkthrough and presents the output being reviewed.
• Moderator - The moderator facilitates the walkthrough
session, ensures the walkthrough agenda is followed, and
encourages all the reviewers to participate.
• Reviewers - The reviewers evaluate the document under test
to determine if it is technically accurate.
• Scribe - The scribe is the recorder of the structured
walkthrough outcomes who records the issues identified and
any other technical comments, suggestions, and unresolved
questions.
Benefits of Structured Walkthrough:
• Saves time and money as defects are found and rectified
very early in the lifecycle.
• This provides value-added comments from reviewers with
different technical backgrounds and experience.
• It notifies the project management team about the progress
of the development process.
• It creates awareness about different development or
maintenance methodologies which can provide a
professional growth to participants.
2. Inspection:
• The trained moderator guides the Inspection. It is most
formal type of review.
• The reviewers are prepared and check the documents before
the meeting.
• In Inspection, a separate preparation is achieved when the
product is examined and defects are found. These defects
are documented in issue log.
• In Inspection, moderator performs a formal follow-up by
applying exit criteria.
Goals of Inspection:
• Assist the author to improve the quality of the document
under inspection.
• Efficiently and rapidly remove the defects.
• Generating the documents with higher level of quality and it
helps to improve the product quality.
• It learns from the previous defects found and prohibits the
occurrence of similar defects.
• Generate common understanding by interchanging
information.
3. Technical Review:
• Technical review is a discussion meeting that focuses on technical
content of the document. It is a less formal review.
• It is guided by a trained moderator or a technical expert.
Goals of Technical Review:
• The goal is to evaluate the value of technical concept in the project
environment.
• Build the consistency in the use and representation of the technical
concepts.
• In early stages it ensures that the technical concepts are used
correctly.
• Notify the participants regarding the technical content of the
document.
Difference between walkthrough and inspection
Advantages of Structural Testing:
• Forces test developer to reason carefully about implementation
• Reveals errors in "hidden" code
• Spots the Dead Code or other issues with respect to best
programming practices.
Disadvantages of Structural Box Testing:
• Expensive as one has to spend both time and money to perform
white box testing.
• Every possibility that few lines of code is missed accidentally.
• Indepth knowledge about the programming language is necessary to
perform white box testing.