So, Katrina Clokie (KC) tweeted a tweet last week…
Still thinking about this question that someone asked me a week ago: “If we removed a tester from the team, would quality go down?”
To which my initial reply was…
@katrina_tester you never remove a tester though, you remove a person and that person is unique. So very hard to answer.
@DMGreenlees Yes, thank you for articulating so clearly one of the reasons that I’m finding it difficult to find a generalised response.
@DMGreenlees I feel like there should be a “these are the 5 things to consider” type of response, but I can’t even nail that. Yet.
So I started tweeting my thoughts on some of them (which I’ll articulate further below), and that was followed by a few more tweets from KC, including this one…
@DMGreenlees I feel like we’re thinking about the question entirely differently, and I’d like to read your blog on this topic 🙂
…and here we are. 🙂
So hopefully KC will reply to this with why she thought that, because I’m still a little confused by it. Anyway, there were quite a few replies to her initial tweet and many ‘cautions’ about defining what quality means… which I completely agree with. However, I’m stuck by the ‘remove tester’ part of it so I’ll stick with that for now.
My first thought was in relation to ‘tester’ versus ‘testing’. I know KC reasonably well, so I was confident I didn’t need to clarify and that she in fact was talking about the role of the tester rather than the activity of testing. With that I moved immediately to thinking about the person who was in the role of the tester because, let’s face it, a role description is only ever as good (or bad) as the person performing the role. With that, there was no way I could answer the question without getting specific about a particular context, which wasn’t going to happen on Twitter because I hate conversation on Twitter. 😉
So I tweeted my initial response.
After KC acknowledged and mentioned the ‘5 things’ I tweeted the following…
@katrina_tester 1. Mindset, 2. Skills, 3. EQ/personality, 4 and 5. Hmmmmmmmmm
@katrina_tester 4. Current team fit. How they work together. Are they a motivator/demotivator? Do they hold it together?
@katrina_tester communication is too broad and sits in skills anyway… help me out with 4 and 5 KC.
@DMGreenlees 4. Support (from other people/teams & artifacts/automation/monitoring) 5. Quality (depends what it means to your org?)
Notice how nothing we’ve mentioned is ultimately role specific? It’s all very much related to the individual who may be removed, rather than the role. So when reading the following consider it in relation to a specific person in your team, the one that you call tester and performs the role of tester (whatever that may mean to you).
- Mindset – I’ve often said the following… developers are positive, testers are negative. Now before you get angry with me, let me explain. Developers build stuff. Sure, they may break things down in order to build, but ultimately they build, create, bring life to new code. Testers seek to break things down. Sure, they may build things in order to break other things down, but ultimately they find breaks and disprove. If you remove a tester who likes to break things down, what impact will that have on your team and it’s output?
- Skills – Humans are unique. Each bring different skills to the team. You may have two testers who are both brilliant with SQL, but does that mean they look at things the same way? No. Skills go much deeper that how they use a keyboard, or what they may have listed on their CV. So when you remove a tester, what actual skills are you taking away from the team?
- EQ/personality – Sure, you could put this under skills and call them ‘soft skills’, but I won’t. I’m calling them out separately because that’s important I think they are. I’ve worked in many teams over the years and it’s always been fascinating for me to watch how people interact with each other and find their place within the team. Introverts, extroverts, people who have empathy, people you don’t… oh, and there’s usually at least one ass-hole. Taking one person out of the mix can have a huge impact, which can be very positive, very negative, or somewhere in-between. So, go ahead… remove that tester, but think about it first.
- Current team fit – In hindsight, this is likely an amalgamation of all 3 points above. Everything adds up to the ‘team fit’. I guess I was in a hurry to produce a number 4!
- Communication – Yeah well, like I said in the tweet… too broad and likely sits within skills also. However, it’s still very much worth considering when thinking about how your team communicates, and more specifically how the tester you’re going to remove communicates. They may very well be a conduit to the wider team. In my experience testers seem to fit well in that spot as they tend to have a broader perspective of the project… focusing on the initial business need right through to the developed solution’s use.
I’ll let KC explain her 4 and 5 (hopefully – please KC?).
So the key message from me is exactly what my initial tweet said – you don’t remove a tester, you remove a person performing a role. Getting another person to perform that same role, or the activities that are intended to be performed by it, will always give you different results, always.
So who has removed testers and what happened?
Example: Atlassian QA Model (there’s way more than one link BTW) – OK, so they didn’t really ‘remove’ testers. They changed their approach, and the role seems to have changed with it (although the number of staff appears to have significantly decreased in the ‘testing’ space). What happened? Well, from what I’ve researched the outcome has been more positive than negative. I don’t work there, so I don’t know this first hand, but it appears to be working for them.
I’ve used (and still do use) Atlassian products, and my experience has always been quite good. So if I’m a measure… well done Atlassian.
Unfortunately (or perhaps fortunately) my first hand experience has always been introducing testers rather than removing them… so I can’t add any personal experience. However, the way the industry is moving, I think I’ll soon be experiencing the removal. Things move quickly these days. The time available to explore a product is constantly shrinking as we push things to production faster and faster. We’re pushing automation to developers (which I think is good), we’re doing more automation (which I also think is good if it’s well thought out), so the need for large numbers of testers is reducing. I don’t believe there will ever be a point where we won’t need a human interacting with and exploring a product (not in my lifetime anyway). However, does that human need to be called a tester?
Ah, and now we return to ‘tester’ versus ‘testing’… so when removing a tester don’t just think about the role description. Think about the person you’re removing and the activities they perform. Will the other members of the team be able to do what they did? Think… and I mean critically.
I liked this from Aaron Hodder…
@katrina_tester A team is a complex system. I don’t think you can predict the outcome. (plus let alone diving into “what does qual mean”)
A complex system indeed, and why is that? Because they’re built with humans!
Also, again, that caution on what quality means… an extremely important part of the equation which many books could be written about (oh, they have!).