UNIT-2 : TYPES OF TESTING

❖ Black Box Testing :

What is & When?
Black box testing is a technique of software testing which examines the
functionality of software without peering into its internal structure or coding. The
primary source of black box testing is a specification of requirements that is stated
by the customer.

In this method, the tester selects a function and gives input value to examine its
functionality, and checks whether the function is giving expected output or not. If
the function produces correct output, then it is passed in testing, otherwise failed.
The test team reports the result to the development team and then tests the next
function. After completing testing of all functions if there are severe problems,
then it is given back to the development team for correction.

Generic steps of black box testing :

1. The black box test is based on the specification of requirements, so it is
examined in the beginning.
2. 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.
3. 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.
4. The fourth phase includes the execution of all test cases.
5. In the fifth step, the tester compares the expected output against the actual
output.
 6. 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.

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. Boundary Value Analysis :
Boundary value analysis is one of the widely used case design techniques 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.

2. Equivalence class testing :

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

3. Decision Table :
Decision Table Technique is a systematic approach where various input
combinations and their respective system behavior are captured in a tabular form.
It is appropriate for the functions that have a logical relationship between two and
more than two inputs.

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.

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.

❖ White Box Testing

Overview :
White box testing is 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 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 send it to the developer.

The developer fixes the bugs and does one round of white box testing and sends it
to the testing team. Here, fixing the bugs implies that the bug is deleted, and the
particular feature is working fine on the application.

Here, the test engineers will not include in fixing the defects for the following
reasons:
○ Fixing the bug might interrupt the other features. Therefore, the test engineer
should always find the bugs, and developers should still be doing the bug
fixes.
○ If the test engineers spend most of the time fixing the defects, then they may
be unable to find the other bugs in the application.

Test cases for white box testing are derived from the design phase of the software
development lifecycle. Data flow testing, control flow testing, path testing, branch
testing, statement and decision coverage all these techniques used by white box
testing as a guideline to create an error-free software.

White box testing follows some working steps to make testing manageable and
easy to understand what the next task to do. There are some basic steps to perform
white box testing.

Generic steps of white box testing

○ Design all test scenarios, test cases and prioritize them according to high
priority number.
 ○ This step involves the study of code at runtime to examine the resource
utilization, not accessed areas of the code, time taken by various methods
and operations and so on.
○ In this step testing of internal subroutines takes place. Internal subroutines
such as nonpublic methods, interfaces are able to handle all types of data
appropriately or not.
○ This step focuses on testing of control statements like loops and conditional
statements to check the efficiency and accuracy for different data inputs.
○ In the last step white box testing includes security testing to check all
possible security loopholes by looking at how the code handles security.

Reasons for white box testing

○ It identifies internal security holes.
○ To check the way of input inside the code.
○ Check the functionality of conditional loops.
○ To test function, object, and statement at an individual level.

Types :
The white box testing contains various tests, which are as follows:
○ Path testing
○ Loop testing
○ Condition testing
○ Testing based on the memory perspective
○ Test performance of the program
1. Path testing :
In the path testing, we will write the flow graphs and test all independent paths.
Here writing the flow graph implies that flow graphs are representing the flow of
the program and also show how every program is added with one another as we
can see in the below image:
And test all the independent paths implies that suppose a path from main() to
function G, first set the parameters and test if the program is correct in that
particular path, and in the same way test all other paths and fix the bugs.

Example :
 2. Loop testing
In the loop testing, we will test the loops such as while, for, and do-while, etc. and
also check for ending conditions if working correctly and if the size of the
conditions is enough.

For example: we have one program where the developers have given about 50,000
loops.

​ {
​ while(50,000)
​ ……
​ ……
​ }
We cannot test this program manually for all the 50,000 loops cycle. So we write a
small program that helps for all 50,000 cycles, as we can see in the below program,
that - Test P is written in the similar language as the source code program, and this
is known as a Unit test. And it is written by the developers only.

​ Test P
​ {
​ ……
​ …… }
As we can see in the below image that, we have various requirements such as 1, 2,
3, 4. And then, the developer writes the programs such as program 1,2,3,4 for the
parallel conditions. Here the application contains the 100s line of codes.
The developer will do the white box testing, and they will test all the five programs
line by line of code to find the bug. If they found any bug in any of the programs,
they will correct it. And they again have to test the system then this process
contains lots of time and effort and slows down the product release time.

Now, suppose we have another case, where the clients want to modify the
requirements, then the developer will do the required changes and test all four
program again, which take lots of time and efforts.

These issues can be resolved in the following ways:

