Proper automation starts with proper approach selection and proper processes definition. But these are just first steps which require further correlations and updates as long as automation grows. And in most cases these updates/corellations are related to the specifics of used toolset. So, the more project specifics your toolset fits the less corrective actions you should make in your automation processes.
What should we do for proper test automation tools selection?
First of all, we should clearly identify what testing type the tool is supposed to be used for. So, if we plan making performance testing we should look for performance testing tool. The same thing is for functional testing, for unit testing or so. All these testing types are different by the area of impact as well as they use different approaches.
Secondly, we should pay attention to the technologies supported. Of course, if we start using some tool we should make sure that it can do the task we need from it. Otherwise, we're just losing our time which could be spent on finding more appropriate solution.
In this area we should clearly define whether we really need some already developped tool. E.g. if the system under test is supposed to be installed on some specific hardware and operates with some specific technologies, propably there's a reason to make some kind of built-in testing modules. It's almost the only way out for the systems which can't be accessed from outside. So, we have to interact with them from inside.
Thirdly, it's all about money. Various automation tools are usually costful and sometimes (especially performance testing tools) are quite expensive. So, we should identify whether the license costs are really reasonable for the testing we want to make. E.g. it doesn't make sense to buy heavy-weight expensive tools for the applications like Notepad or single visit-card website with static pages. In most cases the test automation investment will never return for the projects like that.
Fourthly, it matters what technoogies and programming languages are used for tests automation. From one hand we should make sure that we can find people who can work we the tools we select at all. In case of specific (and even sometimes self-made solution) a lot of time should be spent on getting familiar with test tool itself as well as such experience will be very specific. At the same when we use some wide spread solution it's more likely that we find people who's already experienced with such tools.
This point can include the programming language for test automation. It's critical for code-level testing as such testing operates with the code of system under test. And it's necessary to write the tests on the same language the application was written on. Also, the more popular programming language is the more people familiar with it we can find.
At the same time it covers another point we should take into account. It's integration capabilities.
As you might have seen, most of big vendor solutions from HP, Borland, IBM are actually complicated systems covering all application lifecycle. And each particular tool is just a component of overall solution.
At the same time light-weight tools which are actually some libraries are easier to adjust to development solution and integrate with development environment. And actually they can use the same toolset that developers use. And if test automation is coded on the same language as application under test it would be a good step for test automation solution integrity into overall build process.
Each point should be analyzed in details. The main thing we should do is to make sure that tools we select rather resolve our problems than create new onces. If we keep this idea the automation we make will take effect.
No comments:
Post a Comment