The future for manual testing

Feb 9, 2015 · 464 words · 3 min read

Is being a manual tester a dead-end career as @jsonmez says in his video response for Simple Programmer?

I’m a developer and I’ll admit that I’ve looked down on testers in the past. It’s not something I’m proud of. I was wrong.

The argument that you need to be a developer to progress with a career in technology is harming our industry. Videos and comments like the ones from John are not helping to get rid of the stigma associated with testing.

There has been a drive to remove all testers from modern development teams. After all, we now have some great test automation frameworks, and developers who can write code. So why would we need to run manual testing? I have to admit, I’ve been part of this school of thinking in the past.

My previous company laid off all our testers apart from those that could write code. These testers became automation testers. At first this made sense, yet it became clear that this wasn’t the right thing to do. Removing the manual testing harmed the quality. Our automated tests were covering the things we knew, meaning that we were confident on these features. It came at the cost of not exploring the product. We missed a lot of the “what if” testing.

Exploration is a key part to testing a product. So much so, that James Bach and Michael Bolton have gone a long way to make the distinction between testing and checking. We should classify the automated testing I mention above as automated checking. When we do, it becomes clear that we’re missing a large part of the picture.

I think, and I hope, that checking is what John is talking about. One can argue that the manual execution of checks, release after release assigning a Pass/Fail could is a dying role. It’s probable that you’ll be able to replace a lot of manual checks with automated checks.

Testing is so much more than that. My current team writes unit and acceptance tests, which are in fact checks on the functionality we’re building. They’re pretty much all automated and they’re written by our developers. This frees our testers up to do what they do best. The testers can go deep into the product, run experiments and make new discoveries about the things we’re building. I find that allowing testers to do this adds more value to the team.

In some of the comments on his Simple Programmer post, John refers to the view in the corporate world between developers and testers. He also comments that developers tend to earn more, as testers reach a glass ceiling. Unfortunately, this will be the case if the organisation shares John’s view that all testing results in a Pass or Fail from a check.