Black Box vs. White Box Henrik Emilsson
I have heard and seen the difference between Black Box Software Testing and White Box Software Testing being described as “whether or not you have knowledge about the code”; and that Gray Box Software Testing is a mix of the two.
But is it really about how much of the code you see?
I rather think in another way; and this is my take on an explanation:
Black Box Software Testing – When you worry about what happens outside the box.
White Box Software Testing – When you worry about what’s going on inside the box.
– Sometimes you know about the inside when doing Black Box Software Testing.
– Sometimes you know about the outside when doing White Box Software Testing.
What matters is that there might be a difference in scope, question formulation, and information objectives.
Another take which would mean the same thing:
Black Box Software Testing – When you don’t need to worry about what’s going on inside the box.
White Box Software Testing – When you don’t need to worry about what’s happening outside the box.
================================================
Disclaimer: As a tester I cannot say that I often categorize my testing into White/Black/Gray Box Testing. However, it can sometimes be helpful to think about the transition to another perspective; so I use Black and White Box as a test idea trigger (or heuristic).
Actually I’d say this was closer to the original:
Black Box Software Testing – When you don’t want to worry about what’s going on inside the box.
White Box Software Testing – When you don’t want to worry about what’s happening outside the box.
I only changed one word in each but I think that it was an important one.
Yet another view would be whether you have access to the internal (unit, code, dev environment) components or access to external (interface, GUI, deployed environment) components for testing. There are many useful tests that can and are performed in each environment.
That distinction came clear one day on a large (>40 person) waterfall project team years ago when I invited a developer to our test lab to show her a defect I was seeing. She was amazed: it was the first time in a year and a half that anyone had shown her what the actual application looked like she was working on. All that time, she was assigned specific unit level tasks with no understanding of the overall purpose or goals of her changes. I think the most effective testing is performed in a “gray box” environment with heavy interaction between the team members.
Chris, I were in doubt on if I should us “need” or “want” (in the second paragraph).
Both would work, I think.
For me though, “Need” is more to the point since I might actually “want” to do it, but I might don’t need to… 🙂
Jeff, interesting story! And scary! 🙂
What I am trying to point out is that it is not about the access to the inside or outside; it’s about what your information objectives are.
I like your distinction about a “gray box environment”, and I agree that we often benefit from such an environment.
It’s important though, to diversify and broaden the testing so that we try to avoid testing the same things both from a white box and black box perspective.
One example is automated acceptance tests that, in my experience, introduces a risk of only testing the same functionality as have been tested on integration or unit level.
Thanks for the post.
It is simple and useful.
I would like to ask: “I am a manual tester, I do black box testing”
Should i write my role as “Black box tester? “
Nice post.
As I learned the difference from Black to White Box tests is where you get the information from.
Black Box tests are based on documentation, requirements, and so on. Whereas White Box tests depend on what you learned from the code.
I think the ‘technical detail’ of how black and white (I prefer the word ‘glass’) box testing are defined may not be the most relevant difference and here’s why:
Whether or not you do or don’t have access to knowledge about the internal structure of a piece of software is one aspect of the matter.
Another aspect is the focus of the testing itself: Black box testing is focussed on the actual behaviour of the software and dealing with the value it provides to users/customers. Glass box testing tends to focus in the internal structure and deals more likely with questions about the maintainability of the code, its modularisation etc.
IMO both aspects are important in testing.
Srinivas: I find that both approaches allow manual and automated testing. There are some very useful automated tools for glass box testing, too.
There’s nothing about white box (which I think should be called “open box”) testing which wants to ignore what’s going on outside the box. Or if you think so, then black box testing would have to be just the same, since the term “black box” does not include anything outside of the box. (Or else the phrase would be “box-in-the-world testing.”)
Black box testing means that you test without concern for how the box does what it does, but rather only that it seems to do it. If you open the black box to see inside, you may be able to test better, but that also shifts your focus.
The reason that black box testing is popular is partly because that’s accessible to non-technical people and partly because it encourages you to focus on the relationship between the box and the user. This relationship is not discouraged in white box testing, but it is largely the case that filling your brain with the technical details drives your awareness away from the experience of using the system.