In this, we will write test for a similar program where the developer writes these
test code in the related language as the source code. Then they execute these test
code, which is also known as unit test programs. These test programs linked to the
main program and implemented as programs.
Therefore, if there is any requirement of modification or bug in the code, then the
developer makes the adjustment both in the main program and the test program and
then executes the test program.

3. Condition testing :
In this, we will test all logical conditions for both true and false values; that is, we
will verify for both if and else conditions.

For example:

​ if(condition) - true
​ {
​ …..
​ ……
​ ……
​ }
​ else - false
​ {
​ …..
​ ……
​ ……
​ }
The above program will work fine for both the conditions, which means that if the
condition is accurate, and then else should be false and conversely.

4. Testing based on the memory (size) perspective

The size of the code is increasing for the following reasons:
○ The reuse of code is not there: let us take one example, where we have four
programs of the same application, and the first ten lines of the program are
similar. We can write these ten lines as a discrete function, and it should be
accessible by the above four programs as well. And also, if any bug is there,
we can modify the line of code in the function rather than the entire code.
○ The developers use the logic that might be modified. If one programmer
writes code and the file size is up to 250 kb, then another programmer could
write a similar code using the different logic, and the file size is up to 100kb.
 ○ The developer declares so many functions and variables that might never be
used in any portion of the code. Therefore, the size of the program will
increase.

For example,
​ Int a=15;
​ Int b=20;
​ String S= "Welcome";
​ ….
​ …..
​ …..
​ ….
​ …..
​ Int p=b;
​ Create user()
​ {
​ ……
​ ……
​ ….. 200's line of code
​ }
In the above code, we can see that the integer a has never been called anywhere in
the program, and also the function Create user has never been called anywhere in
the code. Therefore, it leads us to memory consumption.

We cannot remember this type of mistake manually by verifying the code because
of the large code. So, we have a built-in tool, which helps us to test the needless
variables and functions. And, here we have the tool called Rational purify.
Suppose we have three programs such as Program P, Q, and R, which provides the
input to S. And S goes into the programs and verifies the unused variables and then
gives the outcome. After that, the developers will click on several results and call
or remove the unnecessary function and the variables.

This tool is only used for the C programming language and C++ programming
language; for another language, we have other related tools available in the market.

○ The developer does not use the available in-built functions; instead they
write the full features using their logic. Therefore, it leads us to waste of
time and also postpone the product releases.
5. Test the performance (Speed, response time) of the program :
The application could be slow for the following reasons:
○ When logic is used.
○ For the conditional cases, we will use or & and adequately.
○ Switch case, which means we cannot use nested if, instead of using a switch
case.
As we know that the developer is performing white box testing, they understand
that the code is running slow, or the performance of the program is also getting
deliberate. And the developer cannot go manually over the program and verify
which line of the code is slowing the program.

To recover with this condition, we have a tool called Rational Quantify, which
resolves these kinds of issues automatically. Once the entire code is ready, the
Rational Quantify tool will go through the code and execute it. And we can see the
outcome in the result sheet in the form of thick and thin lines.

Here, the thick line specifies which section of code is time-consuming. When we
double-click on the thick line, the tool will take us to that line or piece of code
automatically, which is also displayed in a different color. We can change that code
and again and use this tool. When the order of lines is all thin, we know that the
presentation of the program has been enhanced. And the developers will perform
the white box testing automatically because it saves time rather than performing
manually.

Advantages of White box testing

○ White box testing optimizes code so hidden errors can be identified.
○ Test cases of white box testing can be easily automated.
○ This testing is more thorough than other testing approaches as it covers all
code paths.
○ It can be started in the SDLC phase even without GUI.

Disadvantages of White box testing

○ White box testing is too much time consuming when it comes to large-scale
programming applications.
○ White box testing is much expensive and complex.
○ It can lead to production error because it is not detailed by the developers.
○ White box testing needs professional programmers who have a detailed
knowledge and understanding of programming language and
implementation.
❖ Structural : Coverage, Path :
One of the main benefits of white box testing is that it allows for testing every part
of an application. To achieve complete code coverage, white box testing uses the
following techniques:

1. Statement Coverage :
In this technique, the aim is to traverse all statements at least once. Hence, each
line of code is tested. In the case of a flowchart, every node must be traversed at
least once. Since all lines of code are covered, it helps in pointing out faulty code.
 Statement Coverage Example

2. Branch Coverage :
In this technique, test cases are designed so that each branch from all decision
points is traversed at least once. In a flowchart, all edges must be traversed at least
once.

