The Inquisitors are proud to introduce a bit of code we have been working on. We are calling it the Software Inquisition Foundation Library for QTP, but you can call it SIFL (pronounced like "sniffle", but without the "n").

SIFL is a collection of QTP functions that we have been using for a while as a base framework for our QTP tests. Having eschewed checkpoints, the object repository, and the idea of record-and-playback testing, we needed a uniform way to write tests. SIFL is what we came up with.

Before I get into the details, let me show you a sample test to give an idea of what we are looking at. This is a quick example that uses the all-too-familiar Mercury Tours web site. We will open the site, navigate to the cruises page and make sure the departure time for the Skagway cruise is 5 pm.

If you are used to seeing QTP code, that should look somewhat – but not entirely – familiar. I’ll go line-by-line to show you what is happening.

BrowserDefault.Navigate "http://newtours.mercuryinteractive.com"

The “BrowserDefault” function returns the current default browser. Because we have not already defined a default browser, it will open a new instance of IE for us and make it the default for future calls to BrowserDefault. The “Navigate” portion of that line is just the browser object’s standard navigate method. This causes the newly opened instance of IE to navigate to the Mercury Tours site.

BrowserDefault.Link("innerText:=Cruises").Click

Here we are calling the default browser again. This time we are clicking a link in the default browser.

Set oTable = BrowserDefault.WebTable("innerText:=Cruise Itinerary.*")

Once again, this is pretty standard. We are just assigning this web table instance to oTable. This step isn’t really necessary, but I wanted to keep the next line short

sDeparture = oTable.GetXWhereYisString("Departure", "Port of Call", "Skagway, Alaska")

Here we are using the SIFL method “GetXWhereYisString”. To put it simply, this gets the data from the “Departure” column in the row where the “Port of Call” column is “Skagway, Alaska”. If everything is kosher on the site, sDeparture should be a string with the value “5 pm”.

assertStringEquals sDeparture, "5 pm"

Here we assert that the string sDeparture equals “5 pm” and note the results in the log. If the assertion is correct, it passes, if not, it fails. Note the fine control we have over the types involved in this homemade "checkpoint". This is what allows us to execute tests across continents without a complicated source tree.

I am writing this on a plane that is about to land, so that's it for now. Expect to see more on SIFL in the next few days along with a link to download it for yourself.

According to Google Analytics, about 36% of you understand the title of this post. For the rest of you, it is Hindi for "We welcome our Indian friends".

Over the past 18 months, there we have had almost as many Indian visitors as US visitors. Considering this is a US site written in English, it amazes me that 7500 people in India have visited us and read 25,000 articles (or at least looked at them). I had heard that there is a lot of software development and testing happening in India, but seeing this many Indian visitors makes it real to me. Also making it real to me are daily phone calls and IMs with three coworkers in Bangalore: Ashok, Sridhar and Shiva. They make up 3/5 of our test automation team.

The top six cities that The Software Inquisition receives visitors from are in India: Bangalore, Chennai, Mumbai, Hyderabad, Delhi and Pune. The first US city on the list is New York at number 7.

I just learned a new trick.

Sandboxie is a freeware application that you can use to run two instances of QuickTest Pro simultaneously. Sandboxie will create a virtual sandbox separated from the rest of the applications on your machine. What happens in the sandbox stays in the sandbox, and what happens outside the sandbox stays outside.

Once you have sandboxie installed, run an instance of QTP in the sandbox and then run another instance outside the sandbox. They won't see each other. Better yet, they won't see each other's browsers, so you can run two tests at the same time without them interfering with each other.

Of course sandboxie wasn't written with QTP in mind. This is just one of many applications for it. Most of you are software testers, and I am sure that software testers can figure out the benefits of segregating a test app from the rest of your machine.

I have been extensively using the method for vbscript optional arguments that I described in March. I want to expand on this a little with some recent changes we have made to how we use this.

Functions that use this method have an aOptions parameter in their signatures. That means, that even if we are not going to specify any optional arguments, we have to pass something, so we pass a Null. The problem is that I end up passing Null most of the time, and I don't like having to do that - especially for our smoke tests where are code is visible to manual testers and developers.

