Should test automation be left to developers?

I am not a developer. I have a background in Computer Science, I know a thing or two about writing code, but I am definitely not a developer. This is similar to me knowing how to prepare food, but not being a cook. People that have met me in person probably remember and will possible be bored to death by me using this analogy (sorry!).

On the other hand, I also try to repeat as often as possible that test automation is software development, and that it should be treated as such. So, you might ask, how come I am working in test automation, yet I don’t call myself a developer? And more importantly, shouldn’t test automation be left to developers, if it really IS software development? Recent blog posts I’ve read and presentations I’ve heard have made me think a lot about this.

So, to start with the second and most important question: should test automation be left to developers? My answer would be yes.

And no.

Test automation should be left to developers, because
writing automated tests involves writing code. Personally, I don’t believe in codeless solutions that advertise that ‘anybody’ can create automated tests. So, since code writing is involved, and since nobody knows writing code better than a developer, I think that writing automated tests can best be done by a developer.

I’m going to use myself as an example here. Since writing code isn’t in my DNA, I find it takes me three times as long – at the minimum – to write automated tests compared to your average developer. And with high-pressure projects, short release cycles and the trend of having less and less testers for every developer in development teams, I just couldn’t keep up.

To make matters worse, new automation tools are being released what seems like every day. Especially within the Java and JavaScript worlds, although it might be just as good (or bad?) in other ecosystems, just less visible to me personally. I don’t know. For a while, as a non-developer, I’ve tried to keep up with all of these tools, but I just couldn’t manage. So, instead of frantically trying to keep up, I’ve made a career shift. This came naturally after I realized that

Test automation should not be left to developers, because
nobody knows testing better than testers. As I said, I (and possibly many people involved in test automation along with me) am not skilled enough to compete with the best on how to create automated tests. However, I think I (and a lot of others) can teach a lot of people a thing or two about the equally, if not more important questions of why you should (not) do test automation, and what tests should and should not be automated.

A lot of developers I have met don’t have a testing mindset (yet!) and tend to think solely along the happy path. ‘Let’s see if this works…’, rather than ‘let’s see what happens if I do this…’, so to say. When writing automated tests, just as with creating specs for the software that needs to be built, it requires a tester’s mindset to think beyond the obvious happy flow. This is why I think it isn’t wise to see test automation as a task purely for developers.

It also helps if people other than developers feel some sort of responsibility for creating automated tests. Given that most developers are busy people, they need to choose between writing tests and writing production code on a regular basis. Almost always, that decision will be made in favor of production code. This does make sense from a deadline perspective, but not always as much when you look at it from a quality and process point of view. Having people in other roles (testing, for example) stressing the need for a mature and stable automated testing suite will definitely improve the likelyhood of such a suite actually being created and maintained. Which might just benefit the people continuously fretting about those deadlines in the long end..

So, to answer the first question I posed at the beginning of this post: Why am I still working in test automation despite not being a developer? Because nowadays I mainly focus on helping people answer the why and the what of test automation. I do some stuff related to the how question as well, especially for smaller clients that are at the beginning of their test automation journey or that don’t have a lot of experienced developers in house, but not as much as before. I love to tinker with tools every now and then, if only just to keep up and remain relevant and hireable. I’m not as much involved in the day to day work of writing automated tests anymore, though. Which is fine with me, because it plays to my strengths. And I think that’ll benefit everybody, in the long end.

I think the test automation community could use a lot more highly skilled people that are (not) developers.

