Is There a Bias against Manual Testers?
With just how much testing has changed over the last decade—from automation, to artificial intelligence, to the medley of open-source tools on the market—plenty of teams find themselves unsure of the exact role that manual testers play.
We keep hearing that testers need to learn how to code, automate, and adopt as many skills as possible in order to stay relevant, but what about the highly-skilled manual testers who are still needed in today’s fast-paced environment—the manual testers who still provide value and do a job that automation just can’t correctly cover?
More and more, it feels like management (and even other members of the team) are looking for ways to eliminate manual testing. But Jennifer Scandariato, the director of test engineering and leader of the Women in Technology initiative at iCIMS, recently explained why manual testing is still integral to high-quality software delivery.
“There is a bias that manual testing is something that provides less value. I believe a strong engineer knows that there’s a level of critical thinking that is required to ‘break’ things and ensure they are built robustly,” she said in an interview with StickyMinds. “It’s easier to teach Java than to teach the critical thinking required in a test engineer or SDET.
“On a great team, you have diverse skillsets where everyone complements each other, and you might even alternate roles such as paired programming where one person is developing and the other performs the validation or peer review.”
OK, the mindset that most manual testers have is still needed, and certain parts of the process are better left to humans rather than AI or some sort of tool. But if a team is going agile or focusing on DevOps, should the old-school testers bear the brunt of the responsibility to change?
“Absolutely not. It’s a transformation at every level. At iCIMS, our QA team needed to learn new skills. Our SDET’s (Software Developers in Test) needed to embrace the help and create a buddy-system,” Scandariato. “Our developers needed to accept the help in test automation and be open to receive feedback on more effective ways to code.”
Manual testing might not be as all-important as it once was, but it’s still needed if you have any hope of delivering software at a quality you can be proud of. How we create software is going to continue to change, but the burden of that change needs to be handled by more than one group within the industry.
I wish we would stop using the phrase manual testing. No tester I know uses the old hand, manual static testing methods anymore. Not sure what I mean when I say that? Think things like Flow charts, state transition diagrams, and other model or flow based testing methods. What is going away are structured and more formalized and documentation centric testing. For most of us, automation is in use even if we aren't explicitly aware. Testers make use of tools, like Dev Tools in Chrome, Charles or Fidller, JMeter, and other tools to help generate, analyze and poke at software.
What I wish we would have a real conversation about is, tool centric testing, vs coded testing. I believe many are waking up to the fact that a lot of the confirmatory testing can be handled in code, or with tools, and are trying to automate them, but find that on a system level, you need a bit more judicious use of tools and code in order to cover work paths, and flow.
Let's be careful not to become the industry that hits every tool with code though, I think that's setting us up for blind spots that will set our customers up for unexpected outcomes.
Timothy beat me to it. The term "Manual Tester," IMHO, is often used in a derogatory fashion. If you're not using test automation, then you have no choice must manually test (assuming you test). I would like to see the term and use of Exploratory testing become mainstream. Exploratory Testing - digging deep, testing complex scenarios, testing timing issues, etc.
I am looking forward to the day where the standard test team is comprised of exploratory testers and test automators. I am looking forward to the day when there just as many Exploratory testing job postings as there are for automated testing jobs, but I'm not holding my breath.
Well stated Timothy and John. I would like to add my observations on the advancements of Testing. I believe that there has been a big move toward pushing the Testers to Test Automation. Agile Scrum & CI/CD are contributors to this movement. As we all know, Test Automation has pushed the "Manual Testers" to become coders of Selenium or API's. But, I would like us to remember that this is just one part of Quality Assurance (QA). We are discussing the Quality Control (QC) subset of QA. Quality Assurance is about the End to End Processes. Delivering the Highest Quality products to the Customers based on the initial requitements. The QA Team (if you still have one) should be an advocate for the Business. With this in mind, I'm advocating the advancements of the "Manual Tester" into Test Automation by creating Test Journeys that are Automated via the latest "Capture Playback" type tools. Not to be confused with the older capture playback, the newer tools can create underlined Selenium Code. These also interface with CI/CD Build and Agile Scrum Tools. These "Test Automation" Tools don't require any Coding. Therefore, the QA Analyst can create their Test Journey (End to End Manual Test, if you will) and also create the Automated Test Case at the same time. How's that for Cost Savings? I don't represent any of these "Codeless Test Automation" products so I'm not going to mention any of the, just Google it. Cheers