Black and White Box Testing
Black and White Box Testing
Black box testing involves testing a system with no prior knowledge of its internal workings. A
tester provides an input, and observes the output generated by the system under test. This makes it
possible to identify how the system responds to expected and unexpected user actions, its response
time, usability issues and reliability issues.
Black box testing is a powerful testing technique because it exercises a system end-to-end. Just
like end-users “don’t care” how a system is coded or architected, and expect to receive an
appropriate response to their requests, a tester can simulate user activity and see if the system
delivers on its promises. Along the way, a black box test evaluates all relevant subsystems,
including UI/UX, web server or application server, database, dependencies, and integrated
systems.
An example of a security technology that performs black box testing is Dynamic Application
Security Testing (DAST), which tests products in staging or production and provides feedback on
compliance and security issues.
Pros Cons
Many practitioners combine black box testing with white box testing. White box testing involves
testing an application with detailed inside information of its source code, architecture and
configuration. It can expose issues like security vulnerabilities, broken paths or data flow issues,
which black box testing cannot test comprehensively or at all.
By combining black box and white box testing, testers can achieve a comprehensive “inside out”
inspection of a software application and increase coverage of quality and security issues.
While white box testing assumes the tester has complete knowledge, and black box testing relies
on the user’s perspective with no code insight, grey box testing is a compromise. It tests
applications and environments with partial knowledge of internal workings. Grey box testing is
commonly used for penetration testing, end-to-end system testing, and integration testing.
You can perform grey box testing using Interactive Security Testing (IAST) tools. IAST tools
combine DAST and Static Application Security Testing (SAST), which is used in white box
testing to evaluate static code. IAST tools enable you to combine the work of testers and developers
and increase test coverage efficiently. For example, you are able to perform more directed tests
which focus on areas or user paths that are most likely to contain flaws.
By combining these two testing methods you can ensure that tests:
Functional Testing
Black box testing can test specific functions or features of the software under test. For example,
checking that it is possible to log in using correct user credentials, and not possible to log in using
wrong credentials.
Functional testing can focus on the most critical aspects of the software (smoke testing/sanity
testing), on integration between key components (integration testing), or on the system as a whole
(system testing).
Non-Functional Testing
Black box testing can check additional aspects of the software, beyond features and functionality.
A non-functional test does not check “if” the software can perform a specific action but “how” it
performs that action.
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.
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:
o 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.
o 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.
The white box testing contains various tests, which are as follows:
o Path testing
o Loop testing
o Condition testing
o Testing based on the memory perspective
o Test performance of the program
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.
Loop testing
In the loop testing, we will test the loops such as while, for, and do-while, etc. and also check for
ending condition if working correctly and if the size of the conditions is enough.
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.
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.
Condition testing
Testing based on the memory (size) perspective
Test the performance (Speed, response time) of the program
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.
Control Control flow testing determines the execution order of statements or instructions of the program through a
Flow Testing 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. Test cases
represented by the control graph of the program.
Branch Branch coverage technique is used to cover all branches of the control flow graph. It covers all the possible
Testing outcomes (true and false) of each condition of decision point at least once.
Statement Statement coverage technique is used to design white box test cases. This technique involves execution of all
Testing 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.
Decision This technique reports true and false outcomes of Boolean expressions. Whenever there is a possibility of two
Testing or more outcomes from the statements like do while statement, if statement and case statement (Control flow
statements), it is considered as decision point because there are two outcomes either true or false.
Difference between white-box testing and black-box testing
Following are the significant differences between white box testing and black box testing:
The developers can perform white box testing. The test engineers perform the black box testing.
In this, we will look into the source code and test In this, we will verify the functionality of the application
the logic of the code. based on the requirement specification.
In this, the developer should know about the In this, there is no need to know about the internal design
internal design of the code. of the code.