Why I don’t want to be an automation engineer

Now, it may seem strange to have my second post talking about what I don’t want to be, however it is a combination of me affirming what it is about what I enjoy about my job as I see it currently, and how it feels to me the industry is moving.

Automation engineers, programmed checkers, toolsmith, or any other term that you may wish to use, is someone who writes code/tests/scripts for a program to run, which for where I am is Selenium using Java. The purpose to be able to run monotonous tasks that need doing multiple times, freeing up time to allow other work to be done. It is onlyΒ a brief summary, but there may be people who have no idea what I do or what I am talking about, and I don’t want to get them lost in terminology and acronyms that mean nothing to them!Β I also know some differentiate between tests and checks, as well as how automation can be replaced by programmed, or that automation has become this giant buzz word without a full understanding of what this means.

I have nothing against automation itself. When I’ve been asked to check a web page that has had a change to make sure it hasn’t been broken by something else being fixed, having a tool to run that check for me is great. But creating and maintaining all these scripts just sounds dull to me. If I wanted to do this, I would have gone more towards the role of being a developer over a tester, but I know it’s not for me.

The biggest part of testing that I enjoy is being an explorer. I want to be given a site, a piece of code, a problem of some kind, and then figure out what it should and shouldn’t do. I want to be the one who works out what should be automated, and then hand it over to the automation engineer so they can do what they need to. A friend of mine that I affectionately call Hodor is the opposite to me. He can’t stand the exploration, and would automate as much as he can. Sadly we don’t work together, or we would make an ideal duo. That doesn’t make either of us more or less of a tester to the other, and in fact proves that we can still test and add value, but in different ways.

The reason I wanted to write this is it feels to me, that if you don’t want to be an automation engineer, you are getting pushed aside in the world of testing. Even where I work, to be a Senior Test Analyst, if you can’t write an automated script and execute it, or perform performance/load testing, then you won’t ever get to be in that role. I feel like by wanting to be happy in what work I do, and knowing what I want to do, I’m closing more doors to myself than if I went down the route the industry feels like it’s forcing me.

Am I seeing a future that won’t actually happen, or do I need to accept the future and force myself to like it?