14 thoughts on “Should test automation be left to developers?

  1. Absolutely fascinating article Bas! Thank you!

    My answer is NO – as a developer i spend so much effort to get the code to match the required business solution, mostly due to time pressures, i can only test the ‘happy’ path. And with only one brain, can only ‘see’ one set of failure points. So i rely on my backup team of test ppl to help produce a solid product.

    Sure testing involves writing test code, but we are ALL writing something anyway: specs, plans, test strategies n more. Many testing frameworks take the grunt out of it letting you get optimum results. I like & need test teams!
    With continuous dev.& integration tools, even more so!

    Have a Happy Xmas ;-D

  2. Bas,
    Good article, I admit I didn’t read all of it but enough to know where you’re going with it. I consider myself an “Automation Developer”. Meaning I’m the oddball hybrid Tester who also knows how to write code and construct the “Testware” (frameworks and other code type artifacts that comprise it). I started off as a C programmer and got into test by accident.

    But back on topic. Yes it should be people with “development” and “software construction/design” knowledge who build out automation. And no because they also need to have the tester’s mindset. If you go too far to either extreme you will not get a solid overall solution.

    Just as automation needs to a balanced piece of the overall testing process so does the automation code’s development and maintenance. Balance is everything.

    • Thanks again Jim for sharing your thoughts! It’s true, the best option is to have the best of both worlds. Either in a single person (such as yourself), though those are very hard to come by, or through a healthy mix of skills in a team.

  3. Hi, Bas.

    Thanks for the article. I agree with your points.
    Ideally the biggest benefit from test automation (in terms of speed and quality) can be achived by mixing ‘developement – focused’ engineers with ‘testing – focused engineers’.

    The most technical and complex parts of test automation solution may require a deep knowledge of programming. And the biggest challenge is to build not only suitable solution and simple enough and usable for QA engineers.
    Test automations or even a regular QA engineers should be responsible for adding / updating tests for the solution, report analysis and so on.

    From my experience I can say that in lot of cases if developer write an automation (UI or intergation) without involving testing people – solutions are quickly become completely unusable and not flexible.

    Happy holidays to you.

  4. This question is probably frequently raised in organizations switching to agile QA. I usually found myself answering it with Yes and No, in the same way as you describe.
    I guess it depends on how we define ‘developer’. Is it and oldschool traditional programmer leaving QA to someone else, or is it a developer in a truly agile team?
    I think we could benefit from viewing QA and test automation as basic developer competences, just like CM, databases etc.
    Can we really afford to have testers with no programming skills or programmers with no automation skills in an organization?

    • All good points, Ulf. Thanks for sharing your views. I believe that in today’s teams, programming skills to some extent are a necessity for someone in a tester role. Maybe they’ll never write a line of (production or test) code, but having the skills to read what a developer has done, to analyze it and to possibly point out improvements is essential.

  5. Pingback: Weekly Links #43 | Useful Links For Developers

  6. Hi Bas!
    Great post with good points! I’ll visit more often! 🙂

    My question is – aren’t we all software developers? Programming, testing, analyzing – if the end result is software, than what we do is develop it together.

    So you are a developer – it is not just something reserved for programmers, while everybody else play supportive role 😉 Your contribution help your team deliver software and we all know there so much more that needs to happen for us to deliver software, other than just programming (or testing, etc)

    Happy holidays!

    • Hi Kostadin,

      You’re making a very good point! One that Maaret made in her blog as well (referencing my blog): http://visible-quality.blogspot.nl/2016/12/the-binary-of-coding-in-testing.html

      It has made me think that maybe I shouldn’t bother too much with these labels anymore. There’s a blog post in the works on this topic, probably will be my first blog post in January (4th).

      The reason I use these role labels and the comparison with cooks (chefs would have been a better description probably) is that they represent definitions of roles that in turn help me define what it is I do and how to position myself. As a freelancer, I need to be able to do that in a structured manner so that I can say ‘yes’ and ‘no’ to the right projects..

      Again, thanks for commenting and for your insights. Happy holidays to you and yours too! And thanks for visiting my blog. Hope to see you here more often 🙂

  7. Pingback: Testing Bits – 12/18/16 – 12/24/16 | Testing Curator Blog

  8. Pingback: Java Testing Weekly 52 / 2016

  9. Pingback: Reading Recommendations # 79 | Adventures in QA

Leave a Reply

Your email address will not be published. Required fields are marked *