For example, I will use a simple function called WebEditFillByID that simply finds a WebEdit based on it's html id and fills it with the text supplied. There is also an aOptions parameter in its signature, but I don't usually set any options. So, when I am filling out a form it looks something like this.

That doesn't look too bad, but it would be much more legible without the Nulls in the way. So, to get aOptions out of WebEditFillByID's signature I create a new function called WebEditFillByIDAdv that is identical to WebEditFillByID. Directly beneath WebEditFillByIDAdv, I put a second function named WebEditFillByID with the same signature minus the aOptions. All WebEditFillByID does is call WebEditFillByID with the same arguments it was passed and adds a Null for the aOptions in WebEditFillByID's signature.

Now I can fill the same form without the Nulls.

In my opinion, this is much more pleasant to deal with. For reference, here are the new functions.

To read more about named optional arguments in vbscript, see my previous post about it.

This question came up at QAForums recently:

Q: Is it possible to export QTP results to HTML format?

A: Mercury has provided nearly everything you'd ever need to make this happen, and it's highly customizable if you take the time to learn XSLT.

XSLT is a simple technology, used to transform XML documents into other kinds of documents. QTP comes with three XSL files, which transform the Results.xml file into perfectly readable HTML code.

These stylesheets live in the <QTP root>\dat\ folder (on mine, it's C:\Program Files\Mercury Interactive\QuickTest Professional\dat):
PShort.xsl
PDetails.xsl
PSelection.xsl

When the test run report is generated, it's stored in a directory something like this:
<test folder>\Res1\Report\Results.xml

To see it, you have to add the following line below the XML declaration in Results.xml, so it looks like this:

Then view the Results.xml file in IE (which has an XSL engine built into it).

What we do is, we use an external XSLT transformation tool called 'xsltproc' (which comes from the LibXML2 suite at XMLSoft) to generate an HTML file, which we then upload to a server that archives all our test result information. That way nobody needs Mercury's Results Viewer app (that blasted thing takes you through too many clicks to get what you want, and it doesn't remember your filter preferences from one session to the next... GARR!!!!)

This is much better for everyone on my team.

So, it's not difficult, and you have everything you need already. Now if only there were a way to have QTP insert that stylesheet declaration by default into every test...

VBScript is considered to be "object-based", meaning you can use classes, and those classes can have methods and members, but you can't get nearly the kind of re-use and extensibility you could out of a real OOP language. You don't get inheritance, you don't get polymorphism. In short, you get encapsulation, and that's about it. To me that's pretty important, the abilty to wrap up a bunch of common functions and attributes into a single entity called "an object" and throw it around kinda like you would in Java or Ruby. It allows me to create (instantiate) an object in line 10, then count on it being persisted three levels deep and 200 lines later, and never need to look inside the box to find out how it works.

I'll give some code first.

I'm using VBScript classes right now to model our AUT and make the code prettier. For example, if I want to create a user, it looks like this:

This snippet opens a browser, logs in as an administrator, creates a new User object (basically a variable that holds attributes about a user), then uses that data (if I had supplied any) to actually create user from within the GUI. After the user is created and declared "valid", I call the "addRole()" method off of the same user. The User object knows how to fill out all the form fields. It knows how to add a role through the security interface. How? That's the beauty: I don't have to know. Someone else can develop the library of objects and maintain it, and all I have to know how to do is invoke it.

I know, I know, it's the same with functions. Yes, it is. But here they're all wrapped up together. Consider this:

Later, if I want to know the name of that user, I can just ask the object:

Rather than have to code up a function to go and look it up somewhere. It's the persistance of data between states that I'm most interested in. The lack of inheritance and polymorphism is bad, but the most important problems are solved.

Here's the problem: in QTP, you don't just have the limitations of VBScript, you also have some severe limitations built in to (or rather "excluded from") QTP.

The class declaration (in a file called User.vbs) looks like this:

The first limitation:
That last function is there because QTP doesn't have the ability to use classes from external vbs files within the function libraries. You must give the test script access to the above function, which has access to the class, in order for your test script to be able to "see" the class.

