Which White Box Testing Technique is Best? (Examples)
If you are preparing for your ISTQB, or genuinely curious about the best white-box techniques prior to starting an up-coming test phase, then I have prepared some info to help you decide the best white-box testing approach.
Which white-box testing is best? The best white box testing technique is a combination of a decision based which is also run dynamically (more on this later). Because you have the potential of high test coverage with the ability to analyze how the code actually behaves.
Now that you understand which technique is best, in my opinion, let me go on to explain exactly what white-box testing is, the advantages, disadvantages, types, how it can be measured and much more.
What is white-box testing?
what is white box testing
White-box testing is effectively the opposite of black-box testing. It focuses on the internal structure of a test object, rather than just analyzing the inputs and outputs.
This comes down to analyzing the actual code of the software-based on a detailed design or equivalent specification document.
What are the advantages of White-box testing?
Now that you have a general idea of what this technique is, you may be wondering what the point of it is. Why should you even care about it, right? Well, let me explain some of the
This testing technique is ideal for improving the efficiency of the code, as well as spotting clear errors before getting into further phases of testing.
In my experiences of testing, developers are sometimes hesitant to do this, with the attitude that they are not testers. But, in my opinion, this is the mark of a great developer who truly checks his work before throwing it over the fence to the testers (so to speak).
Disadvantages of White-box testing?
Like most things, there are always set-backs with every technique. So, in this section, I will explain some of the disadvantages of this testing technique.
Firstly, whilst it’s a great way to weed out erroneous code early on in the Software Development lifecycle (SDLC). It relies on your organization having skilled developers that can perform the tests.
Usually, it the actual developer who wrote the code in the first instance that actually executes the tests, so you can guess the level of expertise required here.
The point I am getting at here is the cost. To do this correctly you need a decent budget for a skilled resource.
Impossible to catch everything
Whilst this technique helps to improve the code, prior to getting into later stages of testing, such as system testing, etc. It needs to be said, to set your expectation, that it is impossible to catch every potential defect at this level. In fact, ever, throughout any testing stage for that matter.
Don’t get me wrong, it’s worth the investment, but it is worth explaining this upfront.
Types of White-box testing
In this section, I will now explain some of the actual white-box techniques that can be used. According to the ISTQB syllabus, this testing can occur at any test level. However, I will explain some of the most common techniques used.
White-box testing is typically performed by a developer at a code unit test level using one of the following techniques:
- Statement based
- Decision-based
Statement based
The statement based technique focuses on the individual lines of code to be delivered. The idea is to analyze the actual lines of code in the software program and have tests that verify these lines.
Decision-based
Decision-based techniques are slightly different. Instead of focussing on the lines of code it revolves around the conditions in the code. When I say conditions, I mean the decisions, for example, IF or case statements.
As you can imagine there are many conditions within code that will create many permutations.
Static vs Dynamic
Whether you use statement or decision-based techniques there is another choice to make. This is how you will actually execute these tests. For this there are two choices:
- Static
- Dynamic
Static
Static is a manual approach. This relies on the developer going through the code and eyeballing the code to see obvious errors. This can be done by the creator of the code.
But, it is more effective if it is done by a different developer with a similar skill set. These reviews are typically called peer reviews.
The benefit of the peer review is; it introduces fresh eyes. Often a developer will overlook obvious issues because they have simply spent too much time steering at the code. Whereas a new pair of fresh eyes will look at it from a different angle.
This is an opportunity for the reviewer to not only spot obvious errors but also suggest smarter or more efficient ways of doing things.
Dynamic
Dynamic is the opposite. This comes down to running the code and analyzing the outputs. This gives the developer the opportunity to compare the outputs to what’s expected from the specification.
This is a really effective method because the software can be complicated and even the most experienced developer may be surprised with output that seems to look perfect until it is dynamically run.
How can white-box testing be measured?
Understanding the concept of white-box testing is one thing, but grasping how to measure it is another. And, arguably one of the most important factors that will govern the next stage of your test object. For that reason, I will explain how this is done for statement & decision-based techniques.
Statement based measurement
For statement-based testing, the lines of code is the main focus, as discussed earlier. Therefore, for this method, the total lines of code (statements) are compared to the total tests that execute these lines.
The coverage is typically expressed as a percentage of statements executed to total statements of code.
Decision-based measurement
For decision-based testing, the conditions (decisions) in the code is the main focus, as discussed earlier. Therefore, the coverage is based on this metric.
In particular, the total number of decisions executed by the tests is expressed as a percentage of the total number of decisions.
Special skills and knowledge requirements
With this intricate testing, you can expect that it will require a certain level of skills to get it right. For that reason, in this section, I will explain exactly what level of skills you will expect to have.
White-box testing requires a resource that fully understands the code structure of the test object. In reality, every code object is different, so each skilled resource will develop their own unique expertise in one particular area of the system.
Either way, to begin with, you need a technical low-level coding resource that can do this task correctly. In reality, it doesn’t necessarily have to be a developer, but in my experience is nearly always is.
Related Questions:
In this section, I will answer some questions related to white-box testing. If you have some additional questions that are not answered here please drop a comment below.
Q: What is the difference between white and black-box testing?
White-box focuses on the internal structure of a test object. Whereas in black-box testing, the internal structure is not important. All that matters are the inputs and outputs meet the specification.
Also, with black-box testing, you would expect testers to take on this task. However, with white-box testing, it is typically developers that do this.
Q: How is coverage measured at a component integration level?
This is typically measured by the total number of integrations executed by your tests as a percentage of total integrations.
Integrations are different. The expectation at this stage is that the individual component (click here to see why stubs and drivers are used in component testing) has already been tested and fit for purpose. Therefore, this stage focuses on how the outputs of component A interface with component B.
These integrations are usually in the form of a file (typically XML) with various fields and data. These data points need to match the specification to pass. Hence the need for the component level integrations. And, even more, an important way to measure its coverage.
