Deepak Kumar

2106606 (CSE-A)

ASSIGNMENT-5
Q1. Difference between Black Box Testing and White Box Testing.
Ans. Black Box Testing

In black box testing, the testing team analyzes the workings of an application without first
having an extensive understanding of its internal structure and design. During testing, the
input value is simply compared with the output value. Due to its nature, black box testing is
sometimes called specification-based testing, closed box testing, or opaque box testing.

Black box testing mainly focuses on the comprehensive examination of application

functionality. It is closely related to behavioral testing; however, behavioral testers may have
limited knowledge of internal application workings.

The black box methodology is used to test most modern software applications. It covers
numerous test cases, allowing maximum bugs to be discovered. This testing method is used at
all stages of the software development cycle.

Black box testing focuses on understanding user experience, which means testers do not
require in-depth technical knowledge to carry it out. It’s a valuable way to provide extensive
testing coverage, especially compared to white box testing, which is sometimes so precise
that testers miss the bigger picture.
This form of testing takes place post-completion of development, and both processes are
independent.

White Box Testing

The software application’s internal coding, design, and structure are examined in white box
testing to verify data flow from input to output. White box testing is leveraged to improve
design, usability, and application security. The other names for this methodology include
code-based testing, glass box testing, open box testing, clear box testing, and transparent box
testing.
Deepak Kumar
2106606 (CSE-A)

Unlike black box testing, which focuses on ensuring a smooth user experience, white box
testing is intensive. Combined with other bug-quashing techniques, it is a robust quality
assurance tool. This methodology is designed to conduct in-depth simulations of all the
scenarios the application might encounter at the code level.

The granularity offered by white box testing is an effective way to crush bugs. This
transparent and rigorous testing approach also gives insights into all the possible outputs the
application can theoretically generate. White box testing is leveraged to spot hidden internal
errors and optimize code.

Difference between Black Box Testing and White Box Testing.

Black Box Testing White Box Testing

It is a way of software testing in which the It is a way of testing the software in which
internal structure or the program or the the tester has knowledge about the internal
code is hidden and nothing is known about structure or the code or the program of the
it. software.

Implementation of code is not needed for Code implementation is necessary for

black box testing. white box testing.

It is mostly done by software testers. It is mostly done by software developers.

No knowledge of implementation is
Knowledge of implementation is required.
needed.

It can be referred to as outer or external It is the inner or the internal software

software testing. testing.

It is a functional test of the software. It is a structural test of the software.

This testing can be initiated based on the This type of testing of software is started
requirement specifications document. after a detail design document.
Deepak Kumar
2106606 (CSE-A)

Black Box Testing White Box Testing

No knowledge of programming is It is mandatory to have knowledge of

required. programming.

It is the behavior testing of the software. It is the logic testing of the software.

It is applicable to the higher levels of It is generally applicable to the lower

testing of software. levels of software testing.

It is also called closed testing. It is also called as clear box testing.

It is least time consuming. It is most time consuming.

It is not suitable or preferred for algorithm

It is suitable for algorithm testing.
testing.

Can be done by trial and error ways and Data domains along with inner or internal
methods. boundaries can be better tested.

Example: Search something on google by Example: By input to check and verify

using keywords loops

Black-box test design techniques-

White-box test design techniques-
 Decision table testing
 Control flow testing
 All-pairs testing
 Data flow testing
 Equivalence partitioning
 Branch testing
 Error guessing

Types of Black Box Testing: Types of White Box Testing:

 Functional Testing  Path Testing
 Non-functional testing  Loop Testing
 Regression Testing  Condition testing

It is less exhaustive as compared to white It is comparatively more exhaustive than

box testing. black box testing.
Deepak Kumar
2106606 (CSE-A)

Q2. Explain Debugging and its various Techniques ?

Ans.

What is Debugging?

Debugging is the process of finding and fixing errors or bugs in the source code of any
software. When software does not work as expected, computer programmers study the code
to determine why any errors occurred. They use debugging tools to run the software in a
controlled environment, check the code step by step, and analyze and fix the issue.

Where did the term debugging originate?

The term debugging can be traced back to Admiral Grace Hopper, who worked at Harvard
University in the 1940s. When one of her colleagues found a moth impeding the operation of
one of the university's computers, she told them they were debugging the system. Computer
programmers were first recorded as using the terms bugs and debugging by the 1950s, and by
Deepak Kumar
2106606 (CSE-A)

the early 1960s, the term debugging was commonly accepted in the programming
community.

Why is debugging important?

Bugs and errors happen in computer programming because it is an abstract and conceptual
activity. Computers manipulate data in the form of electronic signals. Programming
languages abstract this information so humans can interact with computers more efficiently.
Any type of software has several layers of abstraction, with different components
communicating for an application to work correctly. When errors occur, finding and
resolving the issue can be challenging. Debugging tools and strategies help to fix problems
faster and improve developer productivity. As a result, both software quality and the end-user
experience improve.

How does the debugging process work?

The debugging process typically requires the following steps.

Error identification

Developers, testers, and end-users report bugs they discover while testing or using the
software. Developers locate the exact line of codes or code module causing the bug. This can
be a tedious and time-consuming process.

Error analysis

