Building Automation Muscle

I started weightlifting back in July of last year, because I was tired of being fat and not having energy. Our 4 girls were constantly outrunning me and I couldn’t keep up.

That had to change.

My first day at the gym, I misunderstood the advice about how to get started, and ended up working every muscle group.

That first day was brutal. My bones hurt. And, my meathead friends laughed heartily at my expense.

In retrospect, I probably shouldn’t have told them, but sometimes I’m honest to a fault.

Now I work out using my kids as weight.

Their dad is a beast. Well… getting there, anyway.

Parallels to Automation

The process of learning automation–of learning anything really–is a lot like building muscle.

If you start off too fast, you might burn out, scare yourself or give up.

Too slow, and you risk setting a pace that doesn’t allow you to grow as fast.

But if you start at the right speed, your strength builds, and you constantly test yourself, pushing your limits, and understand what your body can and can’t do.

And when you define your limits, you know what to push past.

It’s Ok to “Reinvent the Wheel”

When writing code, we strive to not repeat work.

This is something drilled into us, that we shouldn’t be rewriting code that’s been written already.

I’m going to challenge that notion.

When you lift weights, you’re doing the same exercises that other people do. Curls, push-ups, squats, whatever–thousands of people are grinding reps out right along with you.

If everybody’s doing the same thing, does that mean the exercises are invalid? No.

Why is that? Well, because the point of doing the exercises isn’t to just do the exercises. Gyms don’t get built because there’s an overabundance of barbells that need to be constantly picked up and put down.

The point is to get stronger, so that you can do more in your day-to-day activity. The exercises are a means to that end.

Assisting Too Much

What if you’ve gotten stronger and you decide you want to help other people?

What if you showed up to the gym, and saw a new guy, just getting started, and you offered to do his exercises for him?

If he’s starting with low weight–like benching a 45 lb. bar–and you tell him, “Hey, let me handle that for you,” and you just blast out 500 reps with it.

Have you done him a favor? No.

Even though you’ve done a month’s worth of exercises on his behalf, saving him lots of time and effort, it doesn’t benefit him since he didn’t do the work himself.

(And honestly, if it was that easy to do that work, it likely didn’t benefit you either.)

Knowledge Groups

The biggest thing I’ve learned while lifting is knowing what I’m capable of. And as such, I know what limits I can push past.

I can also tell when my strength increases, because maybe I can do 1 or 2 more reps at a weight that’s really challenging.

The next biggest thing I’ve learned is that single exercises can train multiple muscle groups. It’s why I favor free weights instead of using machines, because I use my whole body to stabilize the weights, which increases strength elsewhere.

And then, interestingly enough, when I target specific muscles later, turns out they’re accidentally stronger than I thought.

As part of learning test automation, we also train different muscle groups, but in our brains instead.

Maybe let’s call them “knowledge groups”.

When we start off, it might be slow going. Writing scripts from scratch takes a lot of time and concentration.

But the more you do it, the more you might find that you’re learning new stuff without really intending to.

Maybe you start finding out better ways to define locators for your elements. Or a better way to architect your scripts so there’s less to maintain. Or a method to get tests written even faster.

All of these secondary learnings are side effects of what you’re actually focusing on.

“Show”, Don’t “Tell”

When dealing with people, let us remember we are not dealing with creatures of logic. We are dealing with creatures of emotion, creatures bustling with prejudices and motivated by pride and vanity. -Dale Carnegie

Showing someone that something can be done, is better than telling them how to do it.

I mean, if you tell someone exactly how to do something, it limits their knowledge growth to whatever pathway was chosen. It automatically puts them in a box, of, “This is how to do this thing,” which can be difficult to break out of.

Ideally, we don’t want to be mentally pinned down to a certain way of thinking. We want to always think, “I wonder how (or how else) this can be done?”

That’s the path to innovation.

But if you show that something can be done, that’s a pretty powerful thing.

Actually, it’s powerful in two ways, because:

  • Once you’ve seen it done, you know it’s possible, and
  • It allows you to get to the same destination, while learning through different paths.

Contrary to popular belief, it’s ok to reinvent the wheel when it means you learn new stuff.

And you will. Peoples’ brains all work differently, and the way new pathways get carved out will allow you to draw unique conclusions that no one else would come up with.

Just like training secondary muscles when exercising.

People learn in different ways, even when coming to the same conclusion. This is a good thing.

Market Trends

I used to fling around code snippets and tell people, “Hey look at this cool thing I learned.”

The intent was to help people by saving them time–why spend the time re-learning how to do something if it was done for you already, right?

Essentially, I was doing the very thing I said further up wasn’t a good idea.

For years I’d wondered: Man. Why aren’t these ideas taking off? Am I just rubbing people the wrong way? Or, am I not being convincing enough that this would help?

Well, maybe. It was only recently that I realized a more general reason why it wasn’t a good approach.

There was an article I read awhile back, which I unfortunately can’t find the link for, that said basically, if you want more user loyalty for your mobile app, make it just a little difficult to use. Not too much, but also not so slick either.

The reason is, when people have to grunt through and learn something–even just a little bit–then we have something we can be proud of.

We can say, “I know something that I didn’t know before,” which isn’t far removed from “I know something this other guy doesn’t know.”

We like knowing we have an edge. We’re creatures of emotion.

There are a couple trends in the test automation market today.

Companies that are capitalizing on the fact that not many testers are skilled at scripting, are providing solutions for that market.

And God bless them for that. I don’t fault them for wanting to make money. But they’re addressing a long term problem with a short-range solution. They are muscle-bound helpers, doing the heavy lifting for other people. 

The other trend that you may notice is the abundance of open-source solutions. Free ones too, but that require learning the underlying “how” of test automation. The stuff that gets abstracted away with high-level tools.

Because of that, I’m starting to not want to be the guy that has all the answers. As a consultant, I’m finding better success with guiding rather than plunking a solution down and hoping it takes root.

And maybe you would too, I don’t know.

But on the exercise theme: What if everyone adhered to a minimum standard of fitness?

Nothing huge, just something reasonable.

Wouldn’t the overall ability and health of a group be much higher? Wouldn’t some take that as a jumping off point to even better health? Probably  yes, to both.

If that’s true, then: What if all testers were able to automate some of their tests, using actual code?

Wouldn’t this make them less dependent on 3rd party tools? Wouldn’t this allow them to bring innovations into the automation space that can only come from a tester?

I think so.

I think too, that, as testers, we have a choice to make for our craft.

We can rely on 3rd party tools for our work.

Or, we can undertake learning how to do this ourselves.

I pick the 2nd option. It’s harder, but it’s worth it.

If you agree, then let’s go “Get Swole” together 🙂

When our oldest daughter was 2, one of the Goofy Dad Things(tm) I taught her was to ask people, “Did you get your tickets?” and when they’d say, “…to what?” she’d say, in the deepest voice she could, “TO THE GUN SHOW!” and flex her arms. LOL. 

As a tester, I want testers to also have “guns” they can bring to the gun show of day-to-day work. I’m tellin’  ya, there’s a huge benefit to being able to break out of this pervasive idea of “QA’s a bottleneck”, and contributing your unique flavor of Brain Juice directly to the automation effort. 

That’s part of the service I provide with my consultancy, Arch DevOps. But I’m not gonna do the heavy lifting for you. I’ll “spot” you, and give you guidance, but the new muscle you earn? All you.

Do you want to get you or your team’s skills to the next level? If so, let’s talk.


One thought on “Building Automation Muscle

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s