Practical Experience: Taking Stance On Test Automation

Practical Experience: Taking Stance on Test Automation

It was a year and half ago that I was a bystander of an argument that has repeated itself a dozen times since. Which combination of programming language and supporting tool was better for automation system all across: Java with Sahi or C# with Telerik Test Studio. Each side blew-up weighty arguments: what is easier to do in each language, what language has better libraries, which tool has more flexibility, etc.

Who is right?

It is difficult to settle the argument entirely based on technology characteristics. Because, each language/tool has few aspects where it is better than the other. It is equally hard to judge which attribute is more important to be able to make a decision.

It is an Organizational Decision!

Now, it requires context-switching where we lose some time recalling/adapting to details of the language. It is very important for one to realize and scope the time that it requires for the engineer’s transition and that it requires to maintain existing automation. When the code is not written in the language the engineer prefers, the development and maintenance becomes as likely as not.

How to strategize for test automation in new Language?

Plan to achieve small success and grow. It is not possible to try automating the whole regression suit. Instead, try things, make mistakes and design even better approaches. This process never ends but at a certain point in time you achieve reasonably stronger point of view of the capabilities of the language or the tool. It helps drafting next generation of frameworks that sustain (as they should) over the life time of the product-under-test.

Automation is full time effort, not a side-line. Sometimes automation is extremely underestimated. Again, by starting small and growing, estimating the work can be gauged.

What if even after evaluating the new tool, there isn’t any clear choice? At this point the choice does not matter. The important thing is that we do choose one because the delay may be costlier if you made the wrong decision. Get the team to back whatever the outcome is, follow through with supporting that language.