The second limitation:
There's a bug in QTP where you can't, no matter what you do, use the debugger to step through class functions. That was almost a showstopper for me when doing this, before I learned just how few of me teammates use the debugger. When I found out I was the only one I decided that for the greater good, OO was a good direction to go in, if for no other reason than to make the code seem more familiar to us non-VBScript types.

So, in short, it's possible for us to get what we need to when we confront OO concepts, but we're severely limited by VBScript as well as Mercury. I'll submit defects on both of these issues, but I'm not sure whether I'd be optimistic about my chances. We seem to be the only ones trying to do this. Let me know if you know different!

HP to Acquire Mercury Interactive Corp

Acquisition positions company as a market leader in IT management software
PALO ALTO, Calif. – July 25, 2006 – HP today announced that it has signed a definitive agreement to purchase Mercury Interactive Corp., a leading IT management software and services company, through a cash tender offer for $52.00 per share, or an enterprise value of approximately $4.5 billion, which is net of existing cash and debt.

Upon closing, the acquisition will establish HP’s portfolio of IT management software and services as the clear choice for companies seeking to optimize the value that IT brings to business.

“Today, we are combining two market-leading businesses to create the most powerful management software portfolio in the industry,” said Mark Hurd, HP chief executive officer and president. ”Together, they will help customers cut their IT costs, speed the delivery of new services and drive profitable growth at HP. We expect this important acquisition to deliver significant value for our shareholders.”

Mercury Chief Executive Officer and President Tony Zingale said, “Together, HP and Mercury instantly become the industry’s premier provider of business technology optimization (BTO) software. A deal of this magnitude creates significant opportunities for our customers, our shareholders, our people and our partners.”

The transaction brings together the strength of HP OpenView systems, network and IT service management software with Mercury’s strength in application management, application delivery, IT governance and service-oriented architecture governance. This combination provides customers with the industry’s most robust suite for optimizing, automating and aligning IT services with business needs.

“HP’s software strategy is to be the clear leader in end-to-end enterprise IT management and help our customers tightly align IT priorities with changing business requirements,” said Thomas E. Hogan, senior vice president, Software, HP. “Combining our HP OpenView offerings with Mercury’s BTO Enterprise offerings will integrate the many building blocks of enterprise IT management into one complete solution for the entire IT lifecycle, from planning through to deployment and operations. Mercury is a results-driven, high-performing company with outstanding people that will be a strong addition to HP.”

The Mercury acquisition is expected to increase the size of the HP Software business to more than $2 billion in annual revenue. Immediately following the close of the transaction, Mercury will become part of the HP Software business and both companies’ sales forces will begin reference-selling each others’ products.

HP forecasts that on a non-GAAP basis, the combined HP Software business will deliver revenue growth of approximately 10 percent to 15 percent and operating margin of approximately 20 percent in fiscal year 2008. On a pro forma basis, the transaction is expected to be approximately $0.04 dilutive to non-GAAP per share earnings in fiscal year 2007 and approximately $0.02 accretive to non-GAAP per share earnings in fiscal 2008. This includes purchase accounting adjustments related to deferred revenue write downs and deferred compensation expense of approximately $141 million, or $0.05 per share, in fiscal 2007 and approximately $43 million, or $0.01 per share, in fiscal 2008, as well as expected synergies.

The acquisition will be conducted by means of a tender offer for all of the outstanding shares of Mercury, followed by merger of Mercury with an HP subsidiary. The tender offer is subject to a number of conditions, including that Mercury has filed its Annual Report on Form 10-K for its fiscal year ended Dec. 31, 2005. HP expects to commence the tender offer promptly and the merger is expected to close in the fourth quarter of calendar year 2006.

Webcasts and conference calls
This afternoon, HP will conduct one webcast and two live audio calls to discuss its intent to acquire Mercury. Mercury will conduct a separate webcast for financial analysts.

HP media call: 4:30 p.m. ET / 1:30 p.m. PT, hosted by Mark Hurd. U.S. dial-in: +1 866 356 3377; International dial-in: +1 617 597 5392, passcode: 36175291. Replay information, available until Aug. 1, 2006: U.S. dial-in: +1 888 286 8010, International dial-in: +1 617 801 6888, passcode: 16464601.

