When I started my testing career, I read the lines which said, think Out of the Box. My then manager said the team to think and work, out of the box.
I see testers practicing, working, testing and automating by saying, out of the box.
Wait! When said boxes, what comes to one's mind is Black Box, White Box and Grey Box. But, I tell you, there exists no such boxes. These boxes are imaginary; it was termed probably to give an analogy, to see and know the ways to test the product's code and infrastructure.
I do not tie myself to these imaginary boxes, but, it is a useful analogy. After all, when said Out of the Box, which box are we referring to?
And, what is that I'm missing by saying and doing out of the box?
What Have we Forgotten?
While me talking and saying *out of the box*, I'm not letting myself to think Inside The Box, for first.
If I cannot know what is *inside the box*, how will I know what is outside the box?
If I cannot see, think and explore for what is *inside the box*, how will I know what is outside the box?
I see, we have forgotten "Inside The Box" by saying and hearing "Out of The Box" for decades.
What's inside the box which you are testing? Does it have just functionality, though the functionality is the heart beat of a system? Okay, have I explored the functionality in all possible dimensions?
Almost everything in the box is associated with functionality.
When I'm not said to test for what is inside the box, I will be lost with Out of The Box. Do you?
If I explore Inside The Box, fore sure, it will help me to go beyond functionality. What all I can do inside the box? What all I can evaluate inside the box and how? That is, I think of performance, security, usability, observability, traceability, monitoring, and you label next. All these are associated directly with the functionality.
 |
All the boxes in software testing are imaginary.
We have forgot to see and explore Inside the Box. |
Inside the Box, helps you to identify and observe,
- Why these exists?
- Why these are interconnected?
- How these are interconnected?
- How are they communicating?
- What are they communicating?
- To whom they are communicating?
- When are they communicating?
- When they fail to communicate?
- How fast and reliably they can communicate?
- The programming, code, protocols, tech stacks, libraries, money, ports, cables, people, etc.
- What they are holding and where, how and why, when?
- And, more ...
As you go Inside the Box, this space grows in multi dimension. You will realize what is out of the box and what is inside the box. You will consistently tune yourself to fit in any imaginary boxes with your tests. From there on, you will explore, test, automate and talk to all the imaginary boxes and system[s] you are interacting with.
If I cannot see what is within, how can I see what is outside?
The Reality, Pain, and Cost
This is my observation.
- When I ignore Inside the Box, I will continue to talk with more focus on vocabulary, terminologies, schools, process, advocating on one aspect of the discipline and think this is craft and craftsmanship.
- I will be stuck here and pass on the same to upcoming generation of software test engineers and practice.
- This is the reality and painful part.
Is talking and working on vocabulary, terminologies, schools, craft, craftsmanship and advocating that one aspect is testing, wrong?
- No, it is not wrong.
- But getting lost here indefinitely is beyond wrong.
- The cost of this is huge to the craft as a practice and to the software test engineering discipline.
- As a result, the upcoming test engineers and generation will pick whose voice, approach and content is more opted.
- If observed, this is not the case with programming and programmers.
- I see, the programmers challenge most times and everyone who pushes or sells the thoughts.
- Why? I see, they are trying to learn and understand from inside the box for first.
Unfortunately the smart people who are with role and title of influencers, thought leaders, keynote speakers, seniors, directors, VPs, ambassadors, and advocators of a thought and schools are lost here. My question to them and me is, why not we explore Inside the Box? Why just confined for propagating the philosophies and one's ideas alone ignoring what is Inside the Box? The philosophy is a need; I do not say we should not ignore it. Philosophy alone do not pay one's bills and fill the stomachs. I wish, I had learned this lesson in the start of my career. The business is a philosophy by itself and it will make use of or ignore any other philosophies as and when needed. I hope and wish, the test engineers will interpret this.
I see this is one of the key reasons why the software testing as a discipline and practice we did not gain the recognition and importance as programming the product and solution. Though we work closely with the product code and the test code, we miss our craft and names being called out. This is reality and painful.
To end here, if I'm not seeing and thinking for what is Inside the Box, how will I excel in Out of the Box?
