Tuesday, October 9, 2012

The Overloaded Tester

As most of you know, I came up through software testing, before branching out into development and management. I still like to keep in touch with my roots, and spend a lot of time working with my clients on the test function in software.

I've noticed a trend recently toward overloading the tester. It's no longer fashionable to simply have testers. That's "old school" "retro" thinking that produces script monkeys and poor manual testers. The bright shiny way now is to have test automation gurus - basically developers who specialize in developing tests and test frameworks - and a customer or customer proxy who helps define what to test.

All in all, I don't have a problem with the thinking behind the trend. Yes, script monkeys give testing a bad name. Yes, test automation can be a hugely valuable tool. Yes, listening to the customer is great. Like many trends, it went too far, but it's starting to swing back. And that's where things are getting interesting.

You see, we have all these manual testers, and some of them are very good. Some of them know the business and the uses like the backs of their hands, and we're starting to recognize how valuable that knowledge is. Others know the attributes of testable, maintainable, scalable software and can be great testing in the code review or architecture era. What we used to call a manual tester can now be a great future proofer.

We're really starting to overload the tester. Now instead of hiring a senior manual tester, we see job reqs for a senior tester that include phrases like:

  • "owns the quality process"
  • "evangelist for good software development and delivery practices"
  • "works across the organization to instill a culture of quality"
Your most senior testers are becoming - at least in some places - process gurus and influencers more than testers. They may never actually test a piece of software.

This actually isn't inherently a good or a bad thing. Some companies have experimented with similar ideas on the development side for years, often under the title "Office of the CTO". It's a kind of roving expert consultant who works exclusively within one company but works across the organization. Seeing this start to come up in testing.... well, it's a career path for testers who don't want to get into managing people.

I think overall I'm for this trend of testers taking on a broader role in the organization. Just be careful you know what you're getting into!

1 comment:

  1. Hi Catherine,

    Interesting post! In a previous job/life, I knew a couple of people that were Quality Assurance analysts, without the testing part (similar to your "overloaded tester"). They were dedicated to helping teams measure and improve their processes (and as a result, quality). They were purely non-technical, but were still able to help the technical / support teams review and improve their processes... to an extent. It was no doubt well-intentioned, but ended up being a never-ending hamster wheel of process review, metrics and annoyance to everyone trying to do their work. I guess that's one of the risks - a balance needs to be struck or these people end up buzzing around like flies and posing a nuisance to all and sundry (even though they have good intentions).

    That said, it's not for everyone (and a resource probably only larger companies could really afford). I enjoy the technical investigation and evaluation of software, asking questions, pondering the product etc. Delving into process to they degree that's needed for this "evolved QA" role (if I can label it that?) would leave me cold. But it's certainly an interesting fork in the road a tester can pursue these days.