On where I think the test automation industry is going

One of the funny things about running a blog for a while is that people start to see you as an expert. Whether or not this is a reasonable observation in my case, I’ll leave to answer for the rest of you. Still, they’ll turn to you with questions regarding their career, advice on that, and if I know where the industry is going. I won’t disclose my answers to the former here, since there’s no such thing as general career advice and I don’t feel comfortable sharing questions and answers asked by individuals on a public blog.

In this post, I’ll share a couple of things that tend to make up my replies to the question of ‘where is the industry going?’. You’ll see that hidden in there is some career advice anyway..

The need for good automation will keep growing
This is the answer to a question I get sometimes, and one I’ve been asking myself quite often as well. Is test automation a good field to be in for the foreseeable future? I tend to think that it is. Sure, the field will change due to new technologies, market trends and research breakthroughs, but in general, test automation will remain an important (though I don’t want to overstate the importance of it either) activity in software development. That is, good automation. Hopefully the industry will start to learn that there is a lot of horrible automation being written and maintained at the moment, and will see that we’ll all be better off if the plug is pulled on those efforts. I’ve seen some things.. I don’t even want to know how much money is wasted in these projects!

People that want to be good automation engineers will see that they need software development skills
As a logical follow-up to the previous point, I foresee that the industry will start to recognize that in order to write good automation, one needs actual software development skills. I expect (or at least sincerely hope) that the end of creating automation that is hard to use, explain and maintain is nigh. I myself will do my very best to create this awareness, even if that means standing on some people’s toes. It’s about time test automation is taken seriously, by all parties involved. So, for those that want to move into the automation field, make sure you’ve at least got a grasp of the basic concepts of software design and development. You’ll need it to succeed in the long term.

Automation turns out not to be the silver bullet
Repeat after me: automation is not the silver bullet. Sure, it can make things more effective if applied well. But if you automate horse shit, you’ll get automated horse shit. Just automating something because you can (or because someone asks you to, for those with less backbone or less ability to think critically) does not mean that you should. Again, I see more and more people starting to become aware of this, mostly due to others that have seen the truth earlier and are willing (or feeling obliged) to share. Thanks guys, keep up the great work!

Machine learning and artificial intelligence will not take your job
Sure, ML and AI are emerging trends. And sure, they might have an effect on your job and the way you do it at some point in time. But I refuse to believe that at least in the foreseeable future, ML and AI are going to replace me. Maybe they’ll replace some of my tasks. Writing yet another Page Object and tests that use it (in a valuable way!), for example. And you know what? I’d be happy if they did. It gets boring, after a while. This means that some of my time will be freed up to dedicate to more interesting stuff, such as teaching others, doing research, devising and implementing automation strategies, or becoming the world expert on tiramisù I always wanted to be. I’m looking forward to it.

Despite numerous efforts, the software industry will not be able to get rid of testers
Lastly, and I hope this is the last time I ever need to refer to this fallacy (although I suspect it won’t be), those pesky testers will live to see another day.

