Information Technology Dark Side

Struggles of a Self-Taught Coder

Information Technology Dark Side header image 2

What is a tester’s job?

July 20th, 2010 · 5 Comments

Melissa Bugai (@melbugai) from Atomic object asked the question “What is a tester’s job?” in twitter today. After a few 140 character attempts at succinct answers I gave up and decided to write a blog post about it.

A tester’s job is to make the product better
I admit this is a simplistic claim, so I think I’d better explain what I mean.

Being a tester is much more than just finding problems. I’ve seen testers who are extremely good at finding bugs but fail to turn those bugs into substantial improvements for the product they test. Why is that?

Sometimes it’s because the tester is not a good bug advocate. They aren’t able to convince developer’s, managers, and stakeholders that a bug needs to be fixed. They try, are ignored, and then become irritating jerks when the bug is exposed in a production environment and begin taunting everyone else.

Sometimes it’s the result of crying wolf. A tester thinks every single bug they find, even the obscure boundary bug that only happens when you paste 10 million characters in a text field, is critical and must be fixed now. They escalate on everyone who tells them to chill out until everyone is sick of them and their bug reports are all ignored.

Sometimes it’s because the tester is out of sync with the development team. Maybe they are testing so far behind the dev team that they’ve lost interest in the area the tester is focused on. Or perhaps they have gotten ahead of the dev team and are testing stuff that doesn’t make sense contextually.

These are skill issues that can be taught, coached, and improved. More concerning to me is the third reason this happens.

Sometimes it’s because a tester doesn’t believe it’s part of their job.

“I just find the bugs. What you do with them is none of my business.”

I don’t care for this detached approach to testing software. You can’t coach a tester into caring about the product they test – first you have to remove their head from the dark body cavity in which it is embedded.

But… but… you argue. If they find the same bugs as a tester who cares what difference does it make?

Well, that’s not likely. They won’t find the same bugs. Their testing will be cursory and focused more on creating the impression that adequate coverage has been achieved than finding the bugs that matter the most in the context of the product development effort.

It’s sad to see a tester with otherwise good skills who is so ambivalent to the outcome of their work that they don’t even try to see it in the larger context of effectiveness as an individual CONTRIBUTOR.

A tester cannot succeed independently while the team fails

A tester who doesn’t make the product better is failing. It might not be entirely their fault – maybe the organization has unhealthy incentives to ignore them. Maybe the developers are sensitive jerks who can’t take criticism. Maybe the managers don’t know a critical bug from a mis-spelled word in a EULA. Whatever. It doesn’t matter. If all that stuff conspires to make you fail as a tester…

You still failed. You did not accomplish your job.

Sorry. It’s a cold cruel world kids.

If you enjoyed this post, make sure you subscribe to my RSS feed!
Stumble it!

Tags: Uncategorized

5 responses so far ↓

  • 1 MelBugai // Jul 20, 2010 at 7:53 pm

    This is an intriguing post. I agree that in many organizations that doing such work is extremely valuable and needed.

    Consider this: in a team composed of sensible/smart/alien-level-genius members the need for bug advocacy doesn't really arise because the business makes reasonable choices about what gets fixed when and how that gets prioritized among the backlog of other tasks. So what does a tester do without a need for advocacy? Just find bugs in the running software and report them? I'm okay with that if that's true.

    This brings me back to my original question: What is the tester's job?
    Understanding is all that I seek at this time.

  • 2 Drew Kime // Jul 20, 2010 at 3:05 pm

    I disagree with the premise. Well, maybe with how you’ve defined the terms.

    There are three major functions in creating software: Someone has to decide what the software should do, someone has to make it do things, and someone has to evaluate what it’s actually doing.

    If you’re not writing code, you’re not making it do things. So you can’t make it better. As a tester, you should be telling people as accurately as possible what it’s actually doing. Yes, the goal of that information is to make it better, and all the points you made about advocacy still hold. But ultimately it’s the people writing code who have to make it do that.

    Eventually you’ll always find out if it’s not doing the right thing. What testing does is let you find out before you give it to the users.

  • 3 davidray // Jul 20, 2010 at 10:22 pm

    Well, the fact that you have managed to fit in among such smart peeps is a credit to you, but I think you're being a bit bashful by suggesting you don't do those things. It's just really, really easy the vast majority of the time for you. That might be because the things that you don't entirely control (who you work with) and the things you do control (your own behavior) work nicely together to create a really productive culture.

    Let me prove my point. If you had a tendency to cry wolf, or were perpetually out of sync with the devs… what would happen? Someone would fix that problem, probably through peer pressure.

    In other words, I think you're probably pretty good at bug advocacy. You're also in a place where bug advocacy is less about people skills and more about facts. You still have to collect and explain those facts effectively.

    Anyway, I think your situation brings up a good point about context. I still think a testers job is to make the product better, but what that means varies widely based on the context of the organization, product, and other things.

    In your case, you've got a sweet gig and your life is pretty pleasant and productive. In another environment that is not as healthy or effective, it might mean something entirely different. But the job is the same – to make the product better. A tester might have to do much more than test stories to make that happen, but it's still part of the job.

  • 4 Tweets that mention What is a tester’s job? -- // Jul 21, 2010 at 7:09 am

    […] This post was mentioned on Twitter by Arnon Rotem-Gal-Oz, aldos. aldos said: @MelBugai Got me thinking. It's not a job description, and is more of a rant, but… […]

  • 5 David Christiansen // Jul 21, 2010 at 9:42 am

    Here’s the point I would make – if a tester does his or her job well, the bugs they find will get fixed, because they found them, described them well, and advocated them effectively.
    What I’m proposing is that testers should consider whether the bugs they report get fixed as part of the criteria for determining if they are being effective. Just finding bugs and throwing them over the wall is not enough.

    Whether that action strictly qualifies to be described as “making the product better” is a matter of semantics. I think of it like this: the product is better now because I found this bug and convinced my colleagues to fix it. Sure, I didn’t fix it myself, but, if I hadn’t found it, a customer would have, and the product would have suffered as a result.

    So, that’s my yard stick – not bugs found, or tests done, but bugs fixed. It works for me, and I think it is a good way to evaluate if I am doing a reasonable job.

Leave a Comment