Coders analyze the error by recording all program state changes and data values. They also
prioritize the bug fix based on its impact on software functionality. The software team also
identifies a timeline for bug fixing depending on development goals and requirements.

Fix and validation

Developers fix the bug and run tests to ensure the software continues to work as expected.
They may write new tests to check if the bug recurs in the future.

There are various types of debugging techniquies.

 Brute force method.

 Rubber duck debugging.
 Bug clustering.
 Cause elimination method.
 Backtracking.
 Program slicing.
 Binary searching.
 Static analysis.

Brute force method

The most common debugging strategy is likely the brute force method—despite also being
the least efficient.
Deepak Kumar
2106606 (CSE-A)

As the name suggests, this method lacks an organized, structured approach to resolving
software bugs.
Instead, developers step through the code, trying various fixes until they stumble across a
resolution.
The graph below visualizes the general process

Rubber duck debugging

In a recent Reddit thread, one user posted a photo of their CTO‘s debugging process.
Here’s the image:
Deepak Kumar
2106606 (CSE-A)

Although this picture seems absurd to those who aren’t in the know, there’s a good reason
behind it.
This developer is employing rubber duck debugging—a debugging technique where you
explain the bug to a rubber duck, or at least someone who has no prior knowledge of the issue
that’s troubling you.
Sometimes the easiest way to get to the bottom of the problem is to attack it from a new
angle. Rubber duck debugging facilitates this, as you must use plain language to describe the
defect.
As you articulate the issue to the rubber duck, you’ll walk through all its particulars and
hopefully realize your mistake in the process.
Experienced developer David Hayes has also commented on this, emphasizing the
differences in how humans and computers operate:

Bug clustering

You’ll likely encounter similar errors in your software (e.g., your app crashing in several
different locations).
While debugging, it’s helpful to group these comparable bugs together—a practice known
as bug clustering.
The reasoning is simple: by examining seemingly-related defects, you should quickly arrive
at their resolution.
A recent publication can explain why:
Deepak Kumar
2106606 (CSE-A)

Cause elimination method

Perhaps the most scientific debugging strategy, the cause elimination method employs
deductive techniques to resolve software bugs.

The first step is creating a list of all possible reasons for the defect. They don’t need to be
entirely rationalized—they’re just theories to help assess the situation.

Then, test each hypothesis one by one. As you analyze your codebase, you’ll eliminate
possible causes as you go and should be left one with one sole possible reason.

If that remaining theory is vague, now is the time to refine it further. After that, you should be
able to prove it and solve the software bug.

The image below visualizes the process:

Deepak Kumar
2106606 (CSE-A)

Backtracking

If you’re working in a smaller codebase, backtracking is your ideal debugging method.

To solve bugs via backtracking, start your debugging efforts where the program gives the
incorrect result. From there, retrace your steps, mentally executing the program in reverse.
That way, you’ll determine the state of the software (or values of all its variables) during the
preceding steps.
With this strategy, you should find the bug’s exact location: between where the program’s
state was as expected and the initial starting point, which gave the incorrect result.
Equipped with this information, solving the defect should be much easier.

Binary searching

Similar to program slicing, binary searching also dissects your code into sections. However,
instead of focusing on variables, you’ll search the codebase in halves.
The first step is determining the part of the program hosting the bug—its surface area.
Once you know that, divide the affected code into two halves, and identify which half
contains the bug.
From there, repeat the process, again splitting the code into halves and again diagnosing the
half with the bug.
Then just repeat the procedure until the code portion is small enough it’s obvious where the
defect resides.
The visual below depicts a simplified representation of the process:
Deepak Kumar
2106606 (CSE-A)

Static analysis

Last but not least, static analysis is our final, and perhaps most theoretical, debugging
method.
When using this strategy, developers examine the code in a static environment—without
executing the program or running it through any compilers or debuggers.
While doing so, they also compare the code against coding rules and best practices.

Differences Between Testing and Debugging

Testing Debugging

Testing is the process to find bugs and Debugging is the process of correcting the
errors. bugs found during testing.

It is the process to identify the failure of It is the process to give absolution to code
implemented code. failure.

Testing is the display of errors. Debugging is a deductive process.

Debugging is done by either programmer

Testing is done by the tester.
or the developer.

There is no need of design knowledge in Debugging can’t be done without proper

the testing process. design knowledge.
Deepak Kumar
2106606 (CSE-A)

Testing Debugging

Testing can be done by insiders as well as Debugging is done only by insiders. An

outsiders. outsider can’t do debugging.

Debugging is always manual. Debugging

Testing can be manual or automated.
can’t be automated.

It is based on different testing levels i.e.

Debugging is based on different types of
unit testing, integration testing, system
bugs.
testing, etc.

Debugging is not an aspect of the software

Testing is a stage of the software
development life cycle, it occurs as a
development life cycle (SDLC).
consequence of testing.

While debugging process seeks to match

Testing is composed of the validation and
symptoms with cause, by that it leads to
verification of software.
error correction.

Testing is initiated after the code is Debugging commences with the execution
written. of a test case.

Testing process based on various levels of

Debugging process based on various types
testing-system testing, integration testing,
of bugs is present in a system.
unit testing, etc.