Integrating QTP With Non-Mercury Products

The first thing I should say is that it’s not perfect, that we cobbled it together in between developing our testing strategy for our current release and writing regression test cases for some legacy products. We’ve got plans to improve it, we know pretty much what’s missing, but, as with most meta-testing projects, IT WORKS.

The second thing I should say is that we’re trying to follow an Agile methodology here, and while we haven’t worked it all out, we at least use some of the terminology. If you see some term you’re not familiar with, it probably comes from that school.

I’ll start with an overview of the process, then discuss some of the steps in detail:

• At about 2am, CruiseControl starts what we call the “Nightly” build
• The Nightly build is just an Ant task that starts by building the software (it’s a Tomcat webapp, but that’s not critical to the process discussed here)
• A blank test database is created
• The build is unit-tested, then deployed to a test server
• QuickTest is called upon to run a test that just verified the most basic things: a user logs in, then several objects are tested for existence and properties
• The build is declared “Valid”, and a more comprehensive suite of tests is run (via QuickTest Pro and other automated testing tools
• After each test is run, test results are reported back to Rally (our Agile project management software)

As you may see, these processes take the place of many Mercury products (Quality Center, IT Governance, etc.). We’re a small shop and can’t afford all those tools, and even with the amount of man hours spent on these side projects, I’ll bet we’ve only spent a fraction of what we would spend were we to buy them. I can’t quantify that, and I’m sure someone at Mercury would argue that I’m not factoring in anything, but one thing I know for sure: there is a heck of a lot about our needs that Mercury doesn’t factor in when they charge their astronomical fees and we do actually pay them. They’ve provided some tools that allow us to get this stuff done, so we’re taking full advantage.

And that should put to bed any speculation that we’re secretly in league with Mercury and just using this forum to promote their products.

[/rant]

Here’s the list of things we used to do it:

• Perl
• XML-XSLT
• Apache Ant
• CruiseControl
• Rally
• IIS (could as easily have been Apache)

We’ve written a web-based interface to our suite of QuickTest Pro tests, which allows anyone to run any test at any time on the box running QTP. It’s a simple cgi script that takes several parameters: you select the test, enter where you want the results stored, and when the test is complete, it redirects you to an html representation of the test results.

What that really get us is the ability to launch any QTP script from any application that can make an HTTP request. Ant can do this, so we just have a series of Ant tasks that call the GET method, like so:

<target name=“runQuickTest”>
    <get verbose=“true” src=“http://servername/qtp/LaunchQTP.plx?testname=LoginTest”
        dest=“${outputDirectory}/results.html” />
</target>

The @dest attribute just tells Ant where to put the resulting document on the build machine. We post it at a location that will be stored as a link in the Artifacts folder of the given build.

So, a Perl script, a VB script, heck, a wget command can launch QTP. That means you can integrate with nearly any product out there.

Now, as to the Perl script itself? It’s kinda involved. I’ll post that later when I’m able to cover it in more detail. The plot summary is that it uses the Win32::OLE library (available from CPAN, but usually distributed with any ActiveState version of Perl) to do exactly the same kind of interaction with QTP as you could do with VBS. The fact that it’s in Perl means we don’t have to do any special magic to get to it from within our test harness or any of our other interfaces, most of which are written in Perl.

The ability to integrate QTP tests with our existing build process was invaluable. It allowed us to keep on the track we were on before, using Open Source and keeping tight control over the minutae of our processes.