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.
Followed by…
@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!).
Peace…
Martial Tester 
Hi David, I haven’t followed the whole enchilada on Twitter, but I think I get the drift. As you know, I’ve been in the Testing and Quality game for around 30 years and I’ve built AND disbanded teams in my time. I’ve already re-sized teams. Here’s my initial thoughts (which I may also expand on within my own Blog if I get really fired up!!).
The number of people allocated to testing software is always vexing. It’s usually driven by budget or timeframes or availability of skills etc. So, if KC was pondering this question, the questioner must have had a reason to ask it – like, saving money. If I had been asked to remove a Tester from my team I would have asked what the motivation was (for the question) and if it was money, then I’d ask the questioner “how much money do you want to save?”. I would then ask what outcomes would they like to cut back on – maybe, removal of low risk functions from the testing scope. Maybe, they just want more for less (the usual real motivation…).
In my opinion, the original question is far too vague and requires far more context to be provided. I think I am now going to write a short series of Blogs on the reasons why it can be good, bad or ugly if you reduce/remove Testers (or the formal testing function) from a software development initiative.
You see, I thought I’d get fired up about this….
Cheers
Colin
“In my opinion, the original question is far too vague and requires far more context to be provided.”
Correct Colin, and I think you’d be hard pressed to find anyone who would disagree. However, what these vague questions help us do (if we give enough of a shit to do it) is go deeper on the subject and think of our own possible scenarios and call on our own experiences. I mean, you may end up writing short series of blogs on the subject, which is a great outcome!
I think we need to come to terms with the fact that we’re moving away from roles and focusing more on activities/actions. Who does those depends on who is best placed in the team to do them.
Imagine this… there are no role titles/labels. Someone joins your team and asks, “So what do you do?” Instead of saying, “I’m the tester” you may say something like, “I’m the one who interacts with the product in order to identify quality related information.” Which of those is more powerful?
I look forward to your series of blogs mate.
I asked myself the same question 10 years ago and did an experiment
https://mysoftwarequality.wordpress.com/2016/08/18/can-you-remove-a-tester-and-get-better-quality/
Thanks Gus.
You’re post is a good one, with great comments after it also. The overall sentiment of your post aligns with this part of mine… “However, does that human need to be called a tester?”
Quality is everyone’s responsibility.
David, I have been working with agile teams for the last 10 years or so, I use the name “tester” only to make sure that the people not familiar with agile understand what I am talking about. I believe in capabilities, not in titles, so the answer to your latest question is “No”
Pingback: Five Blogs – 2 November 2016 – 5blogs
“If we removed a tester from the team, would quality go down?”
Very interesting question. This is what I came up with, and what I believe in at the moment.
In a development team you need different competencies depending on (many things, but one is) the complexity of the product you are working on.
If you are working on a complex product which gives birth to complex testing problems, you need a high level of test competence.
If you are working on a simple product which gives birth to obvious or complicated testing problems, you need less test competence in your team.
In most cases, if the team is working on a product that requires a high level of test competence, you most likely need what we usually label as “a tester”.
If you are only facing obvious or complicated testing problems, then most likely the developers could handle it themselves, as high levels of test competence are not needed to solve the problems.
I wrote an article about test competence which ties into this, which you may or may not find interesting/agree with:
Best regards,
Johan
Thanks for your comment Johan, and for sharing your article. I’ll be sure to have a read.
A few things…
– When you say “obvious or complicated”, do you mean uncomplicated?
– How would you know you’re only facing obvious testing problems if you don’t have someone with a good testing mindset and/or good testing skills on the team?
– If you only have developers who focus on development rather than testing because you believe you only have obvious testing problems, are you not at more risk of missing the complex testing problems (because the developer mindset may not be looking for them)?
Good questions 🙂
When I talk about obvious, complicated and complex, I am using terms from the Cynefin framework:
Obvious – in which the relationship between cause and effect is obvious to all
Complicated – in which the relationship between cause and effect requires analysis or some other form of investigation and/or the application of expert knowledge
Complex – in which the relationship between cause and effect can only be perceived in retrospect, but not in advance
Let me try to cover the other questions. Someone always has to have focus on the testing, but if we are facing obvious or complicated testing problems then that someone could be a developer (or someone with less competence in testing) instead of a tester (or someone with more competence in testing). Or so I believe. However if you have a complex system, and let’s be honest – most systems we work with today are complex, then you need someone with high test competence in your team. You could be lucky and have a developer with a high level of test competence, but more often than not that is not the case.
So how do you know what type of testing problem you are facing? If the system is obvious or complicated, but not complex, then chances are that the testing problems you will face are also obvious or complicated, and the other way around. If you have a complex system, then most likely you will face complex testing problems. And this almost always what we face. Someone with a high level of system knowledge could probably analyze the system and try to put it in one of the categories – could be a developer or a system architect or someone similar.
Anyway, the key is that we need a certain competence in a team that is developing a complex product, at least that is what I believe. And in most cases you need someone we usually label as a tester to cover that competence gap.
I think that the unique competence that someone with a high test competence brings to the table is solving complex testing problems.
But I may not have thought this completely through 🙂
Best regards,
Johan