White Box Testing

The software development process involves understanding customer requirements, analysing them for feasibility, followed by designing, coding, testing and implementation.

Testing is a crucial step of the software development cycle as it ensures that all the requirements have been converted into a successful end product.

The decision of choosing the right approach for testing a software is critical. Ideally, the approach should be a healthy mix of various techniques to cover all possible scenarios. The two most commonly used approaches are White Box and Black Box testing.

White box testing requires the tester to know all the functional and design details of the module/code that is being tested. The tester needs to have in-depth knowledge of the requirements, design and even code, as well as the desired outcome.

Black Box Testing, also known as functionality testing or behavioural testing, essentially requires the testers to evaluate the functionality of the software without looking at details of the code.

In this article, we will explore the fundamentals of White Box testing and its importance in testing any software.

White-Box testing

White-box testing is used to test the structure and business logic of the program being developed.

In order to test the code thoroughly, the testing professional needs to have good knowledge of the programming language, the set standards for the code and design fundamentals. Since they have full access to the code, it is important for them to know the details of the software development process, before the testing commences.

White-Box Testing is known by several other names, like, Glass box testing, Clear Box testing, Open Box testing, Structural testing, Path Driven Testing or Logic driven testing.

Testing can be done using either Static or Dynamic approach. Static/Dynamic refers to the state of system under test (running/dynamic, or stopped/static).

Static Analysis requires code walk through by various stakeholders, who read and analyse code for possible defects or deviation from desired functioning. This process also ensures that the code has been developed following defined processes and standards of the Organization. It is also called Structural Analysis or Verification.
Dynamic Analysis involves executing and analysing the code in a test environment. It focus on behaviour. Since dynamic testing validates the outcomes, it is also known as Validation.

White Box testing largely follows the Dynamic approach of testing.

White-Box Testing Process

White box testing follows a process, wherein each aspect of the software is tested thoroughly by the testing team to ensure its quality and adherence to expected norms.

The process for White box testing at any level of testing is more or less the same and involves the following steps:

Understand the languages and tools used in development of the software
Understand the Source Code
Write test cases for every flow and coverage possibility
Execute test cases.
Analyse and record the results

White Box Testing at various levels of the Testing Process

White-box testing can be applied at the Unit, Integration and System levels of the software testing process.

The diagram below provides an idea about the levels at which White Box Testing can be applied.

White Box Testing at Unit Testing Level

Unit testing is done at the basic level, as and when the programmer develops a fully functional module, aka unit of code. The module is tested independent of other modules or sub modules. It has its own set of inputs specific to the function it is expected to perform.

White Box testing at Unit Test Level involves different types of testing. Some important approaches are discussed below:

Execution Testing: It involves deep checking the code to ensure all possible aspects have been covered. It involves:
- Statement Coverage: Statement Coverage is a White Box Test design technique which ensures that each and every line of code has been executed at least once.
- Branch/Decision coverage: Branch coverage is a testing technique which ensures that each and every decision making point and its possible outcomes have been tested at least once with different input parameters.
- Path coverage: Path Coverage ensures that each and every path of the code has been traversed at least once. It is imperative to ensure that all segments of Control structures have been covered for a complete path coverage.
- Loop coverage: Loop coverage ensures that all loops have been executed zero times, at least once or more than once within their boundary values. It is important to test the exit condition of the loop for these cases.
- Data Structures Test: All data structures have to be tested for extreme conditions. For example: Stack overflow issues sometimes go undetected if not handled properly.
Functional Testing – The Functional Testing technique involves testing the functionality of the code segment based on specific inputs to verify and validate the expected outputs.
Mutation Testing – Every time a code is fixed to rectify a bug, there are chances of introducing another bug. Mutation testing looks into such scenarios.

White Box Testing at the Integration Level

White box testing at the integration level focuses on testing the interfacing between various modules to ensure that they work in tandem with each other to produce the desired results. It can be done as and when fully functional modules or sub modules are completed.

Integration testing can be done using the following approaches:

Top-Down Approach: In this type of testing, the high-level modules are tested first and then low-level modules. Finally the low-level modules are integrated with a high level module to ensure that the system is working as intended. Stubs are used in case low level modules are not ready at time of testing. Stubs simulate the functionality of an actual software module.
Bottom-Up Approach: In this type of testing, the lowest level modules are tested first and then high-level modules. Finally integrating them to ensure proper system flow. In case a higher level module is not ready at the time of testing, then Driver modules are used to invoke the module under test by providing test inputs.
Hybrid (Top and Bottom Combined) Approach

There are times when new modules are added to address the new requirements or reflect changes in functionality. Incremental integration testing is performed to test the seamless integration of these new/changed modules.Read for more about :https://www.webomates.com/blog/manual-testing/white-box-testing/