Is There A Future For Manual Testers?

Lisbon, Portugal | Photography by Raphael Awoseyin

I think it's fair to say that in the QA world today, if you know nothing about test automation, you should be worried. QA isn’t what it used to be 15, 20, years ago. Testing is getting more technical, and the very trade now demands a completely different set of skills. Remember when we had a QA organisation that was simply split between those who wrote test cases and those who executed them? Those days are long gone, and now we talk about those who test manually, and those who automate.

Agile, CI/CD, TDD, and all the modern software development methodologies beg for more automation. The once teams of manual testers are fast being replaced. Many companies today have armies of automation engineers or multifaceted testers, tasked with doing both manual and automated testing. ‘Test once, then automate’, or simply ‘automate’, is becoming the norm. With these changes, some manual testers have begun looking to lead and management roles as an alternative. But there has been an increasing demand for automation knowledge even at this level.

I believe the power of a QA team lies in the diversity of its talents. A team of highly technical QA engineers, though efficient, are likely to miss some bugs a less technical tester would find and vice-versa. Tech-savvy folks have forgotten how to think like the average Joe. We know too much, and this limits our creativity. The average user often doesn’t have a degree in computer science and has no clue how our product actually works behind the scenes. A QA Engineer that can think like the average user can be of enormous value to any team, but are often found in the less technical end of the QA spectrum.

Quality Assistance

While non-technical testers are slowly fading out of QA teams, there’s a new trend rising. Based on statements made by Cem Kaner in his highly acclaimed 2004 white paper,  The Ongoing Revolution in Software Testing, some teams are eliminating the traditional QA role altogether. They call it Quality Assistance.

Quality Assistance--that's what testers do. We help. We investigate. We learn things. We report them clearly. We make sure that people understand what we have found and what its significance means. We provide the good data that is so important for understanding and improving the quality of the product. That's important, but it's not "quality assurance." —Cem Kaner (The Ongoing Revolution in Software Testing, 2004)

The software company, Atlassian has been a pioneer in its adoption, which has inspired other companies to follow suit, albeit with variations in its implementation. The idea is if we have a solid quality process, the testing done by the developers should be enough as long as they're guided by an experienced tester. No one tester can actually ‘assure’ the quality of a product. QA is the entire team’s responsibility.  I think Atlassian say it best in their blog post Quality assistance: how Atlassian does QA.

At Atlassian, we optimised the process by empowering and educating developers to test their own features to production quality standards. We evolved this over time by keeping the ratio of testers:developers low – not because of resource constraints, but to force the “whole team” mentality when it comes to quality. As developers learn to build quality into their features from the start, rework is reduced, and the team can achieve both quick and safe delivery. A QA engineer becomes the facilitator for this, instead of the individual performing the tests. We call this model “quality assistance”...

In this case, all the feature testing is done by the developers, and the testers have more of a coaching role. Amaysim is an Australian telecommunications company that has also adopted the Quality Assistance model citing the same reasons and also involving QAs in end-to-end and exploratory testing so they don’t get rusty. If we look at these two adaptations, one thing they both have in common, the QA doesn’t need to be technical. In a subsequent article, Atlassian outlines what they see as qualities of a good Quality Assistance Engineer, among them citing influence, testing expertise, teaching skills, inspiration, facilitation, and problem identification. You’ll notice, there’s no mention of test automation or technical skills. This is a role ripe for a seasoned ‘manual’ tester! In fact, this would be their strong point, providing scenarios from a non-technical user’s perspective.

But of course, hearing this solution I know what you’re probably thinking:  So, we want the developers to do the development AND the testing, while the QA just watches and criticises? That doesn’t seem right. And isn’t this just the beginning of the end of QA? Soon, we will say we no longer need coaching because we’ve gotten the hang of how we can dream up effective test scenarios, and exploratory testing can be done by anyone. How much are we willing to pay this non-testing ‘coach’? These are all valid points to be addressed. But this solution doesn’t seek to eliminate the role, but to use the best of both worlds. Developers understand how the product works both inside and out, and usually don’t have the technical limitations a tester might have. Besides, they are already doing unit testing anyway. The issue is that being so close to the code, developers would tend to ignore key test scenarios. This is where the ‘QA Coach’ comes in. They provide the testing brain full of wacky scenarios to be executed. And to make sure the QA doesn’t get rusty, they are pulled in for more end-to-end and client-heavy user acceptance testing.

Conclusion

I recently spoke with an R&D company here in Paris. They had never heard of the quality assistance model, but were proud to tell me that their testers do not actually do any testing. Their product is highly technical, developer-driven, and they just need testers to facilitate the testing done by the developers. Getting testers technical enough to do what is known as glass box testing proved to be challenging and counter-productive. To encourage quality assurance across teams, that’s quality assistance! To imagine there are companies already organically adopting this model, indicates an evolutionary trend in the industry that must not be ignored. However, with the ‘shift left’ movement in regards QA within the development pipeline, if we continue to favour automation over manual testing, could we be moving towards a future where automation engineers are pushed more and more into a development role? Eventually causing the extinction of the QA role as we know it? While non-technical, aka manual testers, become the new breed of QAs; Quality Assistants.