HP conference call and webcast for financial analysts and shareholders: 5 p.m. ET / 2 p.m. PT, hosted by Mark Hurd. Listen only dial-in: U.S. +1 800 299 0148, International dial-in: +1 617 801 9711, passcode: 82591745. Live audio webcast: www.hp.com/hpinfo/investor. Replay information, available until Aug. 1, 2006: U.S.: +1 888 286 8010, International dial-in: +1 617 801 6888, passcode: 55367340.

HP industry analyst call: 6 p.m. ET / 3 p.m. PT, hosted by Thomas Hogan. U.S. dial-in: +1 800 299 8538; International dial-in: +1 617 786 2902, passcode: 83000965. Replay information, available until July 25, 2007: U.S. dial-in: +1 888 286 8010; International dial-in: +1 617 801 6888, passcode: 57320057

Mercury financial analyst webcast for analysts and shareholders: 8:30 p.m. ET / 5:30 p.m. PT, hosted by Tony Zingale; David Murphy, chief financial officer; and, Shelly Schaffer, vice president, Corporate Finance.

U.S. dial-in: +1 800 289 0533; International dial-in: +1 913 981 5525, passcode: 4078554. The webcast link will be available on Mercury’s website: www.mercury.com/ir. The replay will be available via the same link.

Questions about the Mercury call should be directed to Shelly Shaffer at +1 650 603 4592 or Michelle Ahlmann at +1 650 603 5464.

A replay of the Mercury call will be available at +1 719 457 0820 or +1 888 203 1112, passcode: 4078554. Replay will be available shortly following the conclusion of the live call for one year and the dial-in replay will be available until July 31, 2006.

THIS PRESS RELEASE IS FOR INFORMATIONAL PURPOSES ONLY AND IS NOT AN OFFER TO BUY OR THE SOLICITATION OF AN OFFER TO SELL ANY SECURITIES. THE SOLICITATION AND THE OFFER TO BUY SHARES OF MERCURY COMMON STOCK WILL BE MADE ONLY PURSUANT TO AN OFFER TO PURCHASE AND RELATED MATERIALS THAT HP INTENDS TO FILE WITH THE SECURITIES AND EXCHANGE COMMISSION. MERCURY STOCKHOLDERS AND OTHER INVESTORS SHOULD READ THESE MATERIALS CAREFULLY BECAUSE THEY CONTAIN IMPORTANT INFORMATION, INCLUDING THE TERMS AND CONDITIONS OF THE OFFER. ONCE FILED, MERCURY STOCKHOLDERS AND OTHER INVESTORS WILL BE ABLE TO OBTAIN COPIES OF THE TENDER OFFER STATEMENT ON SCHEDULE ‘TO,’ THE OFFER TO PURCHASE AND RELATED DOCUMENTS WITHOUT CHARGE FROM THE SECURITIES AND EXCHANGE COMMISSION THROUGH THE COMMISSION’S WEBSITE AT WWW.SEC.GOV. MERCURY STOCKHOLDERS AND OTHER INVESTORS ALSO WILL BE ABLE TO OBTAIN COPIES OF THESE DOCUMENTS, WITHOUT CHARGE, FROM INNISFREE M&A INCORPORATED, THE INFORMATION AGENT FOR THE OFFER, AT +1 877 750 5838 OR BY EMAIL AT INFO@INNISFREEMA.COM, FROM MERRILL LYNCH & CO., THE DEALER MANAGER FOR THE OFFER, AT +1 877 653 2948, OR FROM HP. STOCKHOLDERS AND OTHER INVESTORS ARE URGED TO READ CAREFULLY THOSE MATERIALS PRIOR TO MAKING ANY DECISIONS WITH RESPECT TO THE OFFER.

About Mercury
Mercury, the global leader in business technology optimization (BTO), is committed to helping customers optimize the business value of information technology. Founded in 1989, Mercury conducts business worldwide and is one of the fastest growing enterprise software companies today. It provides software and services to govern the priorities, people, and processes of IT; deliver and manage applications; and integrate IT strategy and execution. Customers worldwide rely on Mercury offerings to improve quality and performance of applications and manage IT costs, risks and compliance. Mercury BTO offerings are complemented by technologies and services from global business partners. For more information, please visit www.mercury.com.

