In an effort to help with bandwidth, more companies are blending roles between developers and automation testers.
Usually, the language used for automation code is the same as the production code. It’s a good move when the goal is to have developers do automation too.
I Used to Be a Developer Like You (Then I Took an Arrow to the Knee LOL)
Back in the day I used a lot of different languages. Still do. C, C++, C#, Java. Then got into scripting–Bash, Perl, Python, Ruby.
Each of these languages comes with a… flavor? Idioms that exist in that language. Some port over to other languages but for the most part, there are certain things that you become fluent in when you’re exposed to a language long enough.
Like in English–phrases that we know what they mean, but broken down don’t make much sense? If something is smack dab in the middle of something, you know I mean it’s in the exact middle. But what’s a “smack dab”? Stuff like that.
Developers get that there are idioms in languages, and it helps them write code faster. It’s a good thing.
Wrong Target Audience?
I think however, that the target audience is wrong. It’s not developers and test automators (who are essentially developers of a different stripe) but testers that need to understand the automation more. Here’s why:
Testers Are Pretty Powerful
The best manual testers I know can break a system quickly. They just intuitively know how to get in and find bugs quickly. However, they’re not often programmers, and a hybrid tester/developer is a rare find. So, writing automation in a way that testers can’t understand is less a benefit and more a liability.
Too Much Automation
There’s such a thing as too much automation. I’ve seen it happen. More often than not, automation testers either are, or tend to want to be, developers. Their focus isn’t so much on test conciseness, but rather writing code. It’s great practice, but every line of code increases maintenance and reduces understanding of the code.
Every line of code has to be maintained sometime. It’s a good tenet to live by when writing automation code, because there’s a cost associated with writing code.
Code’s kind of an organic thing. Eventually you may want to update part of it to a different technology, and if there’s a ton of code, it may require a complete rewrite, which is costly in itself.
Having lots of code makes it more difficult to refactor when you need to. Refactoring is key to having a lightweight, maintainable code base for automation. But if it’s so big you can’t refactor, it’ll get so huge it’ll collapse under its own weight.
The Wrong Tool for the Job?
What I’ve noticed then is, the languages that developers use generally aren’t the best choice for writing test automation code.
Common object-oriented languages like Java and C# are easy enough to read and understand if you’re a programmer already. But if not, it’s terribly difficult to understand the code that’s written. The target audience can’t understand the automation, and so there remains a disconnect between developers and testers.
That’s one of the problems I solve with my company, Arch DevOps, LLC. Lack of understanding test automation is a huge barrier to companies being able to move as fast as they want.
There’s not a need to have sameness in languages between development code and automation code. Scripting languages like Ruby, Python and Groovy let you do some creative work with abstracting the confusing code–“hiding the ugly” as I call it–to expose just the key pieces for writing some concise, readable test automation.
Which is better–this:
$browser.text_field(:xpath => '//input[@id="username"]').when_present.set("mfritzius") $browser.text_field(:xpath => '//input[@id="password"]').when_present.set("pass123") $browser.element(:xpath => '//a[@id="submit"]').when_present.click
LoginPage::enter_username("mfritzius") LoginPage::enter_password("pass123") LoginPage::click_submit
I’m sure everybody said the second one.
Code-heavy automation requires focus to drive it properly, and even more so if you’re not a programmer. One cool benefit of having a framework that allows you to write like this is, you spend less time thinking about the code, and more time thinking about the thing you’re trying to test.
There’s a tremendous amount of metaprogramming that scripting languages let you do, so that you don’t have to write as much code. Less code equals less maintenance, and more speed since you don’t have to write as much.
My brain be like, om nom nom nom nom. This is fun stuff! And a scripting language for test automation is the right tool for the job.
Here are some other benefits:
The more languages you and your team are exposed to, the more valuable they become. There are problems that can be solved easier because you have experience looking at the problem from more than one vantage point. It’s like having tools in a toolbox–nobody has just a hammer or just a screwdriver. More languages equals more tools in your toolbox.
The people on your team will be more valuable as well. Someone who knows just C# is pretty good. But C# and Ruby? Even better. Keep stacking up languages!
When your team sees that you’re willing to invest time in teaching them a marketable skill, that sends a message. They know you’re teaching them something that makes them a higher value target by other companies, but if you’re willing to let them learn awesome new stuff, that’s gonna create loyalty right there, I tell you hwhat.
If you’re not able to automate quickly, or your testing team is getting underwater, maybe it’s time to switch up the technology stack a bit. Ask me how a scripting language can help your team get to the next level in test automation.