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 delivering automation training online

Recently (as in, over the last year and a half or so) I regularly receive questions about providing online training in addition to my in-house, in-person training offerings. Until now, I put those requests on the back burner as I was of the opinion that teaching online (either live or through prerecorded video instructions) would never be a replacement for ‘live’ training.

And then something struck me: why would it have to be an exact replacement? Why not just try it, see how it goes, learn from it and see if it’s a suitable way to conduct training?

So, when I got in touch with a test consultancy firm in the UK that was looking for training for their employees, I decided to give it a try. After some discussion, we agreed that I would deliver the first day of training in house (meaning: in Manchester), while the following modules would be delivered online, saving me a couple of trips back and forth and cutting down on overhead costs for airfare and hotels. And so it was done.

Note: I am aware that having met the students in person before delivering training online to them is a big plus. However, I believe that the lessons and the pros and cons I talk about in this blog post equally apply when you’ve never met the students in real life just as well.

So, what did I learn in the process? Let’s see.

Preparation
I could write a whole separate article about how to properly prepare for a technical training course or workshop. In fact, I’ll be doing just that in the near future, in an article that will be published on another platform.

I won’t go into too many details here, but by far the most important thing to do when you’re about to conduct training online is to make sure that the participants are ready from the start. My preferred way of doing this is by sending detailed preparation instructions (a step-by-step guide, screenshots and all) to them at least a whole week in advance, so the participants have some time to set up their device. Additionally, I make myself available for questions and troubleshooting in case something goes wrong.

I was afraid to do this in the beginning, fearing I’d be overwhelmed with questions, but it turns out that’s not the case. For all the workshops I’ve given in the last few years, I’ve only had a couple (as in: three or four) people asking for help. That doesn’t mean that everybody else is ready to go when the workshop or training starts, but that’s a whole different kettle of fish…

The reason this is extra important when delivering training online is that you cannot just walk over to the participants and look over their shoulder to see what’s going wrong. You can do screen sharing, of course, but that’s not as efficient as taking over the controls for a bit.

So, long story short, overdo it on the preparation instructions. Be very clear in them and make sure they’re unambiguous. Have them tested by somebody else if you’re not sure everything’s clear (heck, do this even if you ARE sure).

Organization
With regards to how the training days should be organized, here are some key lessons I’ve learned from the two days of training I’ve hosted so far:

  • Group size: Where I can take around 12 people for a class that involves programming when they’re in the same room, I am glad I had only 4 participants for my online training. I think I can handle up to 6 people, but no more. Keeping track of how everybody is doing takes more effort when you see them through a webcam only, and there will probably be more questions (also because participants can’t help eachother out), so it’s only fair to limit the number of attendees to make sure everybody gets the attention and the answers they deserve.
  • Type of course: Live online training works well for hands-on automation training, but probably much less so (for obvious reasons) for training courses that involve a lot of group work, discussions and presentations. I wouldn’t even know how to facilitate that online…
  • Location and connection: Make sure the participants (and you yourself as well) are in a room with good lighting and that their webcam is on, because reading facial expressions will tell you a lot about their level of engagement. Also make sure they’re in a location with a good Internet connection. Videoconferencing takes bandwidth, yet you want both video and audio to be of the highest possible quality to make sure the participants can hear and see you well.

Engagement
The hardest part about delivering training online is keeping your audience engaged. Taking training is hard enough on your energy levels when you’re in the same room as the trainer, looking at a webcam and listening to somebody who’s potentially very far away is orders of magnitude harder. Here are some tips that might help you (they worked for me!):

  • Ask the participants how they’re doing often, to the point of being annoying. Don’t lose them, don’t give them a chance to start drifting off. Make sure they are awake and engaged. In the pre-course instructions, point out that they should be well rested, and that taking a training course online is even more demanding than ‘live’ training, for both parties.
  • Consider shortening the training days (for example, teach for 6 hours instead of 8 for a day of training). Chances are high that they won’t take in anything in those last two hours anyway, simply because their energy levels are too low. Additionally, take breaks often. Even just a five minute break for a leg stretch or a bathroom visit can help keep energy levels up. I took breaks every hour, which definitely wasn’t overdoing it.
  • Involve them. Instead of just broadcasting information all day, ask them lots of questions. When you’re doing programming exercises, ask them to share their screen and talk the rest of the audience through their solution and thinking process. Again, this helps keep them engaged. Don’t let them fall asleep!