7 thoughts on “On where I think the test automation industry is going

  1. Great and informative article as always Bas. Always find myself coming away with plenty of food for thought after reading your blog entries

    Andy Tilston

  2. Bas,
    Great job again. And you are gaining “expertise” which allows you to be an “experienced” professional. That is the key word, professional. So keep going. Now on to the subject at hand, I’ll try to hit on each point and be constructive with my comments.

    First, the need for good automation (whatever that may really be) has always been a major factor in this line of work. Just like with regular code development there are both technological and methodological changes/advances. In the realm of automation the tools have diversified in both numbers and capabilities. This happened before in the mid 1990’s with the commercial tools, now with opensource. The technologies we are working with have widened; web, mobile, IoT, etc. This has caused a shift in testing and testers focus and skill sets. The advancement of implementation of automation to support all of this has increased as well. And because of this you will have good and bad situation occur with the implementation of automation. We as an industry still experience a first time implementation failure rate of around 70-80%. Been that way for years. And there has been a lot of money wasted on it all.

    How to solve that problem is to recognize the root causes, which is many, but the primary one I tend to focus on is the front-end work. This is the analysis, design, and overall process work that needs to be done first before you write a line of automation code. Everyone just grabs a tool and dives in. They don’t ask the Who, What, When, Where, Why and How questions first. They fail to plan and plan to fail if you know what I mean. This is all related to education of testers, and other people/groups, regarding test automation and what it takes to get it done. You are helping with that now, keep it up.

    Second, there has always been a need and push for testers, and specifically test automation developers (like myself), to have solid development/programming skills. Without them we are creating spaghetti code (like you mentioned before) and painting ourselves into a corner with the success of the implementation in question. Again the question here is education. How do we educate people on this subject, both programming and test automation. What items of information do we need to know aside from how to write a For loop or a method/function or what ever else construct. We need to teach people about the technology they are interacting with / automating against. This could be the UI elements, API/Service call, database query, file handling on the system, or an O/S system call itself. There are so many things we can interact with via automation, just like a regular program, that have to be considered and handled. Gaining those skills takes time and effort.

    Again, to solve that problem means recognizing the root causes and then setting up the education regarding them.

    Third, automation is definitely not a Silver Bullet. You know my favorite saying. And beating a dead horse here again is the point about education regarding test automation work. This is not only for the people trying to do it, but the “other” people (Management, C-Level, Development, Marketing/Sales, IT) as well. We as automation professionals need to make the effort to communicate with and educate not only our own kind but the others as well. We need to work to clear up the myths and misconceptions regarding test automation, and there are many. Thus people like you, me and others in the ranks are doing so by posting blogs, writing articles & whitepapers, and presenting at conferences. The key thing with all of this is that we don’t become fatigued and frustrated because we are fighting an uphill battle at times. With “new blood” like you and some others and “olde dog” like me is getting some fight back to persevere.

    Fourth, AI and Machine Learning will not take our jobs. I agree, but it will cause fundamental shifts in how we do our work and what skills we need to have in order to do the work using these new technologies. Besides, the day AI becomes self-aware is the day I head for the mountains to hide. Hopefully that won’t be anytime soon.

    Finally, you are correct in that the software industry will not be able to get rid of testers. The smart ones will learn and adapt, and evolve into a different type of tester. If not then we are all screwed. After all who watches the watchers if you understand the reference.



  3. Of course, in a way you are preaching to the converted. The people who need to be told these things aren’t even IT professionals; they’re the senior managers, directors and board members who are taking decisions about what products or tools are developed and what resources are made available to the professionals tasked with delivering them.

    The last company I was with was in the facilities management sector. They maintained a software dev team with five permanent and up to six contract devs, plus two testers to support the business. The company’s owners looked at the bottom line and decided to do away with in-house development, and to bring in proprietary software. They then went one stage further and actually bought the company that built the proprietary software. Which meant that almost their entire IT team was made redundant.

    But the company had always had the attitude that the testers should only ever test software that the in-house devs had produced. Proprietary software was deployed straight out of the box, because “the providers will have tested it”, without any test programme to ensure that it would stand up on the company’s servers, or that data flows in and out of the proprietary package worked OK. Third-party tools that would be used internally weren’t subject to any testing before roll-out, so the company paid good money for tools that in some cases didn’t even work. And no-one ever tested the website when new pages were put up.

    I complained about this to my management, and got politely slapped down for my troubles. “You’re employed to test the software we write and nothing else” they said.

    The day after I left, the company went public on their new offices. “Click here for a virtual tour of our new, state-of-the-art facilities!” went the social media announcement. Guess what? The link didn’t work.

    I took great pleasure in posting “You’d think this would have been tested before publication – oh, no, I forgot. You just SACKED all your testers!” Yes, that was a bit naughty of me.

    As IT generally becomes more and more a part of the essential infrastructure of business, these arguments need to be taken beyond the discussion between IT professionals and extended to the business community in general – because outside of the dedicated IT business there are a lot more testers working in industry and commerce in general, and they contribute as much to the discipline of testing as anyone else.

    • Hey Robert,

      thanks for the elaborate response. Yes, a large part of the people reading this will already know most of it. I do have a glimmer of hope, though, that I’ve reached at least one that should know this but doesn’t (yet), as you said, this can be a manager, director, board member, or anybody else.

      Else it might serve as a reminder / refresher 🙂

  4. Pingback: Testing Bits – 10/8/17 – 10/14/17 | Testing Curator Blog

Leave a Reply

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

This site uses Akismet to reduce spam. Learn how your comment data is processed.