QuickTest Pro automated testing

Question

Hi All --

I have three easy questions.

Does anybody use QuickTest Pro for automated testing?

Any other automated testing applications that you recommend?

Is automated testing a good idea?

Thanks

Answer 1

'Automated testing' isn't as good as it sounds. As far as I can tell, it's the automation of test execution which is only part of the process.

Answer 2

which kind of automated testing ?

I've written a few scripts that are part of a post-build process to compare some results through the API, but this is not specially what you want.

In terms of automated windows user interface applications, I've had a glimpse on rational robot, but cannot specially recommend it.

Answer 3

which kind of automated testing ?

Automated testing of the UI. I saw rational robot as well but I am not sure which is better or if either is worth the investment.

Answer 4

We don't use QuickTest Pro where I work, but we are in the process of researching options for automated system testing. As far as recommendations go, that's a bit difficult without knowing what your criteria are for accepting or rejecting a software tool. I'm judging automated system tools according to these criteria:

• Does it enable someone other than a programmer to create automated system tests?
• Can programmers script it for customization purposes?
• Does it support data-driven testing (run a single test multiple times with test data from external files and/or databases).
• Can you configure the order tests run in?
• How well does it support inclusion in a continuous integration environment?

These are just capabilities. Cost is certainly a factor. Whether or not the tool requires learning a proprietary language for scripting is another factor.

Automated testing is definitely a good idea. Automated testing is one of the key enablers of continuous integration.

Answer 5

@Scott A. Lawrence - Your requirements are pretty much what I need.

Automated testing is definitely a good idea. Automated testing is one of the key enablers of continuous integration.

That's true for automated unit testing but does it also include automated UI testing? Not sure...

Answer 6

I've found automated testing of non-UI to be definitely worth it.

Automated testing of the UI is also worthwhile, but not as much. For my project, UI is less than 10% of the code. Automated testing of the UI has a bunch of other issues like timing and thread access that makes it more difficult than expected. I use nunitforms for UI testing.

I'd suggest that if it is possible, test the logic behind the UI first, then test the UI last. You get much better bang for buck with non-UI testing.

I evaluated Automated QA's testing program and it looked good but I went with nunitforms since it was more similar to what I was doing for non-UI testing.

Answer 7

There are several threads on SO concerning test automation:

• Which is better for web testing? Record-Play automation or coding?
• User Interface Testing
• Automated testing of GUI

I've never used Quick Test Pro, but I've been on several projects that have used different automated test tools; Silk Test, Rational Robot, WinRunner. The most successful of these efforts was the one that used Rational Robot with the RRAFS framework to isolate application changes from the test scripts. We also use the STAF framework for automating and managing our test infrastructure.

Automated testing is a good technique for testing facets of an application, but it doesn't replace human testers. Like all tools, you can use it or you can abuse it. As long as what you're testing is stable, repetitive, has predictable or computable results, and you test it often enough, then the cost of automating will eventually pay for itself.

Answer 8

I was head of an automation team that used QTP and I hated it. The record/playback functionality was horrible, it would routinely get confused resulting in weird test results. Record could only be used in order to build up the object database and even then had to result to all sorts of hacks in order to get it to work somewhat reliably.

QTP/QC is based on ActiveX/COM and can only be scripted with VBScript which is another bag of flaming dog poo. There are all these hacks and tricks we had to do in order to get any sort of extensibility. We were doing things like run a test that dynamicly adds the QTP test to the test suite, edit the input parameters, change the object repository so that it matches the enviroment, save the test, spawn a scheduler instance in order to run the test. Once the test is done copy all the results to the parent test and then remove the QTP test from the test set. In the end we ended up publishing custom COM components which the VBScript called into and used QTP/Quality Center as a half-assed reporting engine that didn't really offer enough flexibility to get the type of reports we really needed.

Another problem with Mercury/HP is that they outsourced all of their tech support to India and didn't train them. It was common to spend 2 weeks in lower level support purgatory before you could speak to anyone with any technical knowledge about the APIs only to be told that yes it's a bug but no we won't fix it.

I sorry about the strong language but I found the whole episode traumatizing and will never work on a project or for a team that uses QTP/QC ever again.

Answer 9

Automation of any tasks should be there if there are repetition in the tasks.For e.g. in a module if you have to run regression test cases for each build in which some minor improvements are made in the product, then the regression test case run can be automated. In this example, automation of the repitive test cases will increase productivity & will enable tester to concentrate more on manual testing.

Apart from qtp, you may also explore squish for qt related projects & test partner for windows C++ & VB projects.