In this blog, we’ll deal with one of the most popular methods of testing a system or system component thoroughly – namely, white box testing.
Test managers among you will have, by now, been involved with some level of white box testing throughout your career.
“In the name of Agile, I see project teams skimp on a lot of things – chief among them Testing.”
BREAKING NEWS: Click Here to Download Our NEW Exploratory Testing Tool. Integrates Awesomely With Your Favorite Testing Tool. It’s FREE!
In an increasingly Agile-driven world, techniques like white box testing are fighting for survival. I’ve said this before, and will repeat it here again – pursuing Agile methodologies to improve your IT delivery does not equal to ignoring any activity that needs to be accomplished to deliver your project successfully.
In the name of Agile, I see projects and teams skimp on a lot of things – chief among them testing. white box testing is one of the most affected as a result.
Do not fear. With this post, we’ll set right all the wrongs cast upon white box testing.
We’ll refresh our understanding of white box testing. And how it can help you deliver 100% test coverage when necessary.
We’ll pick up an example and walk you through it step by step.
And at the end of it all, you’ll be able to appreciate the unsung role that white box testing often plays in important projects, and go back with a renewed enthusiasm towards incorporating this and other similarly less attractive but equally effective testing techniques back into your arsenal.
And with that, let’s begin…
What is white box Testing?
This being a refresher of sorts, let us begin by defining the technique.
White box testing refers to a scenario where (as opposed to black box testing), the tester deeply understands the inner workings of the system or system component being tested.
Gaining a deep understanding of the system or component is possible when the tester understands these at program- or code-level. So almost all the time, the tester needs to either understand or have access to the source code that makes up the system – usually in the form of specification documents.
Armed with the level of technical detail that is normally visible only to a developer, a Tester will then be able to design and execute test cases that cover all possible scenarios and conditions that the system component is designed to handle.
We’ll see how this is done in our example later.
By performing testing at the most granular level of the system, you are able to build a robust system that works exactly as expected, and ensure it will not throw up any surprises whatsoever.
The key principles that assist you in executing white box tests successfully are:
- Statement Coverage – ensure every single line of code is tested.
- Branch Coverage – ensure every branch (e.g. true or false) is tested.
- Path Coverage – ensure all possible paths are tested.
And we know path coverage is favoured above branch coverage for the sheer comprehensiveness it provides.