Do you think there are organizations that genuinely don’t need software testers? What makes the difference?

Discussions
, ,
1

Read my MoT article, “When hiring software testers doesn’t work (and what to do BEFORE you hire them).” It explores an inconvenient truth: sometimes folks who say “hiring software testers causes more harm than good” are actually onto something.

This isn’t because quality work doesn’t matter (it does!) but because teams often hire software testers without knowing what they actually need. They chase test automation fixes for deeper organizational problems. Or they expect quick wins without giving software testers any real influence. And when things don’t improve, they decide hiring software testers “doesn’t work.”

This article digs into the failure patterns I’ve seen most often and gives guidance for success in hiring testers (and sometimes refraining from doing so).

What you’ll learn:

  • Why software testing hires can “fail” even when that hire is doing the “right” things
  • The difference between solving for symptoms versus fixing root causes
  • How to know if your organization is ready for software testers, and what to do if you’re not there yet
  • When the “hiring software testers isn’t worth it” take is actually valid

After reading, share your thoughts:

  • Have you ever seen a team make the “wrong” software testing hire? What do you think happened?
  • How do you handle expectations when people assume software testing equals test cases plus automation?
  • Do you think there are organizations that genuinely don’t need software testers? What makes the difference?
  • If you’ve ever been interviewed for a testing role where no one in the room had done software testing, how did you navigate that?
8 Likes
2

This is a really great article, Susanne!

I really resonated with it as I have been that tester that was hired in an org that didn’t know what its quality problems were.

I think my struggle in that org was that I was new to that kind of environment and so I didn’t know how best to navigate it at the time.

So I was stuck in a situation where I didn’t know what to do and they didn’t know what they wanted, which was a complete mess in the end :sweat_smile:

I’m actually planning on doing a talk about that experience very soon!

1 Like
3

I had many clients come and say they need a tester and by tester they mean automation engineer to create regression tests.

The reality is like the article suggests that is not what they need at all, they need a decent review of where they are and what is the root cause of their quality issues and particularly if they actually have a regression problem.

In most cases its rarely primarily a testing problem, its usually something else however getting some regression risk coverage is often a small part of the solution.

There are a whole load of problems, could be development process, developer lack of due diligence, over complex systems and so on and rarely a testing problem. Developer lack of due diligence and no testing can be made worse by adding a tester as they just palm off quality responsibility to someone else.

That though is also very different from the consideration of would they benefit from having a tester on board. That’s a risk question.

Are you comfortable that developers or someone else are doing fairly deep sufficient testing in terms of your risk level, are you confident that you currently know all your risks and know them well enough. If that is a clear yes then perhaps testers are not required, I’ve consulted with teams who are in that situation and adding a testing would not improve much but it is rare due to the nature of software development that everything is new and new things carry unknowns and there risk that testers specialise in discovering.

I am an advocate of a lot of developer testing, to the extent I’m comfortable saying the most efficient model is for developers to cover the known risks aspects which means they own automation coverage perhaps with assistance of testers. The tester role then extends that by embracing the unknown side of things.

When the unknowns are limited and controlled perhaps the tester is not required.

2 Likes
4

Probably a bit like @eamond15 , I have just landed in a position where the org knows they need a tester, to automate stuff and all, but they also need a “quality person”, a quality champion who can bring all the people who have a stake in the product together with a quality vision of what is realistic. I’m luck enough to have 18 years of QA background and more as a engineer. But being the only tester is not a job to give to someone who has not got airmiles in this job. Those teams who think they do not need a tester very quickly decide that they do not need a software tester with just automation skills at all. Developers can do that, but we all know from experience, that they cannot sustain it for any significant period of time. And the honest answer, is that they don’t need that role, of an automator. They do need a change of mindset and scope.

On the flip side, there might be entire sectors out there that do not need a software tester. I’m working in one, we sell hardware, not software where I work. So no wonder, but we do hand out software, quite a bit of it, and usually it’s so environmentally specific, that the only way to test it is to let a customer tell you what did not work, and then sometimes go out and help them either change a part or make a small software change. A lot of our issues are hardware related, not software, but we are unique and very low volume. The millions of customers for cloud and other high volume products detect probably over 80% of the defects that need fixing. The basic kind of tester there is often a glorified user who has access to better documentation themselves, and does not drive quality. In the mass-market situations someone automating tests is eventually playing the role not just of tester, but also is wearing many more hats. But eventually everyone needs a tester in-house.

