The future of the automation engineer

Although I’ve tried to avoid writing about test automation since publishing The A Word four years ago, I suppose I should probably take some time soon to add a few more chapters before the book (like my last one) becomes largely obsolete.

Not too long ago, I posted some predictions. In those predictions, I said:

Testers writing automation will become a rarity. […]testers won’t write that much application automation. Unit and integration tests will be written by the developers on the team (w/ coaching from the test specialist on their team as needed). The test expert on the team who code will more likely write diagnostic tools, frameworks for “ilities” (perf, security / fuzzing, stress, etc.) – as well as other tools / processes / approaches that accelerate the achievement of shippable quality.

A few weeks ago, I spit out a small tweet storm about the same topic. The TL;DR version is that I have a strong opinion that the role of someone who solely writes automation for developer produced code will be gone soon. There’s just no good reason I can see anymore for developers to not write test automation for their own code.

For a longer, and really, really well annotated version of my tweet-barf, please check out Richard Bradshaw’s excellent post here. Richard was one of the people I thought I’d scare with my tweets. He’s been (as far as I know) in the role of a test automator for some time. But he agreed with me. He gets it. He sees it too, and he’s in the trenches doing this stuff, while I’m just a talking head most of the time.

That means something.

I know there are some readers who don’t follow me on twitter and may have missed this – but my tweets – and Richard’s further thoughts on the subject are important, and a “prediction” that I am absolutely confident will come to life.

 

One Comment

  1. Posted August 14, 2017 at 9:09 pm | Permalink

    This is all great food for thought. I have a sinking feeling (as I’m currently a test developer with a heavy focus on test automation) that you’re correct here. Richard’s post also seems to reflect these ideas as well.

    However I will mention that, as William Gibson said, the future is here but it’s just unevenly distributed. Some orgs already have test engineers/developers that can switch into an application developer role as needed. Some orgs still have a test automation team responsible for all test automation and related matters (sound familiar for testers?). It’s a similar situation to testing, where some orgs are completely up to date and some are stuck in decades-old practices. It’ll be interesting to see what the overall trends are.

Leave some words for the weasel

%d bloggers like this: