Why Do We Need Testers?

Questions
#1

I saw this question pop up on Slack and I thought it would be excellent to transfer to The Club as I’ve seen variants of it come up frequently.

How would you sell yourself when someone asks why do we need a tester when they have full stack developers who can dev and test? apart from regular answers like different pair of eyes, testers having different approach to that of a developer, identifying bugs being main priority for a tester etc…

The replies on Slack were:

Depending on the devs’ level of testing skill, I would either sell myself as a quality coach or just become a developer.

When I’m doing development work I’m in a different mindset then testing; it takes mental effort to switch gears

  • Being a Quality Advocate, not simply a tester - pushing for quality across the board, asking questions, ensuring good definitions, testing as a user etc
  • Exploratory testing, not simply acceptance testing or checking boxes
  • Different mindset and role reduces cognitive bias (check it works as I expect, vs. what happens when I do this?, will this break it?)

I’ve seen some really great developers in my time who were very skilled at exploratory testing so I lean towards the quality coach response myself.

What about you? How would you respond?

2 Likes
#2

When I hear “developers can test”, I assume they are comfortable doing manual exploratory testing, creating test automation and integrating that into a CI/CD pipeline.

If the developers can do this, and the business hasn’t suffered, they might not need a dedicated tester. But if the business notices bugs in production, then it might be beneficial to seek help to find better ways to test.

At first I can see bringing in quality coaches to help. These coaches can help the developers be more effective in their manual testing and their test automation. As the business needs grow, other testing specialists might be needed such as improving performance and accessibility.

My main point is that the driving force for this decision should be the needs of the business.

4 Likes
#3
  • I do not have enough information about the context or the product, project, stakeholders so I would like to know about how things are working on a daily basis and at their worst times;
  • I would also ask what are some of their problems of users, of stakeholders, of release timelines & confidence, of current testing costs, of refactoring/patching product code, of law/regulations/standards, of demands/requests, claims/marketing/support, etc…
  • I would also then mention what a tester actually does: find threats to the quality of the product - through technical empirical investigations on behalf of the stakeholders. Some examples might be useful…

Why do we need a tester? is like asking 'Why do we need someone to find problems to the quality of the product? I can’t answer for the person asking…

#4

I’d say "All depends on what you mean by ‘testing’. If all you mean by ‘testing’ is ‘making sure all the buttons do what they say they should’, then fine, you don’t need testers.

But if you want to find risks to the integrity and acceptability of your product before end users - who may vote with their feet and/or wallets - then you need testers.

And when (I say when, because it will happen) some embarrassing bug crops up, and everyone on the Net is laughing at your product, and you ask “Why didn’t we pick this up in testing?”, unless you have testers, you’ll have to understand that you, yourself, is included in the “we” in that question."

2 Likes
#5

Greetings!

We don’t need testers or testing. I tell project managers that testing is optional.

Testing is an information collection and reporting activity. If a project can develop a product or deploy a product without the information that testing provides, they should do so. That is a project management decision.

However, continuing without knowing the behavior of the product, the performance of the product, or the value to the business of the product incurs a great deal of risk. If a project manager decides to accept that risk, then testing is not needed.

I have not had one project manager turn away the services of a testing team when I explore risk with them.

Joe

1 Like
#6

As always: It depends. :slight_smile: Without reasonably sufficient information & context this question is impossible (or at least hard) to answer.

I’d usually respond with “I don’t know, you tell me.” — If they assume (presume?) that testers are not needed, I may suggest to send them on a long (paid!) holiday, say 3 or more months. In most situations that is long enough to see whether testers are needed or not. If they seem to be extra bold I might even suggest to fire the testers and then see what happens.

Sometimes it helps to figure out a) if testers have found bug in the past and b) in that case what bugs they have found.
In the (unlikely) case that the testers didn’t find anything, well maybe they are not needed that much. But even then having testers may have a psychological effect on other developers in the team to be carful in order to not produce bugs.

Stephan

1 Like
#7

This question should be answered on two levels - 1. team and 2. the industry as a whole.

At a team level, it’s welcome if developers want to test. As long as they are clear it doesn’t involve code. The challenge is to be able to demonstrate to the developer how you can find bugs that he/she wouldn’t. I also think it’s fine to be able to influence developers on how to test. It would have been nice if teams who do this, also explain testing on their blogs or public talks. In most cases, in these teams, testing is some variation of automation.

At the industry level, this is a tired question. Is there a single blog, talk, book which shows a developer testing? If not, why do we keep having this tired discussion? To me, this is often promoted by testers who are advocates of coaching, not developers.

There are a few examples of devs explaining testing. The Ruby community is particularly good at this, because of their focus on test first. Brian Marick shows how to test in his book, Everyday scripting. There are others who are also good like Sandi Metz and Russ Olsen. However, they are all very code focused. They still make the good point that they ask a lot of questions and there is a back and forth to find a good solution.

More later…

1 Like
#8

@seasidetesting " I might even suggest to fire the testers and then see what happens."

They did this in my last role. The day after I left, the company posted online to say “Click here for a virtual tour of our new city centre offices!”

Of course, no-one had thought to actually test the link first.

2 Likes