Why do Manual Testers Still Exist?

In the April 28th edition of the Sauce Labs blog, Joe Nolan ( @JoeSolobx ) Mobile QA Team Manager and founder of the DC Software QA and Testing Meetup posted an article, "Why is Manual QA Still So Prevalent?" In the article, Joe argues, "With the importance of catching bugs early, and the ability to automate all testing, why do companies and projects resist the investment in [Continuous Integration] and test automation?" and talks about an "automation first" strategy, building automation as the product is being built.

Joe then list reasons why not all companies have embraced automation, such as:

• Management -- except for the QA Manager -- doesn't articulate support for automation
• The development team hasn't giving the buy-in to be responsible for developing automation as they develop the product
• The QA Analyst has trouble committing the time to learn automation, doesn't know where to start learning, and not given a chance to apply knowledge once learned.

I agree with these points, especially the last one. After a long career as a Manual QA Engineer and a newly minted one as an Automation Developer, I don't know how I would have been able to manage in my new role -- although I was decade ago -- had I not finished grad school for software engineering.

My problem with the article is that I believe a manual tester should never be obsolete!



A Manual QA resource embedded in the DEV team is not simply an extra pair of eyes on a project. Doing away with the role in a company is a tragic mistake, silencing the different mindset needed to make a successful product.

My job as a software tester has always been to act as an end-user advocate. I provide a voice for customers of the web application that I am testing. After distilling both the product requirements and the user interface design into test cases, when I was a manual tester, I used to execute them using the same tools our customers will use: a keyboard, a mouse, or fingers on a touchscreen.

A developer's main focus is building the thing. A QA Resource's job is understanding all the myriad ways that thing can be used by the customer, and writing exact steps to test it in kind.

It takes -time- for automation to add their full value, and must be written, reviewed, and tested. Manual testers embedded in the team as the product is still in flux aren't just a stopgap measure. The work they do becomes the next automated test.

- T.J. Maher
Sr. QA Engineer,
Fitbit-Boston

// QA Engineer since Aug. 1996
// Automation developer for [ 1 ] year and still counting!