Saturday, December 26, 2009

Choosing right test automation tools

Many Companies run special activity of investigation on choosing proper test automation development environment. And this big deal inquires lots of evaluations, reading reviews and surveys, asking gurus’ advices, modeling integration with other tools and trying to figure out how to fit a particular tool to overall test automation strategy.

As a first step I suggest to put all your objectives and priorities on a list. Then, try to segment all considered tolls from top to down. For instance, let’s begin breaking down by all tools on open source and proprietary, free and requiring to be purchased. After that, try to go deeper, i.e. segment tools by features, supported technologies (tip: don’t assume that if a tool support a lot of technologies is the best choice, you may be glad tool which supports technology on which your AUT is being developed), supported environments (OS, browsers and so on – this matter is especially important), supported test automation frameworks, parameterization, object recognition, logging and reporting, technical support and documentation. Also study these tools on supported development languages. I strongly advice to sharp your focus on those tools, which support modern and powerful languages (Java, JavaScript, Perl, Ruby). Surely, there are some tricky moments more, like tool stability, integration with other tools (bug tracking, test management, reporting frameworks), and possibility to run simultaneously and remotely. So that’s enough, I think you will have some more specific reflecting your particular needs.
Once we put all things together, we can rate the considered tools and as result making decision likely will be selection between 2 or 3 good tools.

And a last sentence, fit test automation tool with your team skill set, if your team is skilled OO developers, don’t spend money - select open source, your team will take care about developing good test automation framework without needs to use clickable and drag-and-dropable interface. And vice versa, if your team just analysts w/o development background select something easy to use w/o needs to code, but in this case test flexibility rate is almost zero.

No comments: