Testing the software at different levels helps us deliver quality software. White Box Testing is the stage where we check if the software meets our requirements.
Testing the UI functionalities of software alone can’t contribute to quality software; we also need to test the internal structural design and code structure also.
There are two types of testing that will be performed when any software is developed: White Box Testing and Black Box Testing.
Both White Box Testing and Black Box Testing are part of the software development life cycle. Black Box Testing focuses more on usability and how the user uses it, while White Box Testing focuses more on the code perspective.
White Box Testing works on the source code, and Black Box Testing is performed on the application. Now let’s see what White Box Testing is, why it is performed, and how it is performed.
Once the software is developed, and the coding is completed, developers will perform White Box Testing to ensure each and every line of code is optimized to ensure the totality of the source code. White Box Testing is also known as Open Box Testing, Clear Box Testing, Glass Box Testing, Transparent Box Testing, and Structural Testing.
Here are the White Box Testing Types
Path Testing
Conditional Testing
Loop Testing
Unit Testing
Testing the code from a memory point of view.
Testing the code from a performance point of view.
Each White Box Testing type is important and has its own advantages.
1. Path Testing
Path Testing is also called Cyclomatic Complexity as per ISTQB (International Software Testing Qualification Board). In this type of testing, developers will write the flow chart and test each and every individual path, hence the name Path Testing.
Example:
Paths for the above flow:
Path1: main program()—fun1()—fun4()
Path2: main program()—fun1()—fun5()
Path3: main program()—fun2()—fun6()
Path4: main program()—fun2()—fun7()
Path5: main program()—fun3()
In this example, we see all the paths and flows of WhatsApp:
In WhatsApp, the developer will write the flowchart by identifying each individual path. developers will set the parameters for the main program and start to test every individual path.
If developers find any defect while testing, they will fix the defect and retest the entire path. This is how developers perform Path Testing.
2. Conditional Testing Type
Conditional Testing is also called Predicate Testing as per ISTQB.
Here, developers test for logical conditions that are testing for both true and false conditions. Example below:
In the above example, there is a defect in the red-marked condition. White Box Testing can identify these types of conditional defects in the early stages so that defects will not flow.
3. Loop Testing Type
Loop Testing evaluates the loops (while, for, do-while), ensures loops repeat for all the defined number of cycles, and ensures that the terminating condition is properly working.
According to the above example, the loop will repeat 10 times. While testing, if developers know that loop is repeating only 5 times and the 6th time, the loop is failing, there is a defect. The defect will be fixed, and the loop will be tested until the loop is repeated 10 times.
Suppose the loop is written 1000 times. Testing the loop manually 1000 times is a tough job. The developer may choose to automate this loop’s testing.
In unit testing, developers create a test program that corresponds to the main program that will test the main program and provide the result as Pass or Fails. The collection of all the test Programs is called Unit Test Suite/Unit Test Cases.
Let us take the example of the below image to understand more about Unit Testing.
According to the above example, the customer will give the requirement for modules A, B, and C, and developers will write the code correspondingly for main program A, main program B, and main program C. Once coding is completed, the developer will manually test each and every line of the main program. After testing is completed, suppose the customer changes the requirement, the main program will be updated and should test all the main programs manually.
If we observe here, the developer spends more time testing than writing the code. In order to overcome this problem, the developer will choose Unit Testing.
While doing Unit Testing, a developer might find an error in the code. There are 3 common cases of this below:
Case 1: If there is an error in the test program, the developer will fix the error in the test program and run the test program against the main program.
Case 2: If there is an error in the main program, the developer will fix the error in the main program and run the corresponding test program against the main program. Chances are there fixing errors in the main program might impact other main programs. So, the developer will run the entire unit test suite.
Case 3: If the customer changes the requirement for module C, there will be changes in the corresponding main program C, test program C, and run the test program C against the main program C. Chances are that changing the requirement for module C might impact other two modules, so the entire unit test suite has to be run to make sure that there are no errors.
5. Testing the Code From a Memory Point of View
In this type of White Box Testing, we recommend the following best practices:
By changing the logic of the code, we can improve memory because writing logic varies from person to person. If the code written by Dev1 takes 400 MB and Dev2 takes 200 MB, the code written by Dev2 will be preferred.
If there are duplicate codes or repetition of the same code, then we will convert the code into user-defined functions or generic functions.
Remove unused commands and unwanted functions from the program.
Remove dead code from the program. (Dead code refers to unused code in the program)
Use Built-In functions.
Remove unused variables.
6. Testing the Code from a Performance Point of View
By writing efficient logic, we can improve performance. Also, instead of using nested if, switch statements or switch cases can be used. AND and OR operators should be properly used while writing conditions.
In White Box Testing, the Tester will look inside from the outside; that is, the tester will test the internal structure and code of the software. The tester will verify each and every line of code from all perspectives, including memory, load, and accuracy.
Final Thoughts
White Box Testing has to be performed to make sure that each path is thoroughly tested and has no duplicates. Defects can be identified in the early stages. The downward flow of defects can be avoided and we can make sure that the code is working for both true and false conditions. White Box Testing tests the source code. These test cases are derived using the design techniques mentioned above. These are the building blocks of White Box Testing that prevent defects in the downward flow. Different techniques make it easy to minimize errors and help us to create error-free software.
I hope the article helped you to understand White Box Testing.
Sri Priya P. Kulkarni is a test engineer with a focus on the full system development life cycle. Certified in ISTQB, Scrum, and Six Sigma, she currently works at American Express in Bengaluru, creating test cases, executing tests, and reporting defects. She often shares on her LinkedIn and website.