What is a White Box Testing Strategy?

White box testing strategy deals with the internal logic and structure of the code. White box testing is
also called as glass, structural, open box or clear box testing. The tests written based on the white box
testing strategy incorporate coverage of the code written, branches, paths, statements and internal logic
of the code etc.

In order to implement white box testing, the tester has to deal with the code and hence is needed to
possess knowledge of coding and logic i.e. internal working of the code. White box test also needs the
tester to look into the code and find out which unit/statement/chunk of the code is malfunctioning.

Advantages of White box testing are:

i) As the knowledge of internal coding structure is prerequisite, it becomes very easy to find out which
type of input/data can help in testing the application effectively.
ii) The other advantage of white box testing is that it helps in optimizing the code
iii) It helps in removing the extra lines of code, which can bring in hidden defects.

Disadvantages of white box testing are:

i) As knowledge of code and internal structure is a prerequisite, a skilled tester is needed to carry out
this type of testing, which increases the cost.
ii) And it is nearly impossible to look into every bit of code to find out hidden errors, which may create
problems, resulting in failure of the application.

Types of testing under White/Glass Box Testing Strategy:

Unit Testing:
The developer carries out unit testing in order to check if the particular module or unit of code is
working fine. The Unit Testing comes at the very basic level as it is carried out as and when the unit of
the code is developed or a particular functionality is built.

Static and dynamic Analysis:

Static analysis involves going through the code in order to find out any possible defect in the code.
Dynamic analysis involves executing the code and analyzing the output.

Statement Coverage:
In this type of testing the code is executed in such a manner that every statement of the application is
executed at least once. It helps in assuring that all the statements execute without any side effect.

Branch Coverage:
No software application can be written in a continuous mode of coding, at some point we need to
branch out the code in order to perform a particular functionality. Branch coverage testing helps in

1|Page
validating of all the branches in the code and making sure that no branching leads to abnormal behavior
of the application.

Security Testing:
Security Testing is carried out in order to find out how well the system can protect itself from
unauthorized access, hacking – cracking, any code damage etc. which deals with the code of application.
This type of testing needs sophisticated testing techniques.

Mutation Testing:
A kind of testing in which, the application is tested for the code that was modified after fixing a
particular bug/defect. It also helps in finding out which code and which strategy of coding can help in
developing the functionality effectively.

Besides all the testing types given above, there are some more types which fall under both Black box
and White box testing strategies such as: Functional testing (which deals with the code in order to check
its functional performance), Incremental integration testing (which deals with the testing of newly
added code in the application), Performance and Load testing (which helps in finding out how the
particular code manages resources and give performance etc.) etc.

What is white box testing?

White box testing traditionally refers to the use of program source code as a test basis, that is, as the
basis for designing tests and test cases. (IEEE standards define a test as "a set of one or more test
cases.") A looser definition says that "white box testing is based on internal structures of the software",
but it is very unclear what kinds of "internal structure" are covered by this. Some authorities, for
example, include user-facing menus and even business processes. The term "gray box testing" is now in
widespread use for internal software structures that are not actually source code - for example, class
hierarchies or module call trees. In the following discussion, "white box testing" is held to be
synonymous with "code-based testing."
Those two terms are opposed to "requirements-based" or "specification-based" testing, also known as
black box testing. The implication there is that you can't see the inner workings of a black-painted box;
and in fact, you don't need to see the inner workings to test whether a given set of inputs results in the
required or specified set of outputs. But if you do need to test the inner workings, painting the box
white would leave them just as invisible as when the box was black, so the terms "clear box testing" and
"glass box testing" are also used. (The word "analysis" is sometimes used in place of "testing.")
White-box testing usually involves tracing possible execution paths through the code and working out
what input values would force the execution of those paths. Quite simple techniques exist by which the
tester (usually the developer who wrote the code) can work out the smallest number of paths necessary
to test, or "cover," all the code. Some types of static analysis tool will do the same job, more quickly and
more reliably.
White box testing, on its own, cannot identify problems caused by mismatches between the actual
requirements or specification and the code as implemented but it can help identify some types of design
weaknesses in the code. Examples include control flow problems (e.g., closed or infinite loops or
unreachable code), and data flow problems (e.g., trying to use a variable which has no defined value).
Static code analysis (by a tool) may also find these sorts of problems, but doesn't help the

2|Page
tester/developer understand the code to the same degree that personally designing white-box test
cases does.
White box testing is usually associated with component testing (i.e., unit testing), and with the concept
that, at minimum, 100% of the component's code statements should be tested before the component is
released for use ("100% code coverage"). But it may be dangerous to design white box test cases simply
to achieve such a standard. This is not only because it will miss disconnects between code and
specifications, but because the test cases are often artificial and unrepresentative of how the
component will actually be used. The test cases may even be impossible to execute (corresponding to
"unachievable" or "infeasible" paths. A tool will avoid generating these).
A better approach may be to design enough test cases to cover all requirements specified for the
component (black box testing), then use a code coverage monitor to record how much of the code is
actually covered (executed) when the test cases are run. Often, the code will fall into two parts: code
statements that correspond directly to the requirements and get covered by the black box test cases;
and code statements that deal with aspects of the target execution environment, which may not be
explicitly specified but which the developer is expected to provide. This second type of code often
provides error handling for exceptions thrown by hardware or software conditions (e.g., by a database
management system), and often goes untested - which may cause severe problems when such an
exception occurs in live use. The developer would use white box techniques to work out how to drive
the testing of those statements not covered by the black box test cases.

What is a Black Box Testing Strategy?

Black Box Testing is not a type of testing; it instead is a testing strategy, which does not need
any knowledge of internal design or code etc. As the name "black box" suggests, no knowledge
of internal logic or code structure is required. The types of testing under this strategy are totally
based/focused on the testing for requirements and functionality of the work product/software
application. Black box testing is sometimes also called as "Opaque Testing",

3|Page
"Functional/Behavioral Testing" and "Closed Box Testing".

The base of the Black box testing strategy lies in the selection of appropriate data as per
functionality and testing it against the functional specifications in order to check for normal and
abnormal behavior of the system. Now a days, it is becoming common to route the Testing
work to a third party as the developer of the system knows too much of the internal logic and
coding of the system, which makes it unfit to test the application by the developer.

In order to implement Black Box Testing Strategy, the tester is needed to be thorough with the
requirement specifications of the system and as a user, should know, how the system should
behave in response to the particular action.

Various testing types that fall under the Black Box Testing strategy are: functional testing, stress
testing, recovery testing, volume testing, User Acceptance Testing (also known as UAT), system
testing, Sanity or Smoke testing, load testing, Usability testing, Exploratory testing, ad-hoc
testing, alpha testing, beta testing etc.

These testing types are again divided in two groups: a) Testing in which user plays a role of
tester and b) User is not required.

