Hello and welcome to this guide to treating your tester right.
This article is intended for people on a cross-functional team that includes testers, especially developers. I hope to give you something of a glimpse into the tester mindset to help you understand us and build better relationships with us. I write this also as a show of solidarity to people working in software testing and quality. You are not alone!
Now, down to business.
No matter whether the tester has been on your team for days, weeks, or years, there’s a chance that they feel somewhat out of place, underappreciated, or misunderstood.
Of course, this isn’t the case at your job, only at other organisations. (Right?) But in case you end up on a team where it IS the case, this guide might help you to understand your tester, who may seem somewhat fragile at times.
While I’d like to say this pamphlet is completely objective, in reality, I can speak only from my own experiences and observations as a tester. I will try to be as objective as possible, but writing this has been something akin to therapy for me. Perhaps it will ring true for others, too.
Addressing your tester by their proper title
First off: what to call your tester. Okay. Well, hmmm. This isn’t as straightforward as you might assume. The long and short of it is that it’s probably best to ask them what they like to be called.
It could be that you have a tester. Or you might have a test analyst. Or a quality engineer, an SDET / SEIT, a QA, or a test specialist. Or you might have a test manager, a quality specialist, an automation engineer, or a test architect. So your tester / QA / quality engineer / SDET / automation engineer / test manager might go by one of many names for many reasons, despite an awful lot of overlap between these roles.
One reason for the wide variety of possible titles is that the role of a tester has changed over the years. The range of testers’ responsibilities and capabilities has grown. What’s more, the people who make up the titles may not truly be sure how to define the role or what it actually involves. And don’t worry, if a tester were in charge of assigning titles, we’d probably be in the exact same position.
Titles mean different things at different organisations. A test lead in one organisation could be less experienced than a mid-level tester in another. And “QA” in itself can be an annoying or even offensive title if the person is not actually assuring quality throughout the software development process.
Of course, there’s also the possibility that the person who fills this role is such a mythical and wondrous creature that no one can really say what to call them. This seems the most reasonable answer to me. (Joking!)
But none of this helps you in knowing what to call your person of quality. And even though it’s only a title and, as such, ultimately meaningless, it’s treacherous territory. So, good luck on this one. As I said already, it’s probably best simply to ask them which title they prefer.
For the purpose of moving on with our lives, this guide will use the title “tester.”
Okay. Breathe. (This is a reminder for me, but feel free to join in.)
Understanding how your tester’s mind works
Testers are complex, caring, and insightful. They’re curious, inquisitive, and playful. They’re pained artists who just want to be loved and appreciated for everything they do to hold the team together, almost as if they’re the only ones responsible for everything being done well, and without them, it would all fall to pieces in no time. Some also say they can be egotistical. (See, I told you this guide promised objectivity.)
Testers like details and specifics. (Did you see how long I talked about job titles?? And that was only the tip of the iceberg!) They also like to go on tangents, but that’s beside the point. If you’ve got a tester who’s focused, is happy speaking their mind, and has the freedom to do so, you can achieve some incredible collaboration. They’ll help you better understand the problems you’re solving for people, and discuss risks, possibilities, plans, requirements, and acceptance criteria. Testers can help teams achieve more clarity on the specifics AND the whole picture.
How testers interact with other team members
Silence is not always golden
Not only are testers the saviours of software development, they’re also the martyrs. It isn’t rare for them to be undervalued, especially if they don’t code. Examples of this abound, and we won’t go into them here. Nor will we go into possible reasons since that’s a massive topic in and of itself.
But rest assured that being seen as less important than the rest of the team has an effect after a while, regardless of how highly a tester might think of themselves. It can lead to disengagement and ceasing to care as much about quality, just to protect themselves. So, if your tester is a bit quiet, it might not be because they have nothing to say. It could just as easily be that they don’t see the point in speaking up if they would be ignored or underappreciated anyway. There are only so many battles worth fighting.
Testers can be testy
And fight they do. Sometimes, as a tester, it can feel like you have to fight for simple things like being invited to a conversation about the very functionality you’re all working on, supposedly as a whole team. What about being given a heads-up that very day that some work is headed your way, of which you had no prior notice? There’s nothing like work that comes in the form of a ticket that appears in your queue with no details on it. That kind of ticket practically yells, “Just do the thing even if you don’t understand anything about it. And be grateful you even have a job.” The tester thinks: but I don’t WANT to “just do the thing” without knowing anything about it, thank you very much! And I certainly don’t want to be left out of the loop by the people I call my teammates. If you want the best from me, then treat me right. As an equal, for Pete's sake!!
Sometimes, testers can also be a bit dramatic. But you might be quick to jump to drama, too, when an unnecessary struggle simply to do your job is so often the order of the day.
Testers will often challenge you and your thinking. They’re not being “difficult” for the fun of it. Okay, maybe a little bit for the fun of it. But it’s all part of the job, possibly in their DNA, and it’s all in aid of creating something better together. They truly don’t do it with the intention of annoying anyone. So please don’t take it personally if a tester challenges your proposed solution or what you’ve already coded. And please don’t get annoyed at them for it when they have everyone’s best intentions at heart. Assume good intentions on the part of all your colleagues, including testers.
Treat testers the way you want to be treated
Suffice to say, testers have to deal with a lot, and it can affect the way they think and act. And we haven’t even scratched the surface of all the context-switching and pressure that can go hand-in-hand with being a tester. Keep in mind as well that they might be most likely to be considered first for workforce cuts, depending on where they work.
Be aware that they’re juggling a lot, and there’s a good chance they’re underappreciated and undervalued, often literally getting paid less than everyone else, regardless of how hard they work. This is not to say that others aren’t underappreciated or underpaid too. But typically, testers tend to feel it a bit more than others in software teams. So be nice to them!
As much as testers have the world on their shoulders, a good tester wants the best for you and the team. They can help you work out ideas early on and shape them into something tangible that works well. They can help you through a particularly difficult migration or release. They can be your comrade in putting out quality software.
The good, the bad and the ugly: examples of interacting with testers
Let’s have some fun and try not to get too triggered. We’re going to look at some things you might say to (or think about) your tester or how you might deal with your tester. Then we’ll consider whether or not they’re a good idea.
“The tester isn’t needed yet.”
Says who? You? King of the world, is it? Your tester can often offer insights that you wouldn’t think of yourself, and can help to assure quality from an early stage if they’re allowed to. They look at things differently and consider things you might not. True, a tester won’t be needed for every conversation, but the number of conversations where their input is an asset is greater than the number of conversations for which they aren’t needed. They’re full, rightful members of your team. And if you’re unsure whether they are needed in a particular conversation, just ask them. They’re adults and can make decisions for themselves.
“It depends…”
Oh, you’re a keeper. This is testing 101. If you’re already aware that everything isn’t black and white, that there’s an awful lot of variation that can have an impact, AND you act on that belief, we’re going to be friends and I’m going to buy you a drink. I mean to say: your tester’s going to buy you a drink.
“I’ll throw this bit of work over the fence. I don’t need to tell the tester anything about it. Everything will be fine.”
With that attitude, most likely, everything will not be fine. It might be fine occasionally. But if you frequently throw work over the fence without any communication, teamwork, or consideration, at the very least, you will have a slighted tester on your hands. They might not tell you, but, oh my, will they quietly be annoyed at you. And you will eventually pay a price when that sneaked-in code breaks something in production.
“Works on my machine.”
You, my friend, have just poked the bear. If you’re going to say this or something like it in response to a bug you can’t recreate, at least follow it up with a conversation about the issue. Dismissing a bug that’s been raised with the disdain this message conveys won’t go down well with your tester. And, again, you might wind up paying a price with a production bug.
“You’re very good at what you do here, and we would be lost without you.”
This will prompt a mixed reaction of elation, relief at the recognition, and deep, deep suspicion. Don’t try to inflate my ego in public. It’s embarrassing for all of us. Don’t compliment me lavishly.
But do give me subtle praise, and you might want to say nice things about me to my manager, too. I need to know I’m valued at least every now and then. And I do like to have my ego stroked, despite the aura of humility I give off.
“This is technical. Don’t worry about it.”
“I will worry myself about it, thank you very much” is the response you might expect to receive. Don’t underestimate the technical knowledge of your testers, even if they don’t code. They often have deep knowledge of products and systems, and can possibly even teach you a thing or two about how everything hangs together. And if they can’t do that in a certain case, then you might be able to teach them a thing or two about how everything hangs together. Teamwork!
Let’s wrap this up, shall we?
Congratulations on getting to the end of this guide. I hope it has given you some insight into the mindset of a tester as well as some tools for better relationships with them.
If you want your tester to survive and thrive, then remember these rules:
- Treat them as an equal
- Respect what they can bring to the team
- Involve them throughout the SDLC. They often do their best work at the beginning rather than the end of the cycle, and testing should certainly never be an afterthought
- Don’t be surprised that they know things, even things you don’t know
- Don’t be afraid to be friendly. It doesn’t have to be all business
- Appreciate that they help make everything better
Following these rules can help to build a great relationship with your tester, and that can be a beautiful thing for everyone involved.
What do YOU think?
Got comments or thoughts? Share them in the comments box below. If you like, use the ideas below as starting points for reflection and discussion.
Questions to discuss
- Have you had good or bad experiences as a tester integrating in a team or as a developer helping to include testers in the team?
- Do you have any methods to help make sure testers are involved throughout the SDLC?
- Do you have any examples of developer-tester interactions like the ones above?
Actions to take
- Try to be good to each other and work as a team the whole time.
For more information
- Fostering Professional Excellence: Self-awareness as a Moral Responsibility, Barry Ehigiator
- The Good, the Bad, the Ugly: Teamwork for Software Testers, Gareth Waterhouse and Melissa Eaden
- More than just ‘manual testing’: Recognising the skills of software testers, Ady Stokes
