Another piece in the ‘box method’ of software testing. This time we will be looking at white-box testing, which is also known as structural, clear-box, or glass-box testing to name a few of its aliases.
The name is derived from the concept that the tester can see through the box to the internal workings of the software, which of course is opposite to black-box testing which is purely functional and only deals with the inputs and outputs of the application.
The prerequisite for this type of testing is that the tester needs to be familiar with the programming language and the source code that has been used to develop the software and therefore the task is usually reserved for developers.
This is not an exclusive rule however and testers can collaborate with the development team to help them design effective tests for their code.
The white-box testing technique promotes the following kind of tests:
Think of these as little sections of code that test the code that has just been written.
So let’s assume you have some logic in your code that adds two numbers together. If you wanted to test the logic in the piece of code, you would write a unit test.
return(1 + 2)
An example of a unit test
These tests can help you by providing information on how much of the code is being executed by your test cases and highlighting those parts of your code which are failing to be tested.
Statement coverage – How many lines of the software code being executed?
Branch coverage – This covers the number of decisions (if/else) that the software is taking.
Path coverage – Another method of validating that all paths in a piece of software have been covered. Mostly reserved for complex applications with many decisions.
Real-world applications can have a large number of statements and possible journeys through them meaning that 100% branch and statement coverage can either be very expensive, or highly impractical.
The main advantage of white-box testing is that tests are designed at a granular level and allow for testing of all possible scenarios that may be passed to the software.
Doing the same kind of tests with black-box techniques is not really possible due to the time required to carry out the same tests
Each technique has its own advantages.
Black-box testing allows a tester to test the software from a users perspective. By executing scenarios that cover the intended use, this enables us to test how a user might interact with our software and highlight any bugs and defects that block the software from being released.
White-box testing allows for the internal workings of the software to be examined and the internal journeys tested. This has the advantage of exposing defects in the core logic of the software which would is not possible using black-box testing techniques
However, I personally would not recommend one technique over the other, or claim one is favored over the other.
The reason for this is that each technique tests from a different perspective and ignoring one or the other will reduce your overall test coverage and potentially allow for a greater number of defects to reach your end-users.
There is another member of the ‘box method’ of test techniques which is an amalgamation of both white-box testing, and black-box testing.
The advantage of this technique is that unlike white-box testing in which you need to be very familiar with the internal structure and works of the software. You only need to have partial knowledge to be successful. Freeing up the developers to work on fixing issues, or new features.
Grey box testing is most commonly used in conjunction with automated test tools (like Selenium Webdriver) in which a tester only has partial knowledge of the applications HTML structure. But does not have the knowledge of the system behind the webpage or have access to its design.