Taken by Thiago Amanajás

Why just hiring a tester and automate everything won’t solve your problems

The quality responsibility is supposed to get distributed between team members, managers, and others that directly impact a product or project. But to a certain extent, it falls over a few positions, like testers.

It seems familiar nowadays to have in mind that only putting people with determined skills in the right positions will solve any problem. Of course, some still believe that you need to buy the right tool to fix it if something gets broken. But it doesn’t work much when it is about people.

As a tester, we have to overcome many barriers and not only technical barriers but social ones. Understanding the quality perspective is sometimes not present, and the tester represents the gatekeeper of quality, taking all responsibilities and the blame in case of an issue in production.

  • Comfort zone, the avoidance of changing perspectives or learning new things
  • Stereotype, the job title “Tester” can also bring an idea or a label with it
  • The idea that the tester will solve the problems of quality for everyone

I was a developer for many years before becoming a tester; I remember that my work felt more simple. I’m far from saying that a developer’s life is easy. I’m referring to that developers typically create some bubble around them and do their work there. Practical and straightforward it is for them. On the other hand, as a tester, you also have a giant bubble, and you need to work with their bubbles within your big bubble. The tricky part is that they might only see the 1/10 part of your job.

It begins with understanding what Quality Assurance is and why it is not only the tester’s responsibility.

Comfort zone, the avoidance of changing perspectives or learning new things

Improving or increasing quality is a duty for everyone, like the quality of your personal life, the time you spend with people, the quality of the job you do. And to improve quality, something is supposed to change. The same goes for the following:

  • If you move to another country: You will have to adapt to your new life.
  • If you try new things: You might have to accept failure.
  • If you change jobs: It might have a significant impact on your life stability.

Although we are talking about good changes, the uncertainty always will be present. It is necessary because they might challenge your perspective about what is happening in your zone of understanding.

Comfort zones remind me of the story of the cup of tea that I read here in Medium. If the cup is already full, it is not possible to put more tea. It means that if you are full of your ideas and concepts, you won’t accept anything else from others.

When you have to change how things are done inside the team or in a project, usually, it isn’t easy to deal with people with a fixed mindset. Therefore, convincing them that testing is not only in the tester’s hands is even more complicated because you can only change something when the change gets perceived as valuable for the majority.

Stereotype, the job title “Tester” can also bring an idea or a label with

Job titles come with an image attached to them, like Manager or CEO. It seems silly, but I think we also put a mental image of the person occupying that specific position. It might be no different when we say QA or Tester. We all know about the friction between testers and developers, and it is common to have arguments between them regarding requirements and testing.

Let’s put it in a different perspective. Every soccer player has different specialities like forward, midfielder, defender, and goalkeeper. None of them is less important than the other ones, and all of them are soccer players. Perhaps instead of having software developers and software testers, having only software specialists as job titles. Probably it would decrease or eliminate the stereotypes and walls between these two areas.

The idea that the tester will solve the problems of quality for everyone

Not only once have I faced the concept that a tester will solve every quality problem. Indeed, one person can solve everything, but it might not be accurate in most cases.

A tester can bring more visibility to the current issues, and I’m talking about defects or bugs and the whole life cycle and beyond the team.

Here are some of the tasks that a tester can do within the team for the project regarding the development life cycle:

  • Requirements analysis
  • Test case design, test case writing, test case review
  • Test execution
  • Exploratory testing
  • Acceptance testing
  • White-box testing
  • Bug reporting
  • Test Automation
  • Review of production code
  • Unit tests design
  • Carry on with releases
  • Production monitoring(logs, exceptions, graphs etc.)
  • A/B testing
  • Facilitate meetings
  • Communicate with stakeholders
  • Increase the awareness of the necessity of quality in a company
  • User testing

Looking at the list, I would say that a tester’s purpose is not only to test as the name says. But as you can see, it is to connect to different groups bringing different perspectives and visibility of what exists to add more long-term value to the company, project, team or product.

The concept of solving all quality issues by hiring a tester ends based on the idea that started this article, “buying the right tool for fixing the issues”. Although even if you manage to acquire the tool, if you don’t know how to use the tool and are not willing to learn, you’ll remain with the same problems.

Automation is essential to increase quality. It can remove repetitive work and complex tasks, allowing the tester to focus on more critical tasks. However, automating everything doesn’t guarantee that you will never need to test manually again. It is often the opposite. When your business is growing fast, or the market evolves, or your customers develop different needs, you also have to test new features, new designs and continuously do security testing and monitoring. Testing is focused not only on the functionalities but also on non-functional requirements like performance, usability, scalability, security, accessibility, availability, etc. Therefore, it is not possible nowadays to automate these aspects because it often requires the human factor.

Automation cannot replace a tester but might reduce the number of routine tasks until a certain extent when well designed, giving the testers time to explore the product.

For example, web automation won’t find new issues; it will prevent new system changes; old features don’t break. Focusing on web automation, for example, requires a lot of maintenance due to dynamic changes in the production code .e.g: selectors, components interaction, etc.

In many companies where I’ve worked before, test automation became an obsession. They didn’t realise at the time that it was costly, difficult to implement and that it requires a lot of effort and time to maintain. I’ve seen so far that the companies invest more money in hiring test automation engineers than trying to change the development processes instead and teach them that quality is the team’s responsibility. Therefore, some quality standards like the test pyramid, for example, are commonly never followed.

Another aspect out there is also a business point that pushes development and makes TDD a practice not to be followed, pushing the development to focus purely on producing more features and waiting for the testers to take care of quality. In other words: deliver fast and fix it later.

Instead of having the test pyramid in place, it creates an ice cream cone with a colossal amount of flaky automated tests on top and a meagre amount of unit tests or tests covering only the happy path low quality.

Conclusion

This article’s content is a personal perception during my journey. There is still so much to do regarding changing mindsets towards testing. Quality is a vast field on which we all have to work.

Now you know that hiring a tester is not the solution for every quality problem but the beginning of a journey. The tester will make visible the product’s current issues and the team and possibly the company and all different aspects. Therefore, the tester mustn’t be working alone to solve everything because the tester won’t do miracles, and the chance of failing is enormous. It is crucial for a company’s success that everyone is getting heard, is given a voice, and is involved in specific performance-related decision-making processes.

Although automation gives more comfort and enables the team to focus on what is more important, putting it into the team’s focus is not maintainable.

Among other things, testers have many perspectives to work on, and with the right support, they can bring more than what gets written in their job title.

References

Oleksii Levkivskyi — Can automation replace a tester?
https://medium.com/@ololyoshka

Martin Fowler — Test Pyramid
https://martinfowler.com/bliki/TestPyramid.html

Matt Valentine — Cup of tea: https://medium.com/the-mission/empty-your-cup-a-zen-proverb-on-accepting-feedback-f1cce7bfe4a7

Quality Assurance: https://en.wikipedia.org/wiki/Quality_assurance

Software nerd and data engineer enthusiast

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store