The issue of "black box" vs "white box" testing techniques arises often in the context of testing, as well as in general analysis. The central idea is simple: a black box is known only through its interfaces, while a white box reveals its internals for inspection. In some situations this distinction appears to be useful.
I find that it is much more useful to proceed as if there is no such a thing as a white box - only black boxes. Every black box has yet more black boxes inside it (a subtle point here is that we are allowed and able to look inside a black box to see if there are other boxes inside it - a nod to the "whiteness" of the box, or to the believers that you need to examine it as a white box - a nod, no more!).
A perspective that everything is a black box forces the examination of anything only from its interfaces. The point is: we can never know what something IS, we can only know how something behaves. If the model is explanatory and predictive enough, for our current purposes, then that's all we need to know, and it is the "right" level to stop at.
Consider a black box A that you can analyze knowing its interfaces. Now you want to get "under the hood" and peek inside. You find two boxes, B and C. What options of analysis do you have? Study how the interfaces of B and C make the bigger interfaces of A, and how B and C interface to each other. Now you are more curious and you want to look inside both B and C. What could you possibly find? Inside B, boxes B1, B2, and B3 with interfaces among them, and external interfaces that add up to higher level interfaces. Same applies to C. You get the picture. Anyone who has ever opened the hood of a car knows the feeling.
The "looking under the hood" metaphor is instructive - and we can stretch it a bit farther. The instant you go under the hood of a car, you're exposed to the dangers of the white box thinking. You're face to face with enemy of all progress - complexity. The complexity in the problem space suddenly jumps from one black box with well understood interfaces to a jumble of black boxes interconnected in many bewildering ways. Welcome to the Hotel California, you are now face to face with the beast. "You can stab it with your steely knives, but you can never kill the beast".
The essence of this problem is granularity. Each box has inside it boxes of finer granularity. Success, or failure, centers around the "right" granularity of analysis. The auto engine has a basic interface - take in gasoline, and produce rotational energy. The "essence" of the engine is encapsulated in two of its components, the piston, and the crankshaft. The rest is detail. The piston converts heat to vertical motion. The crankshaft converts vertical motion to rotational motion. This illustrates the need for a conceptual framework, to conquer complexity. You must postulate a model. No analysis can proceed just by "getting under the hood". Talking to a mechanic may or may not be instructive. A reflective mechanic, like Click and Clack, the Tappet Brothers, are scientists at heart - and damn good mechanics too. Rare combination to find. A model by necessity is a simplification, and risks some inaccuracy, of course. The biggest danger of simplicity is the slide into trivializing reductionism. But the silliness of reductionism is easier to deal with than the obfuscation of complexity.
Recent Comments