One of the basic challenges with test automation is adoption. I can’t tell you how many times I’ve cataloged licenses for a company and found out they already have many different automation software packages, none of which is being used. Traditionally I’ve been told that is because the tools don’t work and that the teams had a hard time implementing the automation.
Let’s take one thing off the table, there is NO tool problem. Most automation tools do the same thing, catalog objects, record and playback and advanced scripting abilities, so, please, if you trying to organize an automation project, don’t make it about a tool (I think I’m famous for saying this, since tools are only means to an end, they aren’t panaceas, in fact that’s the last thing they are).
Second, the problem is people, not tools. Most testers do not have the skill sets to program in one these monster packages like QTP. They are put in front of a complex IDE and expected to scale that tool with relative ease. Problem, most testers don’t know how to program or haven’t in so long that there skills are completely inadaquate to the task. My experience is that to get a line engineer to learn how to program effectively takes 18 months, I’m sure I have some aghast looks here, but to be “proficient” is a complete different level of understanding then just “grinding” through a software package and hoping your developing scalable automation.
Some of the new tools are trying to divide the effort between automation engineers and line test engineers. QTP has designed a keywork abstraction for their automation tooling. It’s quite complex, but I feel that they are going in the right direction. If you can pair up your subject matter experts with QC Component test automation experts, then you might have a scalable solution, but too many don’t go down this path.
What do I suggest?
- Select a test design process
- Organize the effort around mini-pilots
- Don’t buy tools if you don’t need to, lease them at first
- Understand your teams skill sets – this metric sets adoption
Good luck!
I agree, on division of test engineers and test engineers and their cooperation in building automation, which is (domain knowledge + professional coding expertize). Though must desagree about coining term as “monster package” for QTP. QTP could be utilized to just wrting vbscripts and crelating it with object repository. building smart and effective framework is very important. Also desagree that all tools are equal. Again, most of the less expensive or open source tools have limited features. Though we know that we can build automation without tools at all, just coding in c# or c++, or vb. tools help to achieve goals quicker. Agree completely about companies wasting moneys on byuinng all poasible tools without understanding that they need sckilled enginners to operate them. Most of the skeptisism about automation is comming from the original mistake that qa engineer (you call it line engineer) can develop auto tools. Many QA managers become angry when they hear that it’s not true. I beleive that automation tools marketing teams make imperssion when they sell tools that it is for non-techs. And in most cases it works for simple auto tests they build during the demo. The real life automation is a serious task that requires above average programming expertize. From my experience the best model would be Automation Engineer embeded into QA team. Ratio could be 1/4 or 1/3. One auto engineer per 3 or 4 qa. Also important to educate qa engineers how properly investigate test results. The best is to build intellegent configuartion platform to allow qa engineers to reconfigure auto tests for different platforms. Cheers! Dmitry