But it may sound like I am going around all of the houses, but almost everything relies on software these days. With more industries either becoming regulated, or environmental (marketplace) changes being forced on them, they do need someone with a dedicated software quality mindset. There are enough hardware companies out there who have had their product hacked and had the business go under as a result to make it obvious. So please do name any and we can do a quick risk assessment together.

2 Likes
5

As already said, they need a “QA lead” to set the proper expectations and requirements.

  • “strong developers with quality mindsets”: This is the recipe to disaster, always
  • teams conclude that “software testing doesn’t work.”: I bet they don’t know what is testing

May I suggest a change in the article? Testers don’t find problems, testers find useful information.

1 Like
6

I decided not to read the article first @susanneabdelrahman . I’m going to blame my ADHD for that, because it told me that I agree with you already but my brain had so much to share first; and that I would not be able to objectively and calmly read what turns out to be a brilliant essay!

On one point, I do differ, startups don’t need hire a QA ? And then build tech debt that they later have to pay. They do their first release, and keep going without thinking about the future, because hey we have a patch release to get out, and we just hired a office manager, so we are fine for now. In product security it is often intoned that you have to build security in on day one. Quality is very much the same, just like security, it’s more expensive to make a 5 year old app secure if you wake up too late, and testability is no different. They don’t need to hire, but they really should bring in a contractor or consultant to bootstrap their mindsets.

I think far too many teams never sit down to think about what is holding them back at a cultural, at a physical or environmental as well as political level. What are the business constraints, and what are the goals? Many small companies and even large companies struggle to put into words, what are the limitations artificial or real of their business, and which stakeholders are chasing which goals. Alignment only gets harder the larger your virtual “geography”. People need to talk openly about how expensive it is to write customer docs, or how all the requirements are now so old that they are just not useful, that’s bollocks. Every artefact of the process has value, if not don’t do it! We all need to talk about “definition of done” when a new person joins the company for example. The list goes on, but just like making sure you stop to sharpen your axe if you are a woodsman, software engineers never ever do that. Why?

I think, that in a large company that eventually decides that developers are not that suited to testing because they also face release deadline pressures and process overhead costs, are companies experiencing exactly what you describe @susanneabdelrahman . But they have usually far too much momentum culturally and dept, technically for one dedicated QA to make a big difference. “Big ship can be turned by just a small rudder” stuff does not highlight how pointless just 1 QA in a company of 100 people can be.

In a small company, 1 QA can make a difference, and your essay has super inspired me. I’ve been doing all the activities of automation, building frameworks, finding old test code resurrecting it, writing test plans (oh BTW my ace tip for writing test plans is to use AI to draft them) and doing all of my very best experience based testing as well as exploratory testing. If you are a lone tester, the org already knows that it’s quality is sh42t, so give yourself some breathing space. But the approach you are describing Susanne, is much more useful. By weird co-incidence I had just this same conversation with the software engineering lead. I know my job is to test stuff, but also to build a quality mindset my boss told me. I’m glad he decide to hire a unicorn, I know this is a tough job, and I’m loving the fact that I’m likely to burn myself out if I try to limit my role to software testing, or if I shoot too wide. I’m going to steal your ideas for my next powerpoint show and tell. Cheers Susanne.

(with a link to your page of course)

2 Likes
7

This is a FABULOUS article and I am going to go share it widely!

In the last few years I’ve met some tester-less teams that THINK they are quality-minded and practice good dev practices such as TDD, CI, pairing and more. And yet, they have a lot of customer-reported production issues. They say “Oh, these are not bugs, they are missed requirements” and “Oh, we didn’t expect them to do that in production”. When I dig down and find out about their development process, I learn that they get requirements from product, they do work together to discuss the requirements, break features into stories etc. And - they do not question the requirements at all. They don’t do any kind of practice to identify or discuss risks. They don’t do any practice to find the main value to customer to focus on. Nobody asks the “What if…” questions.

Anyone COULD do these things, ask these questions. It doesn’t have to be a tester. Yet IME when I talk to teams with no testers - nobody asks those questions or proposes doing those practices. So yeah - they miss requirements, their product people make mistakes in specifying requirements, they don’t think about different scenarios of how customers might use the product or what bad things might happen. It’s weird.

IME if the domain is a product FOR developers and it’s a product the developers themselves use - they don’t need testers. If it is a business domain with little risk, nothing that endangers people or costs them money, they may not need testers. Otherwise - they usually need at least one quality engineer / test consultant who can help everyone on the team learn to build quality in.

5 Likes
8

Thank you, @eamond15- I’m glad you enjoyed it!

