Modeling Software Testing With Boxes
The fact is something that is not put to scrutiny or questioned much and often.
As a fact, the Software Testing is explained to us using boxes. That is,
- Black Box
- White Box
- Grey Box
I see, we are seeing Black Box in every other box. Maybe, this is limiting one not to think to learn software testing in other than a black box mindset.
If you ask, are we not automating? Is not that a Grey Box? Very much, we are a black box mindset when writing automation as well. I include myself here. I'm exploring how to break out of this and see the Software Testing.
Do programmers think of their code as different boxes?
- A programmer reads, writes, deletes, and views the data. events and state
- The programmer as well cannot see what's happening between the binaries on the electric circuits
- The programmer evaluates her/his code's testing via logs, debugger, and assertion for the data, state, and events
- Is this a white layer or box?
- Is it called white because one can see through the logs, debugger, and assertion?
- But that is still not a sight of binaries on the electric circuit, right?
- If one could see through the binaries, we should not be having race conditions, out-of-memory, and unhandled exceptions
- Isn't so?
This makes me feel, there is a Black Box in every box and we are largely confined to this Black Box.
Exploring to step outside this box helps to understand the testing, software testing, system [and software] under test, and what is needed to test better.
