Structural testing examines the right execution of internal units, such as program statements, data structures and blocks. This is done through test implementation by monitoring the program behavior related to these specific units.
Software is treated as a white-box, where one can see through to view the internal units and their interconnections. That is why it is generally referred to as white-box testing.
The easiest way of white-box testing is statement coverage testing with the help of using different debugging tools. In this case software tester can understand whether a specific statement has been implemented.
The benefit is that as soon a defect is identified, it is also located. Nevertheless, software bugs of neglect or design bugs cannot be easily identified with the help of white-box testing. The reason is only what is present in the code is tested.
Software tester needs to be very familiar with the code under testing to trace through its implementations. Therefore, white-box testing is normally conducted by the programmers themselves because of their individual knowledge of the specific program unit under software testing. Such double part makes software bug correcting easier as well.
White-box testing can also follow the generic testing process to perform planning, execution and follow-up. Nevertheless, because of the extensive amount of execution information needed, and due to the possibility of combinatorial explosions to cover these execution details, white-box testing is normally limited to a small scale.
For small products, not much formal testing process is needed to plan and execute test cases, and to follow up on execution results.
For unit testing of big products, the white-box testing activities are performed in the encompassing framework where most of the planning is subject to the environment. The environmental constraints pretty much define what can be done.
Consequently, test planning plays a much less significant role in white-box testing than in black-box testing.
Moreover, software bug correcting is made easy by the tight connection between program behavior and program units, and through the double role played by the programmers as testers.
Therefore, not much formal testing process is required. The stopping criteria are also relatively simple: as soon as planned coverage has been reached, testing can stop.