Oh yeah, that sort of limbo can be brutal to operate in. I’d love to hear your talk when it’s ready! I bet it’ll resonate with a lot of us.

1 Like
9

So this is a common problem, then :rofl:

But as you said these problems are often not (only) testing problems. And I love the distinction you made between known risks (where developer testing can be really efficient) vs. unknowns (where testers add the most value)

10

@conrad.braam Ha! I love that you went with your gut first and then read the article. And thank you for the kind words!

You’re absolutely right about the lone tester role not being for someone without experience, and I think teams underestimate how much ambiguity and org navigation comes with being the “first” anything (but especially QA).

I totally agree that by not hiring QA they’re likely building tech debt into their product. I just think that most startups never really get to the point where they need to worry about that debt - and if they do, that’s good problem to have :sweat_smile:

It can be hard pushing for change as the only QA person in a large company. I’ve definitely been there. I do think it’s possible, but there needs to be an appetite for improvements (and maybe also all of the stars and planets need to be aligned as well :rofl: ).

At a smaller company, you can see the impact of your work much faster so that “build a quality mindset” mandate from your boss sounds super exciting. I’m so glad the article inspired you - steal away!

2 Likes
11

Thank you Lisa! That means a lot coming from you :smiling_face_with_three_hearts:

And YES to all of this. I’ve seen the same dynamic with teams that have “good dev practices” while also somehow being weirdly anti-user :thinking:

Yep, I think QA folks are often the only role that has the permission to slow things down and zoom out, while also holding enough technical & product context to also ask those questions no one else is thinking to ask.

1 Like
12

Really thought-provoking read, thank you for putting this on the table. I do want to challenge one framing though. The idea that testers can “cause more harm than good” feels less about the testers themselves and more about how organizations position them. A tester pointing out systemic flaws does not create harm, it surfaces truths that were already hurting the product.

The real harm, in my experience, comes when leadership brings testers in reactively, without the willingness to act on what they uncover. That is when frustration sets in, and the role looks like a bottleneck rather than a value-add. Strong developers with a quality mindset are valuable, absolutely. But their lens is not the same as a tester’s. Caring about quality is not the same as having the craft to probe for risks others do not even see.

I love your point about readiness and influence being key. If testers are empowered to shape requirements, priorities, and processes, they become force multipliers. Without that, they are often set up to fail. Curious to hear your take: how do we make sure this nuance does not get lost, especially when CEOs may only latch onto the headline that “testers might not be worth it”?

4 Likes
13

Yes, I agree - nothing to challenge on my end!

Honestly, I think the CEOs who are quick to latch onto that bit already believe it and don’t need my headline to justify it :sweat_smile: My hope though was that the title would pull them in enough to keep reading :woman_shrugging:

14

Another brilliant article @susanneabdelrahman , I’m becoming a fan! :heart_eyes:

Yeah…me! About 10 years ago I was brought into an energy company and headhunted by people that had worked with me before who I respected. When I came in they wanted me to test, improve automation and coach the team etc. but farely soon it was pretty clear to me that their wasn’t a clear engineering strategy. Some of the software was 3rd party products, or 3rd party bespoke developments and the in house developers roles seemed to be papering of the gaps inbetween all of these systems. The key CRM system was bought cheaply and was so awful that I tried to influence my leaders that this system needed to be replaced. I was delighted when we went through a supplier review and I was taken along to assess each supplier’s quality processes and delighted to a have played a role in the selection process. However, that euphoria came crashing down when we a team leadership meeting that “asked people who wanted to be involved in the project?” and nearly everyone took a step back with the exception of myself and the dev lead. We looked at each other and said “It’s our job isn’t it?”. They then proceeded to hire a contract project team to manage the migration team…shortly after I resigned…”I can’t help you” was my simple explanation.

Yeah totally along the lines your article suggested. I was in a small startup that had 20 employees in total, 3 developers (inc me…when visual basic was all you needed :wink: ) . They hired a tester, because they thought they needed one “to free up the developers”. But each developer was working on unique products with unique release timelines…it just didn’t work. I was always very quality minded so not only did I enjoy making sure my software worked well (and was mortified if it didn’t) but I would also enjoy working with the customer to make sure what I was developing was what they were expecting. It was a poorly run business in its infancy, but I think that organisation gave me the biggest insight into what was needed to ensure quality, even if I didn’t know it at the time.

Well I can honestly say I have never been interviewed for a testing role but someone that had done testing. So you can imagine, a lot of my initial questions in interviews are finding out why they think they need one.

1 Like