Why test automation is a lot like bubble wrap

So, a couple of weeks ago I had the pleasure of delivering a keynote at the 2019 UKStar conference in London, where I talked about how asking better questions (one tip: ask why first, ask how later) can help teams and organizations prevent ‘automation for automation’s sake’ and increase their chances of test automation actually becoming a valuable asset in the overall software development and testing life cycle.

In this talk, I used an analogy comparing test automation to bubble wrap, in an attempt to help people see test automation in a slightly different light than the ‘be all end all’ solution to all testing problems that it’s still perceived as too often. This analogy sparked a couple of mentions and questions for clarification on Twitter afterwards, so I thought it would be a good idea to repeat and expand on it in this blog post.

Street wrapped in bubble wrap

So, why do I think that test automation is similar to bubble wrap?

It has little value on its own
You might not tell this from the incredible amounts of time and money that organizations spend on test automation, but in itself, automated test scripts have very little value. Just like buying a roll of bubble wrap doesn’t set you back a whole lot of money (I’ve found a roll 1 meter wide and 100 meters long for under 40 euros), nobody’s going to wake up in the morning with the plan of spending a lot of money to buy automated tests. But why are organizations still investing so much in it then? That’s because…

It’s used to ship another product of much higher value safely to its destination
The value of both bubble wrap and test automation is instead in what they provide (when applied well, of course): safety. Just like inexpensive bubble wrap can be used to ship expensive products (china vases, for example) safely to the other side of the world, the main purpose of test automation is to enable teams to ship a software product that does provide value to its destination (or at least bring it a step closer): production.

There’s often too much of it in the package
I don’t know about you, but I order a lot of my shopping online, and all too often, the delivery person presents me with a large box that’s filled more than half with bubble wrap (or those fancy air-filled bags). Similarly, software development teams still too often spend a huge amount of time on writing lots of test automation. Why? Because all those green check marks give them a feeling of safety. Everybody feels good when you tell them that you’ve added 25 automated tests to the suite. Far fewer people, however, make a habit of checking if those tests actually serve a purpose…

It doesn’t protect your product against everything that could go wrong with it
Bubble wrap might protect your product from breaking when it falls. However, it doesn’t protect you against theft, or your package getting lost in the mail. Similarly, test automation doesn’t protect your software against all types of risks. It might protect you against some risks.

I cannot make this point without referring you to the example that Alex Schladebeck gave in a recent TestTalks podcast episode:

Outtake from the interview with Alex Schladebeck on TestTalks

I’m referring to the same principle here, although Alex put it much more eloquently than I do.

Oh, and finally…

It’s a lot of fun to play with!
No further comment necessary 🙂

On my 2018 and my 2019

Wow, another year has flown by! And what an amazing year it has been. Now that the end of the year is coming ever closer, I’d like to look back a little on this last year and look forward to what 2019 might have in store for me.

The freelance life
2018 was my first full year freelancing under the On Test Automation label. As I’ve said in previous posts, it fits me like a glove. What I’ve been especially grateful for this year is that being a freelancer has given me the freedom to choose whatever I want to spend my time on, without having to get permission from anybody else. It has also allowed me to be there for my family whenever it’s been needed, without having to deal with sick days or annual leave budgets.

Needless to say that I’ll continue to work as a freelancer in 2019!

Client work
I’ve done consultancy on a per-hour billing basis for four different clients this year. Sometimes as part of a software development team, sometimes in an advisory role. I’ve noticed that the latter suits me far better, so that’s what I’ll try and keep doing in 2019. These roles are a little harder to get by, and they’re often not even publicly advertised, so I’ll have to make sure that people know where to find me in case they’re looking.

I’m happy to say that I’ll be starting a new project that sounds like a perfect early January with a brand new client, where I’ll advise and support several development teams with regards to their test automation efforts for 2 days per week. I’m really looking forward to that.

Training
2018 has been the year where I finally started to increase my efforts to land more training gigs. Delivering training is what I like to do best, and I hope that 2019 I will be able to reap what I have been sowing this year. In 2018, I delivered 17 training sessions (ranging from 2 hours to a full day) with 8 different clients. I am most proud of the two times I’ve been asked to deliver training abroad, allowing me to do one day of training in the UK (Manchester) and one day in Romania (Cluj).

For 2019, I hope to at least double the amount of training sessions delivered, where my ultimate goal is to be at an average of delivering 2 days of training per week (with the rest spent on consulting work, writing, and other things). To get to that amount, I’ve started collaborating with a few training providers this year, and I hope that this pays off in 2019. I am also launching a brand new training course on January 7, one that I’ve got high hopes for, so hopefully I’ll be delivering that one a couple of times too, besides my existing training offerings.

Speaking gigs
This year has been a relatively quiet year on the speaking front. That’s fine with me, because even though I am starting to like speaking more and more, I like doing training and workshops even better, so that’s where my focus has been. Still, I have done five talks this year. Three of them in the Netherlands: at the TestNet spring conference, at a company meetup and the one I am most proud of: my very first keynote talk at the Dutch Testing Day. I’ve also delivered two talks abroad: one at the atamVIE meetup in Vienna, Austria, and one at the Romanian Testing Conference.

I would like to do another couple of talks next year, because I’m slowly learning to become a better speaker and I would love to expand on that. I have one talk scheduled so far, none other than my very first international keynote at the UKStar conference in London, UK in March. I am really, really looking forward to that one!

Conferences
Speaking of conferences, it has been a relatively quiet year on that front as well. I think I’ve attended five conferences this year, four in the Netherlands (TestNet 2x, TestBash NL and the Test Automation Day) and one abroad (the Romanian Testing Conference). In all of these conferences, I’ve been a contributor, either with a talk or with a workshop (or in case of RTC, both).

Next year, I would love to attend more conferences, and not necessarily as a contributor each and every time. Also, I’d like to expand my horizon and attend one or two conferences outside of the testing community. Two conferences are in my agenda already, UKStar and TestBash Netherlands, where I’ll be delivering a brand new workshop.

Writing
I’ve been relatively inactive on the writing front this year, too. I’ve published 7 articles (5 in English, 2 in Dutch) on several websites, as well as 10 blog posts on this site, including this one. Next year, I’m planning to pick up the pen more often again, both for other web sites as well as for my own blog. It will be a matter of consciously making more time for it, as that has been lacking a bit this year.

Webinars
Finally, I’ve also done four webinars this year, and I’m planning on doing a couple more of them next year. The organisers that had to suffer from my ramblings this year were Beaufort Fairmont, Parasoft, TestCraft and CrossBrowserTesting.

So, all in all, it has been a very diverse year! Which is a good thing, but also a trap I’ve been falling in. My attention has been divided over so many different things that those that I think are really important to me (training, writing) have suffered a little. That’s a lesson I’ll definitely take with me into next year.

But first, it’s time to relax a little. We’ll see eachother again in 2019. I hope that it’s going to be an amazing year for all of you.

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.