(note: this claim has not been tested in all global markets)
Last Friday, I attended a meeting with several technical Test leaders from around the company. We were focused on Test PR. Specifically, we wondered what the Test community could do to get college students really excited about the role or, alternatively, find those CompSci folks that would thrive more in the Test Discipline than in Dev or PM.
It was a productive meeting – the ideas generated will be great. One thing, though, bugged me about meeting. We spent a large amount of time trying to converge on a definition of Test that we felt was valuable for the exercise.
Earlier the same day, I met with a tester who currently works in Office Test. This tester had not been out of school for long and was frustrated with their job. They came to me to sort this out: was it their job, their manager, the team they were on, Microsoft?
“I really love interacting with my Developer. I’m really helping to make them productive and they appreciate me for it”.
This person was upset because they knew they were providing real value, but their manager was “old school” and focused on the tester’s low bug count.
On the web, there are examples as well. Here are a couple of recent ones:
- Alan Page puzzles over the Test Job (and whether or not he’s doing it)
- Scott Barber tries to scope the Value Add of Test (and does so quite beautifully, imho)
This is a pattern that I’ve noticed a lot of lately (2 or 3 times a week). Folks are trying to define the value/purpose/meaning of the Test position.
It occurred to me that the problem might be Test itself. Not the discipline, mind you, the word.
Ever since I learned Design Patterns, I have been fascinated by the idea that a single simple word can immediately invoke an entire concept. If you were looking at a piece of my code and stated, “Brent, don’t you think this code would work better as a Singleton?” I would know exactly what you meant.
Definitions are key to understanding. Singleton is nice. It has multiple definitions, but in the CompSci context, only one. You know it or you don’t.
Test doesn’t quite do the same. If I say I programmed a solution, it means I wrote a bunch of code that I believe works to solve the problem I intended. If I hand that code over to someone to Test, what are they going to do with/to it? Is it clear?
Alan shares his perspective on the problem:
“Roles that testers play on teams vary. They vary a lot. You can’t compare them. That’s ok, and (IMO) part of the growth of the role. I find it disturbing and detrimental when testers not only assume that their version of testing is “the way”, or that some roles (or people in those roles) do not qualify as testing.”
I tend to agree. I do not consider myself part of the “Context-Driven” School of testing. I think Testing, by its nature, is context-driven and therefore including that term is redundant. (Though, it does occur to me that this viewpoint *might* actually make me a member of the school. I’ve struggled to find the other Schools of Test to compare. (Edited: it’s here.))
I find myself puzzling: How many other industries that use the word Test have this very same ‘Context-driven’ property?
For example, if my doctor were to schedule a CA 125 test for me, would the lab technician recognize that I was a male and question the validity of the test? If the results came back low (or high), would the lab technician offer me nutritional tips to improve my experience? Would the technician defer my sample to someone else while they worked hard to improve the efficiency of the paperwork handoff between the doctor and the technician?
To all three I answer: Maybe, but I doubt it.
IMHO, over the years, Test has gotten overloaded so much that it has lost much of its meaning. I am reminded of another article. In this one, Michael Bolton makes a distinction between Checking and Testing. I love this. While I don’t necessarily agree with what he finally landed on regarding the definition of Testing. I can roll with it. Michael is helping to disambiguate the terms. I’ve personally found these terms helpful when communicating with others.
So how did we get here? My hypothesis is we got here through business demands.
Scott says this:
“When it comes to software, on average, testing is on [the business’] radar, and testing is not providing the value they are looking for (or, at least is not being communicated in a way they understand).”
Many business leaders have differing expectations of what they want from test. When Software testing began, it was essentially for scientific endeavors. It should be of no surprise to find that it grew from debugging as a mechanism to “prove” correctness of a program (ie prove it works). This then grew to finding bugs. However, I believe as commercialized software began to dominate, making it “user friendly” became a differentiator for most businesses. Suddenly “correctness” meant quality and we hired hoards of testers to pound and find bugs. The cost of recurring Test passes forced us to learn to automate in order to move forward. Since Testing has gone through such dramatic shifts and very quickly, it really shouldn’t be surprising that many folks still cling to older definitions and older value propositions
We are at another transitional stage. Quality is now not necessarily about prevention as it once was, but about quick reaction. We are going faster and faster, and storing more and more and more data. I believe the Testers of the future are Data Scientists.
One thing I am digging already is the cool new title. I hope we don’t overload this one too.