SELENIUM SUCKS! QTP RULES!
Selenium sucks! QTP rules! Got your attention, didn’t I? How many times have you heard this type of statement from overzealous automation engineers? Truth be told, I usually hear statements like this most often made by open source evangelists.
One Test Automation Tool to Rule Them All
The fact is, however, there’s no such thing as a perfect test tool. There is no “Test tool to rule them all.” In lieu of that, you have to use the tool that works best for your team and your particular application. And just because you use one tool for one specific project does not mean you should use it for all your projects. Many test tools require an investment in not just dollars but also in learning and infrastructure – so I understand how tempting it can be to stick with one tool solution for all your testing needs. If you have a hammer, everything looks like a nail.
My Test Tool Dilemma
The main application I test in my current position has many layers of proprietary control wrapped in an active x control and displayed in a web browser (IE to be exact; it doesn’t run under Firefox). The application uses a hodgepodge of non-open source technologies like .NET, CACHE DB, and MUMPS. On top of all this is a Frankenstein-like build system that I couldn’t even begin to explain the workings of.
QTP / UFT
My company also has an enterprise license for HP’s automation tools. So which tool do you think I choose to use? That’s right — QuickTest Pro. Why, might you ask? Well first, it’s the standard tool used throughout the company. Most test engineers are already familiar with it so there’s no need for training and it works (albeit with several modifications) with our application. Also — it doesn’t hurt that I’ve been using the Mercury/HP toolsets for many years.
Some of the groups in my company are moving to AGILE. One group, in particular, is involved in a new application that uses the latest and greatest web2.0 technologies. Also — unlike my group, most of the development is done using open source technologies and uses Hudson for daily builds. This team’s application can run under different browsers and the application is fairly straightforward. So, in this case, I would think a test tool like Selenium would be a better fit than QTP.
Allegiance to a Test Tool
The point of my rant is that we should all have an allegiance to a particular test tool. As automation engineers, we should be focused on developing the quickest method with which to create reliable automation solutions that serve a specific business need!
Don’t be a Test Tool Fanboy
This leads me to my last point. You should not align yourself with one company’s tool. Let me tell you a quick story. Long ago, in a cubicle far, far away lived a Win Runner automation engineer. How he loved the crisp white screen of a new Winrunner test! The engineer spoke the language of TSL. There was no business problem that he couldn’t solve with the right Winrunner script. Then, one day, Winrunner was discontinued. No longer would his favorite test tool get updates. Job postings for Winrunner experts became fewer and fewer. The engineer was heartbroken. Don’t become like him! Keep learning. Use the right tool for the job. Never become a Selenium or QTP (or whatever company’s technology) fanboy.
So what do you think? Am I wrong? Leave a comment below and let me know!