4 test cases are required such that all branches of all decisions are covered, i.e, all

edges of the flowchart are covered

3. Condition Coverage :
In this technique, all individual conditions must be covered as shown in the
following example:
● READ X, Y
● IF(X == 0 || Y == 0)
● PRINT ‘0’
● #TC1 – X = 0, Y = 55
● #TC2 – X = 5, Y = 0

4. Multiple Condition Coverage :

In this technique, all the possible combinations of the possible outcomes of
conditions are tested at least once. Let’s consider the following example:
● READ X, Y
● IF(X == 0 || Y == 0)
● PRINT ‘0’
● #TC1: X = 0, Y = 0
● #TC2: X = 0, Y = 5
● #TC3: X = 55, Y = 0
● #TC4: X = 55, Y = 5

5. Basis Path Testing :

In this technique, control flow graphs are made from code or flowchart and then
Cyclomatic complexity is calculated which defines the number of independent
paths so that the minimal number of test cases can be designed for each
independent path. Steps:
● Make the corresponding control flow graph
● Calculate the cyclomatic complexity
● Find the independent paths
 ● Design test cases corresponding to each independent path
● V(G) = P + 1, where P is the number of predicate nodes in the flow graph
● V(G) = E – N + 2, where E is the number of edges and N is the total
number of nodes
● V(G) = Number of non-overlapping regions in the graph
● #P1: 1 – 2 – 4 – 7 – 8
● #P2: 1 – 2 – 3 – 5 – 7 – 8
● #P3: 1 – 2 – 3 – 6 – 7 – 8
● #P4: 1 – 2 – 4 – 7 – 1 – . . . – 7 – 8

6. Loop Testing :
Loops are widely used and these are fundamental to many algorithms hence, their
testing is very important. Errors often occur at the beginnings and ends of loops.
● Simple loops: For simple loops of size n, test cases are designed that:
1. Skip the loop entirely
2. Only one pass through the loop
3. 2 passes
4. m passes, where m < n
5. n-1 ans n+1 passes
● Nested loops: For nested loops, all the loops are set to their minimum
count, and we start from the innermost loop. Simple loop tests are
conducted for the innermost loop and this is worked outwards till all the
loops have been tested.
● Concatenated loops: Independent loops, one after another. Simple loop
tests are applied for each. If they’re not independent, treat them like
nesting.
❖ Static Testing :
Introduction to Static Testing :
Static testing is a verification process used to test the application without
implementing the code of the application. And it is a cost-effective process.

To avoid the errors, we will execute Static testing in the initial stage of
development because it is easier to identify the sources of errors, and it can fix
easily.

In other words, we can say that Static testing can be done manually or with the
help of tools to improve the quality of the application by finding the error at the
early stage of development; that is also called the verification process.

We can do some of the following important activities while performing static

testing:

○ Business requirement review

○ Design review
○ Code walkthroughs
○ The test documentation review

Static testing also helps us to identify those errors which may not be found by
Dynamic Testing.

Why do we need to perform Static Testing?

We can perform static testing to fulfill the below aspects:

○ We can use static testing to improve the development productivity.

○ If we performed static testing on an application, we could find the detects in
the earlier stages and easily fix them.
○ The usage of static testing will decrease the testing cost, development
timescales, and time.AD

What are the different features we can test in Static Testing?

We can test the various testing activities in Static Testing, which are as follows:

○ BRD [Business Requirements Document]

○ Functional or system Requirements
○ Unit Use Cases
 ○ Prototype
○ Prototype Specification Document
○ Test Data
○ DB Fields Dictionary Spreadsheet
○ Documentation/Training Guides/ User Manual
○ Test Cases/Test Plan Strategy Document
○ Traceability Matrix Document
○ Performance Test Scripts/Automation

When we performed Static Testing?

To perform static testing, we need to follow the below steps:

Step1: To review the design of the application entirely, we will perform the
inspection process.

Step2: After that, we will use a checklist for each document under review to make
sure that all reviews are covered completely.

We can also implement several activities while performing static testing,

which are discussed in the following table:

Activity Purpose

Architecture Review ○ The architecture review

activities contain all
business-level processes such as
network diagram, load
balancing, server locations,
protocol definitions, test
equipment, database
accessibility, etc.
Use Cases Requirements Validation ○ It is used to authenticate all the
end-user actions along with
associated input and output.
○ If the use case is more
comprehensive and detailed, we
can make more precise and
inclusive test cases.

Functional Requirements Validation ○ The functional requirement