About HP
HP is a technology solutions provider to consumers, businesses and institutions globally. The company’s offerings span IT infrastructure, global services, business and home computing, and imaging and printing. For the four fiscal quarters ended April 30, 2006, HP revenue totaled $88.9 billion. More information about HP (NYSE, Nasdaq: HPQ) is available at www.hp.com.

Note to editors: HP news releases are available via RSS feed at www.hp.com/hpinfo/rss.html.

###

Forward-looking statements
This news release contains forward-looking statements that involve risks, uncertainties and assumptions. If such risks or uncertainties materialize or such assumptions prove incorrect, the results of HP and its consolidated subsidiaries could differ materially from those expressed or implied by such forward-looking statements and assumptions. All statements other than statements of historical fact are statements that could be deemed forward-looking statements, including the expected benefits and costs of the transaction; management plans relating to the transaction; the anticipated timing of filings and approvals relating to the acquisition; the expected timing of the completion of the transaction; the ability to complete the transaction considering the various closing conditions, including those conditions related to antitrust regulations; any projections of earnings, revenues, synergies, accretion, margins or other financial items; any statements of the plans, strategies and objectives of management for future operations, including the execution of integration plans; any statements of expectation or belief; and any statements of assumptions underlying any of the foregoing. Risks, uncertainties and assumptions include the possibility that expected benefits may not materialize as expected; risks related to the timing or ultimate completion of the transaction; that, prior to the completion of the transaction, Mercury’s business may not perform as expected due to uncertainty; that the parties are unable to successfully implement integration strategies; and other risks that are described from time to time in HP’s and Mercury’s Securities and Exchange Commission reports, including but not limited to the risks described in HP’s Quarterly Report on Form 10-Q for the fiscal quarter ended April 30, 2006 and other reports filed after HP’s Annual Report on Form 10-K for the fiscal year ended October 31, 2005 and Mercury’s Annual Report on Form 10-K/A for the fiscal year ended December 31, 2004. HP assumes no obligation and does not intend to update these forward-looking statements.

© 2006 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. The only warranties for HP products and services are set forth in the express warranty statements accompanying such products and services. Nothing herein should be construed as constituting an additional warranty. HP shall not be liable for technical or editorial errors or omissions contained herein.

7/2006

Editorial Contacts
Robert Sherbin
HP
+1 650 857 2381
robert.sherbin@hp.com

Ryan J. Donovan
HP
+1 650 857 8410
ryan.j.donovan@hp.com

Mike Moeller
HP
+1 650 236 3028
michael.moeller@hp.com

HP Media Hotline
www.hp.com/go/newsroom
+1 866 266 7272
pr@hp.com

Jeff posted a comment about my implication that we have integrated QuickTest Pro into our build processes. I thought I'd elaborate on that a little.

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:

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.

The company we work for is rewriting one of the web products for the next version, and we have taken the opportunity to request a few changes that will help us write automated tests. Chief among the changes is the inclusion of the ID attribute in every significant html tag - some of the insignificant tags like br and hr are exempt. Now that the development process is under way, we are seeing some results. Having a reliable ID attribute makes all the difference we imagined for writing QuickTest tests.

All this is to say that, if you only get one request of the development process, I recommend that you request the developers follow a standard for giving every html tag an ID attribute.

The changes to the management of the Object Repository are among the most significant in the new version, and though I haven't been through enough with the product to have a comprehensive opinion, I wanted to post my initial thoughts, and to invite comments from anyone whose experience is similar or different.

First off, let me say that on our team, where possible, we use programmatic descriptions. We minimize our interaction with the OR because we find that this is usually the first area that breaks when something changes in the interface. But we still do use the OR, and we rely on having an easy way to interact with it. I'm happy to report that they have made improvements in version 9, but there are still cases where they didn't go far enough.

The Set Up

In the description below, I opened a new test and associated my AUT's shared repository with the default action. My first inclination was to remove the association between the action's default Local Repository, but then I found that you can't remove the association. In an initial fit of consternation I talked it over with Will, and he was happy about the new behavior.

