Adding UI Automation Skills to Manual Testing

Why is UI Automation So Difficult?

There’s a trend I’ve noticed where people who are able to automate tests are more like developers than testers.

It’s expected, because automation code is still code–it’s not different just because it’s for running tests.

However: all of the automators I’ve known have gone on to take developer positions.

Not saying that’s a bad thing. I am saying though that the mentality of automators who think like developers is much different than automators who think like testers.

Problem is, automators who think like testers, or testers who can automate, are hard to come by.

Problem Set

It presents a distinct set of problems:

• Automators who are more like developers can write some heavy code–heavy as in, it takes a dev to write/read/extend it,
• Many testers can’t code, or at least can’t produce as much code as developers, and
• The bar is kinda high for manual testers to start automating.

The manual testers I’ve worked with have been incredibly powerful in their ability to find bugs. There are a few in particular that I know can find bugs within a short time after a deployment.

But it takes time to run manual tests–time which costs money.

What about giving manual testers the ability to automate?

Here’s a strategy to counter the problem set above:

Solution Set

• Provide a framework that takes common operations (clicking things, entering text, getting values from fields, etc.) and boils them down to something easy to read and understand

With automation written in raw C#, Ruby, Python or Java, it’s very easy to get lost in thinking more about the automation, than the thing you’re trying to test. I know this because I’ve seen me do it.

It’s also very easy to not “hide the ugly”–stashing the nuts-and-bolts code away somewhere where most people don’t have to know about it in order to write automation. When we’re trying to get a test to just work, you spill some goop and it doesn’t get cleaned up sometimes.

This causes people to have to be intimately familiar with how the framework works, which clutters up brain space, and again takes the focus off what you’re trying to test, and forces it to be on the tool itself.

But what if you could take lines like this:

$browser.text_field(:xpath => '//input[@id="username"]').when_present.set("username")
$browser.text_field(:xpath => '//input[@id="password"]').when_present.set("password")
$browser.element(:xpath => '//input[@id="submit"]').when_present.click

and instead write them like this:

ThisPage::enter_username("username")
ThisPage::enter_password("password")
ThisPage::click_login_button

Isn’t that easier to read? Wouldn’t it be even cooler to know that there aren’t any methods anywhere called enter_username, enter_password or click_login_button–that metaprogramming figures out all that for you?

Wouldn’t it be neat to know it’s already being done?

I’ve had a lot of fun helping train manual testers on automation of this sort, and am excited at the possibility of arming testers with technology to help them take a stepping stone like this, to learn more about automation, and get deeper into it without having the bar set so high.

There is tremendous advantage to having testers know how to automate.

One big advantage is, you’ll likely get less code to have to maintain since testers will strategically know which tests can do the most damage.

Why write 100 tests that all basically do the same thing when you can get the same result with 5?

Look at all that time they just saved. Look at all that time we just saved. Awesome.

And, you get some new Brain Juice added. Devs who automate think differently than testers who automate. Great things will happen when there’s a whole new segment of problem solvers in the mix.

I’m hoping to have more info to share in coming weeks, but it’s been fun seeing where this is going. Stay tuned!