Pros and cons
As I said earlier, online training isn’t a replacement for in-person training, at least not on a 1-on-1 basis. It’s a whole different ball game. Both have their pros and cons. Some of the benefits of delivering training online for me are:

  • It allows me to work from home. Big plus. I like driving my car, but I hate wasting time commuting. With online training, I can teach from the comfort of my own home.
  • My potential client base is many times larger. I am quite limited in the amount of travel I can do in a year, and the Netherlands is a small country, which means my client base isn’t all that large. With the possibilities of online training, though, I can deliver my courses to the entire world, potentially. Added bonus: meeting and talking to people from other countries and cultures, plus it does wonders for my English.

Sure, there are some downsides as well:

  • Not being able to walk up to people and see how they’re doing. I do this a lot when teaching in-person, but that’s not an option when online. Even with a webcam, people can hide behind their screen easier and pretend all is well. Their loss, of course, but I take pride in keeping everybody engaged.
  • It isn’t suited for every course I offer. I do more and more courses where people work in groups and have discussions, and as I said earlier, that’s not really an option when teaching online.

Having said all of this, I will definitely start offering live online training more often in the future, probably starting after the summer holidays. It’s definitely a valuable addition to the services I can offer. If you’re interested in taking one of my online courses, keep an eye out on this site for future announcements.

Oh, and in case you were wondering: so far I didn’t need any dedicated virtual classroom software to conduct the training. I used the pro version of appear.in, which requires no software to be installed at all on the client side, is a breeze to work with, allows everybody to share their screen effortlessly, has a chat to share links and stuff, basically everything I need.

Defining Continuous Testing for myself

On a couple of recent occasions, I found myself talking about Continuous Testing and how test automation related to this phenomenon (or buzzword, if you prefer that term). However, to this day I didn’t have a decent answer to the question of what Continuous Testing (CT) is and how exactly it relates to test automation. Now that I’m busy preparing another webinar (this time together with the people at Testim, but more on that probably in another post), and we find ourselves again talking about CT, I thought it was due time to start carving out a definition for myself. This blog post is much like me thinking out loud, so bear with me.

To start, CT is definitely not equal to test automation, not even to test automation on steroids (i.e., test automation that is actually fast, stable and repeatable. Instead, I see CT as an integrated part of the Continuous Delivery (CD) life cycle:

Continuous Testing as part of the Continuous Delivery life cycle

You could also say that CT is a means of that teams can adopt to support CD while aiming to deliver quality software.

Let’s take a closer look and dissect the term ‘Continuous Testing’. The first part, ‘Continuous’, to me is a term that means two things in the CD context:

  1. The software that is being created is continuously tested (or, more likely, continually) in a given environment. In other words, any version of the software that enters an environment is immediately subjected to the tests that are associated with that environment. This environment can be a local development environment, a test environment, or even a production environment (where testing is often done in the form of monitoring).
  2. The software that is being created is continuously tested as it passes through environments. In other words: there’s no deploy that is not being followed by some form of testing, and in case of the local development environment, tests are run before any deployment (or better, commit and build) is being done.

Continuous Testing in two dimensions

This is not necessarily different from any other software delivery method, but what makes CT (and CD) stand out is that the time between deployments is typically very short. And that’s where the second part of the term Continuous Testing comes into play: ‘Testing’. How is this testing being done? This is where automation often comes into play, as an enabler of fast feedback and software moving through the pipeline fast, yet in a controlled manner.

Teams that want to ‘do’ CT and CD simply cannot be blocked by testing as an activity tacked on at the end. Instead, CT requires a shift of mind from traditional testing as an afterthought to testing being ingrained throughout the pipeline. Formalized handoffs and boundaries between environments will have to be replaced by testing activities that act as gatekeepers and safety nets. And where necessary and useful, this testing is supported by tools. In this respect, test automation can be an enabler of Continuous Testing. But (as is so often the case), only if that automation makes sense. Again, I refer to this blog post if you want to know what I mean by ‘making sense’ in a CT context.

I still don’t have a one line, encyclopedia-style definition for Continuous Testing, but at least the thought process I went through to write this (short) blog post helped me put some things into place. Next to Katrina Clokie’s book on testing in DevOps, the following articles have been a source of information for me (while being much better written than these ramblings):

What is continuous testing? Know the basics of this core safety net for DevOps teams
A real-world guide to continuous testing
What is Continuous Testing?
Continuous Testing vs. test automation (whitepaper)
The Great Debate: Automated Testing vs Continuous Testing

What is your definition of Continuous Testing? Do you have one?