The testing of software application internal infrastructure and coding is referred to as white box testing. White box testing is also called open box testing, clear box testing, transparent box testing, glass box testing, structural testing, or code-based testing [1]. White box testing primarily focuses on the internal structure, design, and implementation of the software with the aim of strengthening security, improving design and usability, and the flows of input and output within the application. When using this approach, the tester concentrates on how the software performs what it is supposed to perform. In order to perform white box testing, a tester should have programming know-how in order for them to understand the code used within the software and understand its implementation. This is because the tester would be testing the software beyond the user interface and going into the nitty-gritty of the application. When conducting white box testing the tester would understand the various lines of code that are being executed and the ones that are not. In case there is a line of code not being executed it means there is missing logic or there is a typo that could lead to negative consequences. This method of testing of testing is referred to as white box because the software application in the eyes of the tester is like a transparent or white box where one can see clearly what is happening. There are two types of testing that a software would undergo namely white box testing and black box testing. Black box testing is testing from an end-user perspective. The names were coined based on the view the tester would have when performing each type of testing. Black box testing does not allow the tester to see the inside of the software. Rather they only interact with the end-user side of the software. Having the different types of testing ensures that the software is vigorously tested before it is launched into the market and any issues discovered can be sorted out.

Performing White Box Testing

When conducting white box testing, the tester is checking the software for:

• Internal security holes.

• Flow of specific inputs.

• Poorly structured paths.

• Expected output.

• Conditional loops functionality.

• Testing each object, statement, and function individually.

The tester would conduct the testing at system, integration, and unit levels of the software. The aim of white box testing is verifying the working flow of the software or application [2]. The tester would have to test using predefined inputs to check the expected outputs. In case a predefined input results in an unexpected output the tester would know there is a bug.

The first step involved in white box testing is understanding the code where the tester has to learn and understand the software's source code. Since white box testing involves testing the inner working of the software, the person testing should have knowledge of the programming language used in the software. Secure coding practices should be at the forefront of the tester's mind, and they need to know and understand them. The tester must be able to find any security issues and prevent attacks because the primary objective of white box testing is securing the software. The tester must also check to ensure that a user might not knowingly or unknowingly inject malicious code within the application.

The second step involved in white box testing is creating test cases and executing the test cases [3]. The tester would be testing the software's code for proper structure and flow. One of the way of conducting this test is by writing additional code for testing the software's source code.

For each process in... This step is mainly done by the developer because it requires the tester to have intimate knowledge of the code.

Types of White Box Testing

There are three main types of white box testing namely:

• Unit testing.

• Integration testing.

• Regression testing.

Unit Testing

A unit test is a level of software testing that test individual components of a software. The aim of unit testing is validating if each component/unit is performing as expected. A component is considered the smallest part of a software that can be tested. The component normally has minimal inputs and a single output. Unit testing is normally the first testing type that is performed on a software. The programmer or developer is the one who conducts unit testing because it is done as the code is being written or developed. The programmer would write some lines of code, a function, or object and conduct a test to determine if they are working before progressing [4]. Conducting a unit test allows for the identification and fixing of bugs early on in the development of software, which makes it easy and cheap to fix the bugs.

Unit testing might seem or sound time consuming, but in the long run, it turns out to be more reliable than developer tests. Conducting test on individual components makes it easy to reuse the codes with confidence that they will work and this does reduce the coding time. Conducting unit testing as the development is ongoing allows for easy troubleshooting because only the most recent changes need to be checked in case there is a bug. A good example would be the manufacture of a ball point pen. Each component is manufactured separately. The components are the cap, body, ink cartridge, ballpoint, and tail. These components need to be checked individually to establish if they are working as expected. Once a component has been manufactured it is tested to see if it works and if it does not then it fails the next process. Only those components that are working would progress to the next stage.

Integration Testing

During this testing stage, individual components are combined together and tested to establish if they produce the desired results. The main aim of this testing is to bring out any faults with the interaction of the integrated units [5]. Integration testing can be performed by the developers or independent tester. When doing integration testing the tester could use different approaches like:

• Big bang.

• Top down.

• Bottom up.

• Sandwich/hybrid.

The big bang approach is where all components are integrated and tested at the same time. This approach is normally used when the software is submitted for testing in one bundle.

It should be noted that the big bang approach only tests the interaction between the units and not the entire software. The Top Down approach is a systematic way of conducting the testing where the tester would start with the top-level units and move down till the last/bottom unit is tested.

This differs with the Bottom Down approach that begins testing from the bottom units heading upwards systematically unit by unit. The Bottom Up approach is only used if the software development was conducted using the bottom-up approach. Finally, the Sandwich/Hybrid approach is a combination of Bottom Up and Top Down approaches.

In order to carry out a successful integration testing the tester should be able to have a detailed document that shows where the interaction of the different units take place. Without this information, the tester would not…