The Team-Oriented Object Repository

The local vs shared OR is their solution for how to make a team repository easier to manage: during test development, you have read-only access to the objects currently in the repository, but new objects are added to the local repository for that action. At some point later, one test developer goes back in and merges all the objects that should be shared, and either trims the rest from the local, or leaves them there if there's no chance of them being used outside that action.

I'm undecided about this method, but I understand why they've done it. One thing is for sure: this beats the heck out of trying to run the external merge tool every few days, not having any idea when new objects are being created, and all the other stuff we had to do in 8.2 to get it working.

The New Object Repository Interface

When you open the new Object Repository, the first thing you'll notice (besides the fact that it now takes about 5 seconds on my machine, as opposed to less than half a second for version 8.2), is the tree view on the left and the properties frame on the right. Further, the default size for the OR is more like what you'd expect: with the hierarchy collapsed to 3-deep, you can really see things well. The frame is big, and you probably don't have to scroll around much. When you click on an object, the properties frame on the right automatically refreshes to show the selected object's properties.

You'll further notice that the tree is mostly grayed out - that's the shared repository in read-only mode. Local objects are read-write, and any new objects you add go into that. The nice thing about this is how the trees merge seamlessly - if you're adding a new WebElement under a particular browser/page object, one that exists in the shared OR, its hierarchy is copied into the local rep so that it looks like your new WebElement is actually under the same parent as all the other WebElements on that page. This allows you to view the OR the way you always have, and since the files are separated, you won't be stepping on someone else's code, forcing a merge.

Here's the BIG problem with the interface: For the read-only objects (in the shared OR), you can't get extended attribute properties. You can't view them at all. The only properties you can see are the Description Properties, used to identify the object, the Ordinal Identifier, and whatever Additional Details you have turned on with Smart Identification for that object type. Now, I believe 8.2 worked in the same way if you were working with a read-only repository, but since that's the rule now and not the exception (on our team, anyway), it becomes tiresome to go through the steps necessary to view the additional details.

This probably wouldn't gall me so much if I didn't see all that space below the properties that are listed... space where they could have put reams and reams of information, separating TO Properties and Method calls, allowing you to view anything and everything at will. It's a missed opportunity to put all that good information right there on the page.

So what do you have to do to see the properties? Well, you have two options, one easy, one hard. The easy one is this: select the object whose properties you want to view, then click ObjectsCopy to Local from the menu bar (there's no hot key), then click the plus + sign in the Properties frame... this will allow you to CRUD all the TO properties. The side effect of this is that, if you end up making a change to the object, the change will only be made in your local repository, and will not be carried back to the shared OR.

The other option is to open up the Object Manager, a standalone app that allows you to merge ORs, edit properties, reparent, etc., independently from the main QTP interface. I'll be doing a separate write-up about the new OM, because though it's similar to the OR editor, it has its own set of features, annoyances, and tricky behaviors.

Locate in Repository - the Coolest New Feature

This is the coolest thing in the new OR - the ability to click on an object in the AUT, and have it highlighted in the OR. Was it just me, or did everyone else spend an awful lot of time searching for objects in the OR, navingating through trees and trees of crap, when the object on the page was just sitting there laughing at you? Now you click the "Locate in Repository" button, click on the object in the AUT, and it goes right there - if it can find it. It's a safe bet that if QTP can locate the object during a test run, it can locate it in an OR. It doesn't always work, but it's better than the nothing we had before.

Update from Application

Another cool feature: Select an object in the OR hierarchy, then click on its counterpart in the AUT, and its properties will be updated from the AUT. This is useful for when something is out of date, but I can see it being a pain if a whole page's worth of objects has changed and you have to update them all one-by-one. I don't know if there's an effecient way out of this yet, but it's possible that I've missed it. At any rate, I like the fact that it's there.

...and the Bad

They didn't put the "Locate in Application", "Copy to Local", "Highlight in Application", or any of the other object-specific functions in the right-click menu when these objects are highlighted... and it makes me want to scream. There are no appreciable hot keys, no ways to make management of these things more efficient, and you end up getting just about as frustrated as you did in version 8.2.