Testing method where user is not required:

Functional Testing:
In this type of testing, the software is tested for the functional requirements. The tests are
written in order to check if the application behaves as expected.

Stress Testing:
The application is tested against heavy load such as complex numerical values, large number of
inputs, large number of queries etc. which checks for the stress/load the applications can
withstand.

Load Testing:
The application is tested against heavy loads or inputs such as testing of web sites in order to
find out at what point the web-site/application fails or at what point its performance degrades.

Ad-hoc Testing:
This type of testing is done without any formal Test Plan or Test Case creation. Ad-hoc testing
helps in deciding the scope and duration of the various other testing and it also helps testers in
learning the application prior starting with any other testing.

Exploratory Testing:
This testing is similar to the ad-hoc testing and is done in order to learn/explore the application.

Usability Testing:

4|Page
This testing is also called as ‘Testing for User-Friendliness’. This testing is done if User Interface
of the application stands an important consideration and needs to be specific for the specific
type of user.

Smoke Testing:
This type of testing is also called sanity testing and is done in order to check if the application is
ready for further major testing and is working properly without failing up to least expected
level.

Recovery Testing:
Recovery testing is basically done in order to check how fast and better the application can
recover against any type of crash or hardware failure etc. Type or extent of recovery is specified
in the requirement specifications.

Volume Testing:
Volume testing is done against the efficiency of the application. Huge amount of data is
processed through the application (which is being tested) in order to check the extreme
limitations of the system.

Testing where user plays a role/user is required:

User Acceptance Testing:

In this type of testing, the software is handed over to the user in order to find out if the
software meets the user expectations and works as it is expected to.

Alpha Testing:
In this type of testing, the users are invited at the development center where they use the
application and the developers note every particular input or action carried out by the user.
Any type of abnormal behavior of the system is noted and rectified by the developers.

Beta Testing:
In this type of testing, the software is distributed as a beta version to the users and users test
the application at their sites. As the users explore the software, in case if any exception/defect
occurs that is reported to the developers.

What is a Black Box Testing?

A black box is any device whose workings are not understood by or accessible to its
user. According to Edward Tenner, writing in The Washington Post, the first black box was a gun
sight carried on World War II Flying Fortresses, with hidden components that corrected for
environmental variables, such as wind speed. The crew probably didn't know how the device
worked, but they knew it might be crucial to their survival. Nowadays, there are two types of

5|Page
black box carried on aircraft, which may be combined into a single device: a flight data recorder
(FDR), which logs information such as speed and altitude, and a cockpit voice recorder (CVR),
which logs all voice communication in the cockpit. These black boxes also carry beacons to help
find the aircraft in a rescue situation.
A sampling of other black boxes:
• In telecommunications, a black box is a resistor connected to a phone line that makes it
impossible for the telephone company's equipment to detect when a call has been
answered.
• In data mining, a black box is an algorithm or a technology that doesn't provide an
explanation of how it works.
• In software development, a black box is a testing method in which the tester has no
knowledge of the inner workings of the program being tested. The tester might know
what is input and what the expected outcome is, but not how the results are achieved.
A black box component is a compiled program that is protected from alteration by
ensuring that a programmer can only access it through an exposed interface.
• In film-making, a black box is a dedicated hardware device: equipment that is specifically
used for a particular function.
• In the theatre and television, a black box is an unfurnished studio.
• In the financial world, a black box is a computerized trading system that does not make
its rules easily available.
Perhaps because the metaphor is broadly applicable, black box is sometimes used to refer to
anything that works without its inner workings being understood or accessible for
understanding.
Learn more about Software testing models and approaches (Context-driven, Factory,
Analytic, Quality, IV&V)

Why automated software testing fails and pitfalls to avoid: Chapter 4 from published title "Why
Automated Software Testing Fails and Pitfalls to Avoid" offers new takes on automated R&D,
software development considerations and much more.
Agile software development tutorial: Agile testing: In this section of our agile tutorial, learn how
to be a successful software tester in an agile environment, from tips on test development to
exploratory testing techniques.
Software testing fundamentals: Testing basics: Software testing experts weigh in on creating test
plans, writing test cases, choosing test models and other basic building blocks of software
testing.
Rich Internet applications security testing checklist: Fix common RIA and Web 2.0 application
problems caused by Ajax, Flash and other technologies with these tips.
Seven steps for a quality change and configuration management program: This tip outlines
several ways to ensure you have a topnotch change and configuration management (CCM)
division on your project team which is vital in protecting software code.

6|Page
7|Page