Neo: I just have never…
Rama-Kandra: …heard a program speak of love?
Neo: It’s a… human emotion.
Rama-Kandra: No, it is a word. What matters is the connection the word implies. I see that you are in love. Can you tell me what you would give to hold on to that connection?
Conversation in Mobil Ave, The Matrix Revolutions
One of the activities I recently took upon myself was to consider for myself what my definition of ‘testing’ was. You hear definitions from so many other people about what testing is, but you still have to interpret that definition for yourself. Without stopping to think whether you have truly grasped what someone else’s definition is you may find yourself ill-equipped to defend that definition. “Do I understand it as they say it?” I would find the answer to that question hard to believe if the answer was “Yes”. Just as what Rama-Kandra implies in The Matrix: Revolutions, we interpret all the information we come across, its what makes us human and unique from one another, its why the role of software testing exists today.
So lets get on with it, here is my definition of software testing:
Testing is a systematic approach to systematically learning about something within a given context.
A systematic approach to – The first thing you would have noticed is the strikethrough text. This represents my first definition, I was unhappy with labeling learning as a ‘systematic approach’. It doesn’t make sense to me, it implies that there are other approaches to learning. But, I think learning is fundamentally systematic. When I say systematic, I am happy to use the dictionary’s meaning of “done or acting according to a fixed plan or system; methodical” The only difference is whether the systematic aspect is tacit or explicit.
We might question if children are ‘methodical’ when it comes to learning. But simply asking the question “How do children learn?” already implies that there is some methodology at play that can be discerned. Common answers found online state that children learn through observing, playing and experimenting. So the systematic aspect of their learning would be the processing of external stimuli to arrive at a decision.
systematically – Any astute thinker would then be asking why I have bothered to keep “systematically” a part of this definition at all. If it is true that all learning is systematic, then its a redundant phrase. Like ‘a four-cornered rectangle’, why should I bother describing an attribute of something it innately has?
It’s something I still occasionally wrangle with, but take stock of what most tester’s tout as an important attribute: being a “quick learner”. I think that is a core attribute for a tester to possess. But it’s importance is rivaled by its vagueness. A tester that says they are a quick learner is like a chef that says they are a good cook. I’m inclined to ask for more information – what empowers your learning? What makes you quick? Quick in relation to what? I think when we say we are quick learners, what we are really trying to say is that we possess refined and flexible learning styles that are easily applicable to certain types of applications under test.
I leave ‘systematically’ in the description because the systems of learning testers employ should be orders above anyone that does not actively study testing. I want to draw attention to the fact that our systems of learning are exceptional and meaningful.
learning about – Yes, our jobs are to find bugs and report the ones that matter to the people that matter so they can make informed decisions, so why not instead have “a collection of bug finding activities” instead of “learning about something”? Because I can’t bug find without first learning about the product I am testing.
Whenever I start testing, I don’t know where the bugs are, I can posit where they might be and make an argument for certain plans and strategies based on my presumptions about what the product is meant to do and what it is meant to achieve, but until I start experiencing the product1, I am blind to bugs. Therefore, the activity I am doing first and foremost when I am testing something is learning, and I make it my job to learn as fast as possible and apply my learning skills in such a way that primes me to encounter and recognize that I have encountered bugs that matter.
something – Testing is not limited to just software and hardware. It is applicable in various facets of our lives. Try testing the way you walk, or the ‘best’ way to sleep. You might scoff at that, but it is my current hobby to learn about lucid dreaming and part of that is founded in understanding our sleeping patterns. Look up WILD and WBTB methods for naturally inducing lucid dreams. But I digress, it just so happens that software/hardware is where testing is needed the most, it is not to say it is the only place that testing is used.
within a given context – I’m still 50/50 on this particular phrase. We are back to tackling our four-cornered rectangle. Learning is always encapsulated within some sort of context, so why mention it? I don’t think I have a full answer at this point, but I feel the need to include that phrase anyway. Maybe to make clear to others that do not study testing, that context is a key factor that directs what we learn and how. At least it serves as a talking point should anyone inquire.
- Experience of the product can begin before the product is even built through conference with stakeholders, developers, and end users, testing can begin once someone has formulated and shared the ‘idea’ of the product.
That is my current definition for testing. I’d call it my second definition as well, I would not be surprised that I revisit and amend the definition several times over the years to come. What I like about this definition is that it is a definition that makes room for good testing and bad testing. I don’t think a definition that constricts the view of testing to just good testing could be called a full and complete picture of testing… whether that’s meaningful or not is a discussion for another day.
greyheuristic.com 