Why Is Manual QA Still so Prevalent?
Why Is Manual QA Still so Prevalent?
With the importance of catching bugs early, and the ability to automate all testing, why do companies and projects resist the investment in CI and test automation?
Join the DZone community and get the full member experience.Join For Free
This past week I casually heard comments alluding to the imminent death of the QA Analyst or Manual Tester. (To be clear, I am not referring to the QA Automation Engineer, who builds test automation.)
Not only does the function not seem to be going away, recruiters are still out their hunting testers down. Out of curiosity I did my own review of randomly selected job posts from Monster and Indeed for average QA positions, and discovered that there are still a lot of jobs available for manual testers.
With the importance of catching bugs early, and the ability to automate all testing, why do companies and projects resist the investment in CI and test automation? I will explore the reasons why now, and whether the resistance is good or bad.
Let’s face it. There is a whole generation of legacy products, supported by legacy teams. In my recent review of job openings for manual testers, the listings tended to be for companies that have been around for a long time, are large, and have mature product lines. In the DC area, the job openings tended to be tied to government contracts. Surprisingly, the number of jobs in San Francisco that didn’t require automation skills was almost identical. Again, those companies tended to be more mature, with processes in place that work for them.
In order to drive a development team to embrace automation, it requires upper management’s support and direction. I’m not just talking about QA management, but the development organization as a whole. How many times have you heard a QA manager say the team is going to be handling automation, only to see the efforts fail due to lack of buy-in from other organizations?
Why don’t they embrace automation practices? Switching to an automation-first approach costs time and resources. Project timelines will take a major hit as teams shift gears. If QA is expected to automate without product buy-in on reduced capacity, without developer support to assist with technical details, and without DevOps to help with infrastructure, the effort will be daunting, to say the least.
Development Team Buy-in
Even after all responsible management has signed off and provided direction to scrum teams to start embracing automation, there is still an established mindset that needs to be overcome. I’ve often heard “its QA’s job to test.” When QA is coming up to speed on automation practices, they need help from the scrum team to pick up the testing slack.
Why don’t they embrace automation practices? The scrum team is not taking a “team owns QA” approach. They still think QA is there to catch all of their issues. If a team took ownership of QA, they could pick up a lot of manual efforts, including strategy and exploratory testing via team Bug Bashes.
The QA Automation Engineer can help smooth the transition with developers by working closely with them to:
- Establish best practices, such as those for UI element locators
- Telling them what they need, such as mock data
- Doing more upfront work, such as creating the Gherkin code for Behavior Driven Development (BDD) for the stories for the sprint.
QA Analyst Buy-in
QA Analysts come from many different backgrounds. While a lot of QA talent is hired out of college with software related degrees (and they’re hired as QA Automation Engineers), there are still many in the manual world. I personally love to hire from our support teams, as they are product experts and customer-focused.
Why don’t they embrace automation practices? Learning to automate takes effort. Besides the blocks noted above, the analysts themselves have hurdles to overcome:
- Time – If the company is not behind the effort, it is up to the analyst to learn on his or her own time. While there are plenty of free online lessons available, it takes a major time investment.
- Motivation – How many times have you taken courses to help you learn automation but never get to apply the knowledge? Unless someone is looking for another job, there may be no motivation to make the effort if the previously mentioned blocks exist.
- Don’t know where to begin – There is so much out there. The hardest thing is knowing which tool to learn first. For someone who can be easily distracted into rabbit holes, figuring out what to focus on can be overwhelming.
Automate or Become Obsolete
I took my adhoc research to the next level. I pulled a list of local tech companies as identified by this NCAA Bracket and randomly went directly to their career boards on their websites. I couldn’t find ANY companies that were looking for manual testers. In fact, most of my friends who have gone to smaller, startup-type environments have told me they must not only automate, but must handle the DevOps side of things as well.
Yes, you can still find manual testing roles, but mostly on legacy products. If you want to look forward, avoid obsolescence, and embrace automation.
Published at DZone with permission of Joe Nolan . See the original article here.
Opinions expressed by DZone contributors are their own.