validation activity is used to
make sure that all necessary
elements are identified correctly.
○ And it also took care of the
software, interface listings,
network requirements, hardware,
and database functionality.

Field Dictionary Validation ○ In the field dictionary validation,

we will test each field in the user
interface specified to create
field-level validation test cases.
○ And we can check the fields for
error messages, minimum or
maximum length, list values, etc.

Prototype/Screen Mockup Validation ○ The prototype validation activity

contains the authentication of
requirements and uses cases.
Advantages of Static Testing :
We required Static testing whenever we encounter the following situation while
testing an application or the software:

● Dynamic Testing is time-consuming

We need static testing to test the application as dynamic testing is time-taking
process even though the dynamic testing identifies the bug and provides some
information about the bug.

● Flaws at earlier stages/identification of Bugs

When we are developing the software, we cannot completely rely on Dynamic
testing as it finds the bugs or defects of the application/software at a later stage
because it will take the programmer's plenty of time and effort to fix the bugs.AD

● Dynamic Testing is expensive :

We need to perform the static testing on the software product because dynamic
testing is more expensive than static testing. Involving the test cases is expensive in
dynamic testing as the test cases have been created in the initial stages.

And we also need to preserve the implementation and validation of the test case,
which takes lots of time from the test engineers.

● Increased size of the software :

Whenever we test the software, it will increase the size of the software product,
which we cannot handle because of the reduction in the productivity of code
coverage.

Objectives of Static testing :

The main objectives of performing static testing is as below:

○ Static testing will decrease the flaws in production.

○ Static testing will identify, anticipate and fix the bugs at the earliest possible
time.
○ It is used to save both time and cost.
○ It is used to identify defects in the early stage of SDLC, where we can fix
them easily.
❖ Technical Review : Inspection & Walkthrough

Inspection and walkthrough are methods of software review with distinct

approaches. Inspection is formal, involving detailed group scrutiny to detect
defects early, while walkthrough is informal, where an author presents work to
peers for feedback. Inspection follows structured phases and roles, using
checklists, ensuring thoroughness, while walkthroughs are flexible, focusing on
discussion and feedback without predefined steps. Each method offers unique
benefits in enhancing software quality through early detection and collaborative
improvement processes.
What is Walkthrough?
Walkthrough is a method of conducting informal group/individual review. In a
walkthrough, author describes and explain work product in a informal meeting to
his peers or supervisor to get feedback. Here, validity of the proposed solution for
work product is checked. It is cheaper to make changes when design is on paper
than at time of conversion. Walkthrough is a static method of quality assurance.
Walkthrough are informal meetings but with purpose.
What is Inspection?
An inspection is defined as formal, rigorous, in depth group review designed to
identify problems as close to their point of origin as possible. Inspections improve
reliability, availability, and maintainability of software product. Anything readable
that is produced during the software development can be inspected. Inspections can
be combined with structured, systematic testing to provide a powerful tool for
creating defect-free programs. Inspection activity follows a specified process and
participants play well-defined roles.
An inspection team consists of three to eight members who plays roles of
moderator, author, reader, recorder and inspector.
For example: Designer can acts as inspector during code inspections while a
quality assurance representative can act as standard enforcer.
Difference between Inspection and Walkthrough :

Aspect Inspection Walkthrough

Formality It is formal. It is informal.

 Initiated by the project
Initiation Initiated by author.
team.

Usually team members

A group of relevant
of the same project take
Participant persons from different
part in the walkthrough.
Composition departments participate in
Author himself acts as a
the inspection.
walkthrough leader.

Use of Checklist is used to find No checklist is used in

Checklist faults. the walkthrough.

Walkthrough process
includes overview, little
Inspection processes or no preparation, little
Process include overview, or no preparation
Structure preparation, inspection, examination (actual
and rework and follow up. walkthrough meeting),
and rework and follow
up.

Formalized Formalized procedure in No formalized procedure

Procedure each step. in the steps.
 Inspection takes a longer Shorter time is spent on
Time time as the list of items in walkthrough as there is
Duration the checklist is tracked to no formal checklist used
completion. to evaluate programs.

Planned meeting with the

Meeting
fixed roles assigned to all Unplanned
Structure
the members involved.

Reader reads product Author reads product

Role of code. Everyone inspects it code and his teammate
Reader and comes up with comes up with the
detects. defects or suggestions.

Author makes a note of

Role of Recorder records the
defects and suggestions
Recorder defects.
offered by teammates.

Moderator has a role as

moderator making sure
Informal, so there is no
Moderation that the discussions
moderator.
proceed on the productive
lines.