For sometime whether it be social media, interviewing testers or attending conferences the debate of “Manual” vs “Automation”  testers keeps arising.

Not a great fan of the terms “manual” and “Automation” tester but will use these terms as they are widely used.

Two Camps

There seem to be two camps, each with a classic stereotype, here is an exaggerated stereotype of each below (simply to contrast). 

The “manual” testers would have traditionally executed test cases but may now use explorative testing skills, these testers are more likely to attend general testing conferences/meetups and are often drawn to “human-centric testing”.

The value such a tester brings is their critical thinking, risk assessment, ensuring value is being delivered to the customer and brings great testing skills that can be shared with the team. In simple terms, they ensure that the team don’t get pigeoned holed in their thinking simply around the technical implementation.

A drawback is that they may not be comfortable with mobbing sessions, code reviews and “technical” conversations. Which may limit their value at certain points in a project. 

The “automation” testers love to implement test automation, are more likely to attend automation testing conferences/meetups and are often drawn to “technical” testing, and perhaps see switching to being a developer as a career goal.

The value such testers offer is that they can contribute to automation efforts and perhaps other activities such as code reviews and be more actively involved in mobbing.

A drawback of such a tester is that their focus is on automation code, so in some instances they do not develop their overall testing skills and at times can get stuck in the weeds with the wider team.

Also automation efforts need to be given the same attention as the source code. In general, people should only work on test automation if they can also write the source code, or at a minimum pair with a developer. (Might write on a blog on this topic in the future).

Why balanced?

Some companies are happy to have two different types of Testers. In the book how google tests software they describe two roles

1. Software Engineer in Test (“Automation Tester”)
2. Test Engineers(“Manual Tester”).

Personally I advocate for balanced testers, perhaps because I have found myself in both camps at various points in my career and started to realise that both identities are limiting both in terms of career growth and adding value to a team.

A balanced tester considers risk, has developed their critical thinking skills and can be the team member who pulls everyone out of the weeds. Whilst also having a “technical” side to their game, perhaps not at the same level as the developers in the team but “not afraid” of code. Typically open to participating in code reviews or willing to pair with developers on automation or writing pipelines.

But not only that the balanced Tester looks at the big picture and asks where can I add value across the entire SDLC. Often their focus will switch to the wider concept of Quality rather than focusing on the activity of testing .

A balanced tester may ask questions such as 

• Where is there waste(“toil”) and where can we add value?
• Should we be investing more in Observability?
• How can customer data analytics help us develop new features and measure success?
• Are we engaging enough with our customers and do we understand their problems?
• How will this feature affect our internal stakeholders like support and sales? 

A balance tested can also look at the bigger picture from a career perspective. Testing is their speciality and they build on others skills too such as data analytics, coding, observability, cloud, security and learn from other disciplines such as SRE, UX, Infosec and developers. 

Generalising Specialists

Much of what is described above could be labelled as Generalizing specialists, often referred to as “T-skilled” people(I know this word has started to make some people cringe).

“Generalising Specialists” are those who have a specialised background who also specialise in generalising. This aligns well with agile and a team’s consisting of “engineers”, who have a specialism such as testing, development, or infrastructure. 

Summary 

For so long there has been “two camps” of “manual” vs “automated” testers which is limiting, and do little for the reputation and future of testing.

For testers to become Generalising specialists, they may first need to find balance as test specialists and then focus on other general skills that will grow their careers.