It is time to be more vocal about the profession’s pain points and shed light on the testing craft.

In the fast-moving IT world, it is vital not to lose your compass when drifting into the ocean of opportunities. The hype around automation and related tools sometimes pushes us to rethink the role of testers in digital product development. The biases around testing form the perception of testing professionals in tech companies which is sometimes reduced to “regression tests maintainer” or “bug detector”. The same stereotypes likely affect the self-perception of testers and create the feeling of being undervalued and as a result, underpaid.

However, in agile teams, the Tester’s job is not just applying various testing techniques but much more: analysis of user stories, reviewing prototypes, scripting test cases, monitoring of the system’s behaviour, researching user feedback, maintenance of tools for testing and test management, and so on.

At the same time, the existing biases might simplify the tester’s role. I observe testers are actively sharing their concerns within the professional community. However, fewer talks are circulating outside this bubble, and it needs to be changed. From my experience, a few pain points affect a modern Tester: a cult of automation, praising tools over testing strategy and inappropriate professional labelling.

“What is your experience with automation?” — that was the question from the hiring manager. If this question is asked as the first one, it feels that the company is looking for a tester who will automate the tons of tests that no one hasn’t touched before. However, there are a few issues to be aware of before any team rushes into automation.

Firstly, there is unrealistic thinking that automation of repetitive (regression) tests is a remedy for all the quality pain points. Let’s imagine that we have automated the majority of current repetitive tests. Cool! Let’s exhale deeply. Yet if you think that now you have more time for meditation, that’s far from the reality. What about the tests that will be added as new features are introduced? What about the tests that will be changed on the way as soon as some feature gets updated? What about the tests that cannot be automated? Your team will need a person who will orchestrate all of these things. Or even a few people if the scale of the product is impressive.

Secondly, sometimes the companies don’t even realise how expensive automation efforts are. One thing is to write the scripts in some tool: if the tool is like Cypress or Playwright, there are many hours of coding work behind the scenes. Another thing is maintaining automated tests and keeping them in line with all the product’s updates (it means another bunch of hours to “repair” the previously written testing code). Hopefully, this will be changed with the advancement of AI-driven tools. However, not every company has grabbed AI tools to apply in their testing efforts. Some prefer rolling down the hill and continue applying the tools their teams have been using for years (hello old buddy Cypress).

Thirdly, once you have a new batch of features that should be tested for tomorrow (yesterday), automation will hardly be your priority. Very often automation doesn’t look as fancy as it sounds. You will test new features by applying exploratory techniques in the first round because automating the tests is time-consuming. Even if you don’t have any burning deadlines for testing new features, you still need to use exploratory testing before automating tests in any specific tool. And it requires a bunch of time and effort from QA Engineers, on top of automation.

It would be better if the mentality of hiring companies and their representatives shifted into a more holistic view towards testing roles. A similar change is required in the tech community: the teams should embrace the constraints of automation and analyze the current state and resources carefully before starting any automation project. Because automating tests is always a project!

From the recent job interviews, I’ve learnt that people like to talk about the tools and frameworks they use. Perhaps, we tend to think this is already an achievement if one learns how to apply this or that tool. But what about the actual testing strategy? Is there any strategy that the team follows when using these tools? Do we apply some techniques randomly or on demand from the client (a request about a special type of testing, like a security one, etc.)?

Tools and frameworks are helpful when we know how to utilize them within testing strategies. It’s another (sad) story if we don’t have a testing strategy for our product. We can use some trendy tools as nice-haves. Yet, do we know where we are moving when applying this or that tool? What are our team’s actual needs regarding testing?

So, an overall testing strategy that includes a set of techniques and tools is an essential asset for every team. It is something that testing should be based on in the team. Like a grammar book for language learners, the testing strategy will reflect the system of testing methods and tools. But who should be responsible for it?

To make it more efficient, Wayne Roseberry suggests assigning a test owner: “The test owner describes the test approach in the test strategy. The team will execute on that approach as agreed by the team.” For me, it is a brilliant idea to have a person who initiates the discussion and keeps an eye on the testing strategy in the team.

And the best profile that will match this task is, of course, Tester! However, if your team does not have one, then this role should be delegated to a team member who is familiar with testing fundamentals and strategic planning. It is not an easy pair of shoes to wear, though.