How would you describe automation to someone?
Would you talk about its benefits? Pitfalls? Or would you take a different approach entirely?
That depends on who that someone is. But I personally have somewhat of a problem when people say test automation, similar to that we do not call that automatic build and deploy as “development automation” even if it is. The pitfall is that leaves you with the impression that you can automate testing, which you cannot, at least not yet. Instead you can automate parts of that process, typically the repetitive, non-sentient parts.
So if you want to just describe “automation” that is the process of making a computer do part of the work. Like having robots assemble a car.
2 Likes
That’s why I was very careful not to say “test automation” 
1 Like
Well, you are gonna deposit 1 million dollars in any bank. Imagine how much time you have to wait if 1 million $ counted by either bank clerk manually or counted by machines automatically.
So, choose your option accordingly 
2 Likes
That’s really interesting because in my context, making the differentiation between test automation and deployment, build or development (as a few examples) automation is important. Our team is cross-functional so we do need to differentiate.
If we’re talking test automation then I like to talk about it as giving a level of confidence that nothing has changed to break the software you’re deploying. The areas of the software you are testing are returning what you would expect.
I would highlight the repeatability and fast feedback of test automation but also make sure that test maintenance and test creation time is highlighted (it isn’t a time saver, especially short-term), as well as what its limits are in terms of finding unknown issues in your software.
3 Likes
The conversation would go like this:
Have you ever had ice before? Did you have to create the cubes or chunks yourself? If you’ve ever made ice from cube molds you know it is not a fun process. Fill up the mold with water to the tip top and try not to spill it all over your frozen burritos as you slide it into the freezer, wait 3 hours, and then try and pop the cubes out of the mold without making a mess. And what about those ice chunks that aren’t all the way solid. I have no idea how to make those from home. This is where automation can come in. Whether it’s an ice machine built into your freezer that distributes cubed goodness or ice chunks from the ice maker at your favorite restaurant. You push a button and get ice (near instant result). The boring and difficulty of the process has been automated away. This is a simple example of how you probably use (hardware) automation every single day. When it comes to automating in software you can take out some of the boring parts. The difficulty, is for every type of ice you want you have to rely on different hardware, different size parts, different freeze temperatures, etc, For automating software, more than likely no two pieces of software are the same, so it’s like having billions of different types of ice you need to automate. Building automation around software can be very complex.
1 Like
Any activity where machine replaces human is “automation” . A basic example is wheel. This is how I approach.
3 Likes
What an interesting question!
Basically my message is about the value of automation in the other person’s perspective. I.e. whoever I’m talking to. Yes the benefits and pitfalls are important, but I want them to think and reflect before I teach them too much about the details here.
This is about communication. I always try to assume a perspective that makes sense for the person I’m talking to. The overall message they are receiving should be about value for them.
So with the usual “it depends” reservation, if I’m addressing management, I’m finding myself saying things like the below.
Automation is about eliminating work in order to save time and resources to save for more proactive, qualitative, and investigative testing. Automation can really speed up things in testing. But automating (the work!) is not simple so there are severe risks involved that the benefits may never work out due to the sheer cost of getting there. Also, laying off testers is generally a bad idea. Automation is not good at dealing with complexity. It needs maintenance, and it won’t identify risks. Only bugs. The industry has been plagued by that problem for the past decade. But people are getting more careful about approaches and processes these days and it’s my experience that with skilled developers with experience in automation, good understanding of testing processes and the risks we are dealing with in production, automation can substantially help support the business.
2 Likes