19 thoughts on “Why I don’t want to be an automation engineer

  1. Hi
    I absolutely agree that one feels pushed away if one is not an enthusisstic automation engineer in testing. While I agree to your reasoning I see another reason: in the fascinating world of business process testing, there also is not much room for automation. Neither is for some topics of mobile testing. Still, I believe that both is relevant, automation and manual testing. I have been working in projects with manual testing only and this also is not too great, as one tends to oversee spupid little regressions when things get boring.
    Have fun testing!

    Liked by 1 person

    1. Thanks for the comment Testhexe πŸ™‚

      As I mentioned, I have nothing against automation and accept it adds a benefit, I just don’t think I would be a good fit for it.

      It is easy to focus on the small things with manual regression, but ideally by the time it is only regression testing being performed, all the serious bugs should have been found before.

      All the best with your testing!


  2. This is perfect, and I’m glad you wrote this because many testers feel pressured to learn automation when it’s not a good match for them, Manual testing isn’t going extinct, but it -is- being shaped, in part, by automation. Analytical skills, exploratory testing and strategies on how to prevent bugs, will be what the future manual tester will be doing, which from what I’ve read, you might find to be fun. I encourage you to keep walking your path and playing to your strengths.

    Fritz @ testzius.wordpress.com

    Liked by 1 person

    1. Thanks for the comment Fritz. It was nice to see comments when I woke up this morning πŸ™‚

      I’m hoping what you describe is where I can go, as exploration and finding bugs are what I enjoy doing, and give me job satisfaction, which helps anyone get up and go to work each day.

      I hope to continue walking this path, preaching the benefits and joys of manual testing, and whilst I don’t want people to feel like they shouldn’t learn automation if they don’t want to, I don’t want them to feel like they have to when they don’t want to.


  3. I must confess, the main reason I became an automation developer is because I like employment.

    I’ve suffered through two layoffs recently: one because after twenty years of software testing experience I didn’t have work experience coding, and another because I only had two years of experience coding. Many of my software testing friends have seen entire QA departments being axed.

    At first, it was really, really scary being out of my comfort zone. Now? After two years? I am really having fun doing automation! πŸ™‚ You get to automate those really boring regression tests. Automating browser tests, it is a very visual medium, something that didn’t exist when I was earning my BSCS in the 1990s.

    Plus, the software industry needs us software testers to turn automation engineers. It needs people who know how to craft a mental model of the customer who is using the product, and take it through the entire software development life cycle.

    Good luck in your career, wherever it may take you!

    Liked by 1 person

  4. I’m sorry to hear that the lack of automation experience has caused you to be laid off in the past T.J 😦

    Hearing that is what makes me wonder if I will have to learn automation, simply to continue working as a tester, and if it is better to be doing testing in some form, than not at all?

    It is good that you are now settled into it and enjoying it, which if I end up in the same situation, I hope I end up doing, looking back at where I am now and realising that it was a fear of change stopping me.

    Good luck with all of your automation, and preach to those who are interested in it, why they should learn automation!


    1. Think of coding as simply another tool in your testing toolkit, along with, “How can I examine these requirements and make sure they are testable?” and “How do I lead a test case review with the stakeholders to make sure that this is a robust test?”.

      Yes, it will be hard at first. After six months of practice, it will be easier.

      If you want to see some articles I have written about my experience going from manual testing to automation, you can take a look at https://techbeacon.com/contributors/thomas-maher

      -T.J. Maher

      Liked by 1 person

  5. I agree with T.J. about coding/automation and performance being more tools in your tool case, and you can still continue testing manually and finally automate what you have checked.

    I too share your infusiation for exploratory testing, and I feel it is the most comfortable approach for testing for me, as, by this way I always find “on the way” many paths the test can spread, paths you don’t think of before hand,and it allows me to ‘feel’ the system and get a sense on how well it is functioning.
    but I am obstacled by different approaches which say all tests should be designed accurately at the beginning and no time for exploratory..although it may seem more professional this way, it takes away much of my personal way for testing..

    Liked by 1 person

    1. Coming back to reply to comments almost a month old feels excessive, but when you have taken the time to comment on my post Eli, it would be rude of me to never say anything back. Better late than never!

      I unfortunately know your pain of having to create all your tests at the start and get no time exploring (which should be done at the start to find more tests, not at the end when it’s too late to add more tests). But if we keep our heads down and keep letting it happen, our managers and peers won’t ever know that there is another way we could be testing, and they can be alongside one another, as exploration and scripted testing can work together instead of being a conflict.


  6. I completely agree with you. I feel an exploratory tester has much more responsibility for testing.
    Being an exploratory tester, I can find bugs under the hood, back in the trunk, in the backyard, which can’t be found by automated scripts πŸ˜‰ πŸ˜‰

    Liked by 1 person

    1. Again, sorry for being so late in replying Atinderpal, but better late than never!

      It’s wonderful to hear another voice for exploratory testing. Around me it feels like not enough appreciate the value it can add, and how it can (and will) find things that classic scripted methods (of which automation has to be) may not have found.

      Best of luck with all your exploring!


  7. I am so happy I read this article this morning. And to begin with I am not against manual testing (although I believe there is no such term). A quick look at my LinkedIn profile will tell you, 5 years ago, I was a simple hands-on test engineer who was handed a piece of software to write test cases, figure out workflows and then test it to the comfort level of dev team so that no bug shows up on production. At least not on the day of launch. Fast forwarding to today. I am a test engineer who is hands on with writing scripts to take care of those monotonous clicks and checks that anybody could have done if hired in my place. So now my task has evolved over years to figure out faster ways to test those flows, figure out nasty scenarios that tend to break my AUT on test and prod and get those fixed really really quickly.

    Now to the point where the author has mentioned that they want to be meaningful in their own way. I would just mention, it’s a two-way game. Not all companies would pay you to come to work, and do what you want. So sometimes it’s better to up-level your skills and that does not necessarily means you need to learn to code like a pro. In-fact none of the automation folks I know consider themselves masters of Java/Ruby/Python/

    Its just about finding the right mix and challenging yourself to do something new each day. Again, nothing goes against a seasoned manual test engineer. But if you are saying your company/industry is kicking you aside, take a look around. Its happening with everyone. Remember those developers from cobol/pascal days? Do you see them anymore. No? right. But don’t you think they up leveled their skills and learned Python/Pearl/ and still in the game.

    So play the game that’s current and keep yourself relevant.

    Liked by 1 person

    1. And another apology for the delay in replying, sorry Jasmeet!

      I’m glad my post made you happy. It may not please everyone, but so long as it gets people to think about it, I feel like I’ve achieved something.

      By automating all those monotonous clicks, do you feel that when you are performing manual tests to find those critical prod impacting bugs it is more satisfying? That when you are getting your hands dirty, it is for something worthwhile, not some regression that is a means to get to where you need?

      I appreciate they don’t pay me to do what I want, but I do hope if we don’t see eye to eye on what I want to do, I can find the right company who does.

      As for COBOL developers, amazingly we still have them as we have COBOL code in the foundations of our infrastructure, which is very scary! We keep having a project to replace it with SQL, and it keeps getting closed as the size and cost of the project means they would rather spend it on something else.


  8. Clearly a topic that has generated interest. I suggest you all explore the idea more and share more ideas around the topic. If you want non-automated testing to become more relevant, then it is up to us all to write and share more ideas around it.

    Of course automation is important, but so are many other things in testing. It would be nice to see more balance πŸ™‚

    Liked by 1 person

    1. Thanks for the support Rosie.

      I’ll keep shouting from the rooftops as much as I can, and even try and get in the 99 second talks at TestBash Brighton to explain my thoughts, and see if it gets others to talk or grab me after for a chat.

      Liked by 1 person

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s