Every so often I’ll see posts on message boards like this: I need to automate tests, what tool should I use?
And unfortunately, that’s the wrong angle to approach the problem from. The first question you need to ask yourself is “what programming language is the app I’m testing developed in?” That seems like a very basic question, and some people may be insulted by it, but I have worked with teams who didn’t know the answer. Keep in mind that there may be more than one language in use – an app developed in ASP.NET may also have a SQL server back end, so you’d need to know C# and SQL. Once you know what language your app is written in, the next question is, “Can I code in those languages?”
If not, start by learning about that language. I’m not saying that you need to become a full blown .NET or Java developer, but you should understand the language, how it works, and how to write some basic code. Now, this is usually where an oldschool QA manager would have a stroke. “My people aren’t developers,” he says. “I just want them to click a record button and then have everything work.”
That’s a lovely idea, but it’s not reality. The cold truth of the matter, folks, is that when you automate, you are writing code that tests other code. That’s exactly what record and replay tools are doing, but they abstract it up a level or two so that users don’t see that code. Problem is, those tools can only be so smart. Eventually, you’re going to encounter something in your application that a record & replay tool can’t handle, and then you’re stuck. The only way to become unstuck is to code your way around the problem.
So start out by learning a bit about the language your app is written in. This will help you learn how your app works under the hood, which then means you can start tinkering with different ways to automate things. Back before I knew SQL, I had to modify all my test data via my app’s UI. That was a laborious, time consuming process. Then I learned how to write Update statements, and that let me modify the data much faster and more efficiently than before. I’ve seen this many times, where the person who does the most effective automation is the one who understands how to code.
It’s a worthwhile endeavor that will not only improve your automation efforts, but will increase your value as an employee as well.