Uncharted Waters

Mar 21 2017   8:46AM GMT

The Definition Game

Matt Heusser Matt Heusser Profile: Matt Heusser

Tags:
HR
IT
quality
Testing

Definition Game“There are certain words I’d like to use without being told that I’m using the wrong word, or using the word in the wrong context, or using a word that in theory means something else.

A good example is the word ‘break’. Sometimes I like to say testers break stuff. Often it is with humour. Virtually everytime I use it, or when I see others use it, then a tester pops up correcting the use of the word break and how testers don’t break things. The same applies to other words. QA/quality is another example. Or testing/checking.

It’s all good discussing these things, but it feels like it has gone over the top.”

– Rosie Sherry on the Ministry of Testing

Yes, most testers do enjoy a well-timed “Well, Actually.” To some testers, “Well, Actually” is the job itself. Consider the programmer, who spends a week developing an amazing report. The tester adds value by saying “well, actually, sort order is broken if …”

Personally, I find sometimes testers do break things. And sometimes, the distinction between QA and “testing” doesn’t make a difference.

Let’s talk about the definition game.

Breaking Things

When I am testing, I frequently do break the software. Not as often as a few years ago, but it still happens occasionally that when I started testing, the webserver is up. Not too long into testing, the webserver has crashed. It is down. That is, www.somesite.com used to look like a web page before I tested it, and now it generates an error.

What can we say but that I broke it?

Likewise, sometimes I say that feature_X is broken. I do that on purpose and with intent. Often, new developers, who know me by reputation, are incredibly skeptical of such a bug report. “MATT” they shout. “HOW UNPROFESSIONAL. I can’t BELIEVE that someone of your CALIBRE would write such a TERRIBLE bug report! Why, there are no reproduction steps! There is no expected result, no actual result!”

My reply: “Have you tried to use the feature? At all? In any way?”

Do we really need reproduction steps when clicking the button that is the name of the feature generates an error? When it is impossible to use the feature in any way? At that point, I would argue that details, reproduction steps, screen captures, videos, all that is waste. It is not essential. The programmer can look at it and see the problem.

Let’s talk about QA verses testing.

Testers Don’t Assure Quality (Goes The Argument)

As Edsger Dijskstra pointed out decades ago, Testing can prove the presence of bugs, but not their absence. Asking “Why didn’t QA Find that bug?” is more an exercise in blamestorming than a search for truth — but the term “Quality Assurance” takes people down that path.

Testers can not live up to the title of “Quality Assurance”; the title makes a promise testers cannot keep.

And yet.

Honestly, when I go into an organization with a “QA Department”, getting the department’s name changed is rarely the first thing on my priority list. Why?

It comes down to behavior.

If you renamed the role to “Tester” instead of “Quality Assurance Engineer”, what behaviors would change? How would the testers do the job differently?

Often, nothing at all.

The term is a placeholder, something that existed before every “QA” was hired, and will likely be around after they leave. Perhaps, at best, a better term might help some of the less-technical executives understand what testers do. Once or twice, in my career, an executive has said “there are some quality problems, we need better QA”, when yes, there were quality problems, and we needed better development and more clear requirements. After all, if the bug tracker is full, we know about plenty of bugs,  we just need to fix them and introduce new ones.

Most of the time though, there is would be no difference in behavior. Being smart, using more accurate and precise words, leads us into a silly argument. Again, it might be worth having, but I have other priorities. Besides, as Martin Hynie has pointed out, a more vague job description might just allow the tester more influence outside of classic “I-just-assembled-product” land.

In the end, I want to focus on the work. If the words we use don’t make a difference, then … the words don’t make a difference. I’ll use your words, whatever, let’s just get some work done.

And that’s the bottom line.

Epilogue

Google’s keyword planner suggests words that mean similar things, but might be more popular. Struggling with the title of this piece, I asked for alternative terms to the definition game. Ironically, “pretentious” was one of the top answers.

Perhaps it wasn’t that ironic after all.

 Comment on this Post

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when other members comment.

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

Share this item with your network: