It’s a compelling post with plenty of solid arguments. Plus great advocacy for reasons a company will likely need a tester if they think they don’t.
What’s your experience been like? Have you ever experienced a situation where testers aren’t required? – given that you’re likely a testing professional reading this and are currently or were part of an engineering team, I appreciate the paradox, yet I wonder if you’ve had testers let go for the reasons Alessandra has mentioned.
Curious to get your take and lived experience of this.
This is actually the reason I and the other QA Engineer I worked with were let go from my last role.
The company had a Customer Success team that worked closely with customers on the product but also performed QA tasks. The company decided that this was more necessary than traditional QA Engineers and so, we were let go.
Not actually sure how this has worked out for them after the fact
Even though the article mentions Google and Facebook teams working without testers, however, in real many normal companies are inspired by this thought as they consider the testers a liability instead of assets.
I have seen people who say that since developers have written the code they have to test, while I have also seen clients who refuse to pay the billing hour of bug tickets by saying that it was the developer’s fault who wrote the wrong code if they have written correct code then testers wouldn’t be required at all.
In my opinion, when we talk about SDLC we consider the whole software development life cycle as a system of which testers are also part and if we remove the testers then either the system may crash or get de-stable depending on how crucial testers are in the system.
No matter how much we automate the software, still market is surrounded. by stereotype that anyone can test and hence we don’t need testers… and fighting that thoughts and proving the importance of testers in such cases is bit tough but is worthy…
Not having dedicated testers shouldn’t be seen as if the software isn’t tested.
It probably is to some degree by the various people involved either through diligence of their own roles or taking temporarily the role of a tester.
And that might be enough.
It’s up to the company to decide when the failures affect them financially and when they think potentially that a dedicate person could spot most of them ahead of the impact.
Some also rely on their image being impacted before considering getting testers.
Then some companies might be hiring bad testers to start with; it’s hard to recruit well.
Then some might have bad experiences with bad testers so they’ll decide to fire them and not replace with anyone else.
It’s not about what we want and how we feel companies should conduct their business, as it’s not a tester/user oriented world out there…
As I read it the case Alessandra makes is for the technical tester, so someone who can maybe even help with the coding, help out with coding tasks such as unit tests (which I see very much on the developer’s side). And of course, if you have a startup you probably wouldn’t have testers, but to me, that’s more a question of funds.
To me, somebody who does the testing is not necessarily a tester, because he may not have the mind set required. A developer testing his code (or somebody else’s) could be thorough, bend on finding bugs and checking the overall functions of a program. But he/she could also just go through the motions, just the recent functions, “yeah, works ok”. Meaning that testing requires a certain mindset, not an official role or even a special training.
Testing could be done by a dedicated tester or can also be done by a secondary role such as manager, PO, BA, or even a Dev (Unit Testing / Sanity Checking).
Quality of the outcome will vary of course.
I have worked in both kind of teams - One who had testers from Day 1 and the other one who got a dedicated tester after 3 years.
The one who got it later respected testing and tester 10x more because they had spent time without it and knew the value that testers brought to the table.
A few weeks ago I read a post that someone on Reddit posted about his laid-off story, so basically The guy had been working in an insurance company since 2020, and as things started getting normal and people were being called back to the office, his company started looking for ways to decrease the operational cost. In 2022, the company started implementing AI and removing developers as well as testers, things were okay for 6 months but then prod bugs started coming and the company got into multiple financial lawsuits, hence to resolve that the company declared itself bankrupt in November last year and laid-off all employees.
And the guy regretted not switching back in 2022 when things started as job opportunities were better in 2022 as compared to the current market.
That’s just one decision, if we see around us we will multiple such cases happening in real world.
So in my opinion company may or may not regret its decision, but those who are negatively impacted by it definitely regret being part of such a decision.
I would say you always need tester…but it depends who is doing it and what the success criteria is that they’re aiming for. How high that bar is, will be pivotal as what level of testing resource is required. There’s a reason our profession exists and its not because no-one else wants to do it. Its a very different skill.
For example, if you have customer that has 100% bought into the prospect of getting a new product and being part of that process, then in its early stages that success criteria could be “have something demonstrable to the customer to get feedback”, then its about making sure its working enough to get that feedback.
A tester would still be immensely valuable as a “quality consultant” to guide designers on say usability but the software itself may not need to be rock solid. I ended up in that position when I was hired as the sole tester, the direction of the product was so bizarre that I had to keep shifting left to ask the question “What is the product actually for and why should our customers buy it?”
I’ve never been in that position having worked most of my career on government or local authority contracts, so the bar has always been set high enough that dedicated testers were needed.
It’s a good article and I generally agree with the key points made.
Not all testers are equal is a very important one.
I’ve found that developers have a slight bias towards known risks and are very good at that coverage. If the tester on the team carries a similar bias and not something significantly different then the value in my view drops, they may even be indirectly doing harm, I struggle though to go as far as suggesting developers drop due diligence even if testers are doing the same thing they can do more efficiently themselves.
If managers and companies only view that model of testing it can become a very strong voice that testers are not needed. This one is of particular concern because the decision for testers is only based on a narrow view of the value testers can bring.
A testing bias towards the consideration of the unknowns significantly changes that thinking as it can offer much more than the developers own testing that goes more into learning, exploration, investigation and experiments.
Even with a good understanding of the latter though I still encounter successful teams without a pro tester, I look at this as a risk decision.
Are you comfortable that you feel you know about and enough about the potential risks and you deem impact as low. This matches the simplified decision step in the article which may be a better way to get the message across than my own known/unknown bias discussions.
Rather than dropping pro-testers it makes sense to first consider can we change the value they are offering to compliment and extend developer testing rather than replace it.
