⬜White Box Testing
Last updated
Last updated
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.
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:
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.
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.
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.
Following are the significant differences between white box testing and black box testing:
White-box testing | Black box testing |
---|---|
The developers can perform white box testing. | The test engineers perform the black box testing. |
To perform White Box Testing, we should have an understanding of the programming languages. | To perform Black Box Testing, there is no need to have an understanding of the programming languages. |
In this, we will look into the source code and test the logic of the code. | In this, we will verify the functionality of the application based on the requirement specification. |
In this, the developer should know about the internal design of the code. | In this, there is no need to know about the internal design of the code. |
Each statement in the code is executed at least once. This ensures that each line of code is executed.
If the code is:
A test case would simply execute all 4 statements.
Each decision point (if/else, switch case, etc.) in the code is tested so that both paths (true and false branches) are executed.
If the code is:
Two test cases would be:
a > b is true
a > b is false
Each boolean condition in if/else statements, while loops, etc. is tested for both true and false values.
If the code is:
Test cases would be:
age = 19
age = 17
All possible paths through the code are tested. This achieves high coverage but can be difficult to implement for complex code.
All loops in the code are tested for a minimum of 0, 1 and multiple iterations. Loop boundaries and conditions are also tested.
For a while loop:
Test cases would be:
i = 0 (loops 10 times)
i = 5 (loops 5 times)
i = 10 (loops 0 times)
Tests are designed based on definition-use pairs of variables to ensure all definitions and uses of variables are exercised.
For code with variables:
Test cases would test the definition of a, and the uses of a in b and c.
Complex logical expressions are evaluated for all possible logical combinations of inputs.
For a complex logical expression:
Test cases would evaluate all combinations of a,b,c,d.