OpenText Functional Testing Reviews and Pricing

QA Expert at a tech services company with 1,001-5,000 employees

Nov 11, 2013

Is it sane to compare Selenium with QTP?

I have seen many articles which compare Selenium (1 or 2) with QTP (or other commercial tools). But these articles miss very basic point that Selenium is a library available in variety of language while QTP has entire gamut of tools with it. So if you were to really compare QTP with Selenium then comparison should be based on the library of languages which is offered either of these tools, which in my opinion Selenium wins outright over QTP.
My only intention of writing this post is not claim Selenium victory of QTP but to demonstrate how badly Selenium is compared with QTP at times. There might be things QTP would be good at doing (I left QTP long ago hence can not name any) but to disregard Selenium on the factors I listed herein is highly biased.

Object spying - Sure, you have QTP recorder which does it for you but don't forget that you can test object locator using Selenium IDE and it is not limited to using only Selenium IDE. Firebug with Firefox can be used for same while Chrome has built in development tool bar to test element locator. In case you don't know you can use $$("cssLocator") to test css locator and $x("xpathLocator") to test xPath in both FF and chrome to test application objects. Can you use QTP to test object locators in FF and Chrome?

Debugging code - So QTP comes in with built-in editor and Selenium is defeated in this aspect. Is it? Given the variety of languages Selenium can be used with, you have far greater language editor options with Selenium than with QTP. You have umpteen options with editors like Intellij, Eclipse, Visual Studio than the one available with QTP. When I was working with QTP I could not even conveniently rename test methods spanning across multiple files. Such re factoring is child's play with professional editors you use with Selenium

Recovery Scenarios - This is one of the biggest cheat point of QTP. Add recovery scenarios and tool takes care of working around the update windows. First of all if you add recovery scenario then it slows down the speed of test execution as there would be one listener always looking for such events, which means more recovery scenario and be ready for more slower test execution. Why should you bother about those automatic update windows in your test environment? Should not you proof your test environment against such update windows? If it is windows or FF then disable automatic updates. And best if you can not manage your test environment then out source it to some else like - Sauce Labs or Testing Bot

Testing non browser applications - Well, when did Selenium claim that it can tests window based applications. Selenium is browser automation framework. Comparing Selenium and QTP on this front is like comparing apples with oranges.

Great object Repository of QTP - So QTP can store objects in an external location, all you need to do is to update object repo when your object location changes. And then you find that the easiest way to port QTP scripts from one machine to another is to use Descriptive Programming which indeed means that you should do away with your beloved object repository of QTP. Now coming to absence of object repository mechanism in Selenium. Have you heard of properties files or Page Factory and guess what, you you don't have to do away with any thing to be able to port your Selenium tests from one machine to another.

No built-in Report with Selenium - QTP generates nice test reports and with Selenium - none. Really? When you pick up a language for Selenium you would be using a framework in that language and most probably the framework will provide you the reporting capabilities. For example there is ant task to generate test report in JUnit while TestNG has buit-in reporting mechanism. Google it and you would find similar options in language of your choice.

QTP and QC integration- You bought QTP for test automation now buy QC for test management. What with Selenium Test Management tools. None. There are indeed options - xStudio is one good option for small Selenium teams looking for test management with out spending any extra money. And their commercial options are cheaper than QC. If you are looking to port your test results to Test Management tool then TestLink might be worth a try. In this case you don't have to pay at all.

Disclosure: My company does not have a business relationship with this vendor other than being a customer.

it_user68493

QA Expert at a financial services firm with 51-200 employees

Nov 11, 2013

QTP Sucks Selenium Rules

I decided to use Selenium because I like the freedom that you get with all the programming languages it supports and because development is usually quicker than any other testing tools I ever used!

I chose Selenium IDE as my first open source automated tool. And then I worked with Selenium RC. And now Selenium Webdriver. It's the best testing tool ever!!

I think QTP is sucks. Of course, QTP fanboys will immediately jump up & down stating that I don't know how to use QTP. On the contrary, I know exactly what I am talking about. Because I've been a QTP Engineer for last 6 years. As of this writing, QTP still does not support Mac OS X, and Linux, heck it still doesn't support Firefox 3.6! Are you kidding me? Well, apart from HP's snail pace development process, I have other problems with the tool itself. Like its really retarded scripting engine (which uses vbscript), which does not provide you any real mechanism to maintain frameworks. Another example - CreateObject("WScript.Shell") - what do you think will happen if you used that in QTP? Any programmer who knows vbscript, will say that it creates a wscript object but she'd be so wrong. It rather creates a native windows shell automation object. WScript CreateObject() is simply not supported in QTP as QTP scripting engine overrides WScript.

Let us get one thing straight - Automation is programming, now let that sink in for a second...again - automation is programming. If your automation tool does not provide a real good programming interface, it is not fit for automation. Obviously in my books, QTP falls way short of that goal. One of the statements I consistenly hear is - "oh we don't have programmers in our automation team". If you cannot see the fallacy in that statement, no one can help your team - not even QTP. And of course, support from HP is bad too. Case in point - few month ago our team encountered a bug in QTP 10 where it had memory allocation issues & the workaround offered to us - "restart QTP after every 4 test case runs". I am not joking.

QTP does few things really good vis-a-vis record & playback (and they make it real simple for non technical users). And that also includes support for various enterprise applications both web based & win32. That means, they have to cover a lot of territory before they can release something and that explains why Windows 7 support is still lacking. But in your case, do you need Sharepoint support on Windows 7? If all you're testing is your own web app, why do you have to wait for HP to finish support for say Oracle enterprise apps? At this juncture, the only reason your team is still sticking to QTP is either because you have no real developers in your QA team and/or you have a lot of test cases automated in QTP. The later is a pain initially to convert to something else, but if you plan it out correctly you will save tons of headache in future.

I could go on & on about all that is wrong with QTP, but this article is not about that. This article is about getting rid of QTP & using alternatives in place of it to achieve a truly cross platform solution. After joining my current company, one of my first goal was to do exactly that. And this article describes what we did & how we did it.

To see a list of hotfixes that I know of see:

http://www.sayem.org/2012/02/qtp-sucks-selenium-rules.html

Disclosure: My company does not have a business relationship with this vendor other than being a customer.

it_user122115Works at a tech vendor with 10,001+ employees

Report as inappropriate

Sep 9, 2017

One of the downsides of the internet is that it keeps iu-informed and out dated posts around to help propagate the the notion that change doesn't happen. Micro Focus (then HPE) has release LeanFT a few years back which support creating and replaying tests on Mac, Linux, and Windows. And if that wasn't enough, most QTP customers already have access to it. But as they say, "Wait their is more", you can choose to write your tests in Java, C# or Javascript and leverage popular frameworks such as Junit, Nunit, TestNG or even build frameworks such as Maven.

As I like to say #DiscoverTheNew.

And for disclosure, I am a Solutions Architect who has worked for Mercury, HP, HP Enterprise and now Micro Focus and have supported the functional testing tools since WinRunner.

See all 2 comments