After some recent posts, people have asked how they can learn about test automation. I think we can all agree that automation is something good to know in the software QA field, and any amount we can pick up will help us in our jobs, not to mention make us more marketable.
But, it can be difficult to start because it’s a HUGE field. I can imagine some people having trouble starting, just because it’s hard to overcome that inertia for a few reasons related to how much possible there is to learn.
There are 3 Big Secrets that I’m gonna just spill, free of charge, so that you can get started.
Big Secret #1: “You can’t steer a parked car”
This is something my father-in-law told me years ago, when I was asking questions about spiritual guidance. I’d been wondering, how do I know if I’m in God’s will or not? How do I know what direction I’m supposed to go?
His response? “You can’t steer a parked car.”
I mean, he elaborated later, he didn’t just leave it at that.
It took me a minute to figure out what he meant, but it finally hit me: God will direct my life if I just… move. He’ll do the steering.
Pretty cool.
It’s neat how a piece of wisdom small enough to fit on a Snapple cap can apply elsewhere. When it comes to learning automation, we ask the question, “What direction should I go?” And really, we should first consider, “Am I even moving yet?” You can’t go in a direction unless you’re going.
If we’re not moving forward in some direction so that we can pick a direction later, then we just need to start the car, and push the gas pedal.
Big Secret #2: There’s no wrong thing to start with
Along with the previous Big Secret is this one–there’s no wrong thing to start with.
People sometimes think that if they learn something that ends up not being used much later, that it’s a waste of brain cells.
Truth is, it’s not.
In the past years, I’ve become interested in how our brains learn things. And I’ve found that, as we learn, our brains carve out specific and abstract pathways.
Specific pathways are made in response to the things we learn–things like “2 + 2 = 4”. These are concrete, factual things.
Abstract pathways are the ones that are created as a side-effect of specific ones. They’re the reason why we can think in terms of pictures or figure out complex answers later.
This is where the real power of the human brain comes out–we don’t have an explicit pathway carved out for these abstract ideas, but our imagination, visualization, and ability to think outside the box, are improved as we learn things, regardless of what we learn.
The process of learning something, and even the order in which we learn them, gives us each a unique fingerprint to how we solve problems. Because of what you learn, there a problems that only you will be able to solve. The more you learn, the more of these kinds of problems will be solved only by you.
There’s no wrong thing to start with. Pick a thing! You’ll be fine.
Big Secret #3: Mastery isn’t required
Some people think that, unless you have complete mastery of a subject, it’s not very useful.
The big secret is: Nope. That’s not true.
There’s a limit to what you can solve with a particular toolset. Some tools are better at solving certain problems than other tools. And, the more you stay with a certain toolset, you’ll find there’s a point of diminishing returns.
Here’s an example: Years ago, when I was working in a Linux environment, I used to do everything with Bash scripts. That’s what I had mastery of, that’s what I knew the most about, not many other people knew how to do what I did.
I had found a niche. Or so I thought.
What ended up happening was that, although I could solve the problem using the same tool I was comfortable with, it got to be really time consuming to do so, not to mention it got to be very unreadable.
Fast forward to… well, just a few weeks ago. There was something that turned out Bash was a pretty good fit for. And the solution ended up getting extended and getting heavy into regular expressions, and it was a real pain to contort the script to work. So I just said, “BAH! Forget it, I’m switching over to Perl,” which is not only better suited for that type of thing, but was already installed on my machine, so I didn’t have to contact Help Desk to get something else put on.
I’m certain that if I’d rigidly (and stubbornly) stuck with my preferred toolset years ago, without seeing what else was there–whether it was better or not–I’d be severely limited, both in terms of how quickly I can solve a problem, and what kinds of problems I’m familiar with.
There are concepts that you can pick up with one tool, that apply to other tools too, and it enhances your ability with them as well. But you won’t find that out if you strive for mastery of a toolset.
It doesn’t take master level knowledge of a tool to wield it properly. Actually, I’m gonna be bold about this and say: if you find a tool that does require mastery in order to use it, don’t use it. The rate at which software changes will make that tool obsolete, and you’ll be spending more time trying to figure out the tool, and less time actually being productive with it.
Don’t worry about not having mastered something before moving to something else. It’s not a waste. The things you’ve learned now will enhance what you learn later.
On Getting Started
“That’s great, Fritz, but I don’t have any time to pick this up. How should I get started?”
Very common question. Here’s my advice:
Start With Your Manager
It’s pretty easy to make the case for a good ROI on automation:
- I have a task that I have to do manually.
- It’ll take some time to learn/write some automation to replace it.
- After that, my time’s freed up to do other things.
Some variant of that should suffice.
If your manager is on board with it, then ask if you can invest a small amount of time per day to learn automation. Pick out a particular task that is time consuming for you–or better yet, your team–and learn whatever it takes to automate that task.
Be sure to pick out a small task, because you don’t want to pick a huge thing and risk discouragement. You also want to have something to show your manager in a short amount of time.
Your manager will get benefits out of you learning automation, for obvious reasons. The not-so-obvious reasons are that first, they get a very small “experiment” to see if this works. If one person is spending a little bit of time to learn something, it doesn’t cost the company a ton of money. It’s a lot less risk than the whole team or company doing something new. Second, when this works, then you can share the knowledge around your team, or even your company. This helps your manager look good, too.
If That Doesn’t Work…
…then unfortunately it’s up to you to find time.
I know we’re all pretty busy, but if you can invest even 30 minutes per day on something, before too long you’ll have a lot of practice and knowledge accrued.
Just think–30 minutes, Monday through Friday, every week, is 130 hours per year. That’s a lot of time.
I don’t know how to tell you what needs to get dropped or moved in your schedule–that’s up to you. But I do know that we all (myself included) probably have things we spend time on that we can spend a little less time on, and find some new time to do things with.
30 minutes is a little over 2% of a 24 hour day.
Once you know a bit about automation, you can make a simple proof-of-concept, to show your manager, and explain that you did this on your own, and prove that it can help save time.
If that works, then the automation effort will help carve out even more time for you and your team. It’ll take some work, and may be slow going at first, but will get better. And so will you.
Where Can I Start?
There’s a two-part series where I direct people to get them started.
It’s about automating web UI tests, and I pick it because it’s nice to be able to see the effects of your work, right away, by watching the webdriver interact with the page with code you wrote. I’d recommend going through it and learning all you can.
From there, you can branch out to learn more about different types of automation, like for file systems, databases and webservices. The things you’ve learned previously will help you learn new things, because there are similar ideas that apply to those kinds of automation too.
I hope above all else that you enjoy the journey! There’s a lot of cool stuff out there to learn.
–Fritz
If you’re still having trouble getting going with test automation, that’s something I help with. My consultancy, Arch DevOps, specializes in getting teams going in that direction.
Would you like to find out how?
testzius 