Once again, another great feature request from one our users is being integrated into the next release of Test Design Studio!

Test Design Studio features extensive support for outlining the various code elements of your file so that you can collapse areas that you do not want to focus on at the time.  The ‘Toggle Outlining Expansion’ command is what you use to expand/collapse the node closest to the caret position.  But what about when you want to toggle a lot of nodes at once?

Previously, the only other option was ‘Toggle All Outlining’ that worked on the whole document.  We have now expanded the functionality of the ‘Toggle Outlining Expansion’ command to support a selected range.

If you have not selected any text in the editor, the command functions just like it always did before.  If you have selected a text range, all the nodes that are fully encompassed in the text range will either be expanded or collapsed.  Since you are dealing with multiple outlined regions that could be in different expand/collapse states, the first encountered node in the region will determine if the other nodes are expanded or collapsed.  So if the first node in the range is currently expanded, all nodes will be toggled to the collapsed state.

This subtle enhancement should make it that much easier to use outlining in Test Design Studio and further improve your productivity.

We are happy to provide another feature request in our next release of Test Design Studio.  This feature, while simple, is very useful.  When you press the ‘SPACE’ key after typing the ‘Call’ keyword, a member list will be displayed showing just the available methods that are accessible for you to call.  This can make it easier to find what you’re looking for without displaying a full member list and ignoring all the irrelevant items like variables and keywords that are not valid in that context.


Note: This special feature is only available when you press the ‘SPACE’ key after the ‘Call’ method and will not be displayed if you use the standard options for showing a member list.

This feature is primarily targeted for use with Enumerations (a.k.a. Enum), but everything you see below will also work with Boolean values since it, too, has a pre-defined list of values (i.e. True or False).  Support for Enum’s is something unique to Test Design Studio that you cannot find in QuickTest® Professional!

NOTE: This feature will be available in the next build of Test Design Studio

We have always supported the ability to setup the parameters of a method with an Enum list so that, when typing the arguments for your method call, you would be presented with a member list of available values for that parameter based on the associated Enum.  We are happy to report that this option is now available when performing an assignment operation or equality comparison.

In the screen shot below, you can see an example of this feature.  At the top of our script, we have defined an Enum for a series of strings called “Color”.  Later, we declare a variable and use the XML comments to designate that this variable is expected to hold the values of the “Color” Enum instead of being treated as a normal string.

With this configuration in place, the Member List of available values is immediately displayed when you press "Space" after an "Equals" sign.  You can also manually display the Member List (i.e. “CTRL+SPACE” for the Complete Word operation) of available values to assign to this variable.  This feature can help ensure you are assigning the appropriate values.


The same feature is available when using the equals sign to do an equality comparison instead of assignment as shown below:


If you do not want to see the Enum-specific Member List, simply repeat the “CTRL+SPACE” shortcut command to toggle between the default Member List and the Enum-specific Member List.

Defining and using Enums is a feature unique to Test Design Studio that can easily help you ensure you are using data correctly.  If you are not already using them, now is a great time to take a second look at the feature.

You can find more details about how to define an Enum in our on-line help.

This feature comes to you courtesy of a request from a user!  We always strive to incorporate the features that are important to the users of our product, so we encourage you to keep those feature requests coming.  All ideas are welcome!  This feature was incorporated and made available to the user in less than 24 hours from receiving the request.  We cannot promise that all features can be added or that you will have the same turnaround, but we hope you take this example as an indicator that we are serious about keeping our users happy.  When is the last time you remember getting support like that from a software company!? Smile

How you manage your QuickTest® Pro test assets will have a significant impact on the success of your project.  We put together a white paper that discusses project management using either QC/ALM or the standard Windows® file system.  We also go on to show you how Test Design Studio builds on these techniques to provide a superior experience.

These techniques are valuable to anyone working with QuickTest® Pro, and not just Test Design Studio customers.  We hope you enjoy the white paper and will share with your colleagues.

The white paper can be downloaded here.

Test Design Studio does a lot that QuickTest® Professional does not!  There are, however, a few elusive items that Test Design Studio does not (or cannot) do.  You can view a feature comparison here.  One of the biggest reasons for the lack of support has to do with how the QuickTest® Professional API is constructed.


Problems with the QuickTest® Professional API

A QTP test contains a lot of different data.  Some of this data is easily viewable through standard text-based files, but a lot of it is locked up in binary files.  These files, unfortunately, cannot be read without a proper interface, and that is where the QuickTest® Professional API comes in.  The API allows you to read test properties, modify test resources, and other similar actions.  The problem is that QTP was designed to only allow one test to be opened at a time.

So why is this a problem?  Consider this scenario.

You have a test open in QTP that you are actively editing.  At the same time, you have a different test open in Test Design Studio.  If you want to do anything with your test in Test Design Studio that requires the API, the following must happen:

  1. Test Design Studio invokes a new instance of the QTP automation object.  This does not create a new instance of QTP, however, since you cannot launch multiple sessions of QTP.  Instead, it allows you to access and control the currently running instance.
  2. The test that you are currently working on in QTP must be closed so that the test you need from Test Design Studio can be opened.  You cannot access the details of a QTP test without having it opened in the application.
  3. If the active test has been modified, you must save your changes before closing.  If you were not done performing your edits, this places the test in a potentially corrupt state (e.g. syntax errors, incomplete code, incomplete logic).
  4. Once the test is open in QTP, Test Design Studio can finally read the details of the test.


As you can see, this process is very intrusive to the end user and makes it impossible for Test Design Studio to silently load data “behind the scenes” for a test.


Problems with QuickTest® Professional Actions

Test Design Studio includes basic support for existing Actions in a QuickTest® Professional test.  This includes the ability to view the action code and make changes as necessary.  What Test Design Studio cannot do is modify an Action or allow you to insert calls to new Actions that are not already part of the test.

Test Design Studio is essentially the equivalent of the ‘Expert View’ in QTP (although much more powerful and feature-rich).  The following statement from the QTP v11 Help File regarding the “RunAction” statement explains the problem (emphasis added):

The RunAction statement can run only actions that are already associated with your test as part of the test flow. Therefore, in order to enter a RunAction statement in the Expert View for an external action, you must first insert a call to the action (Insert > Call to Action) or copy the external action (Insert > Copy of Action) into your test. Using this option associates the action with the testand also inserts a RunAction statement for you. After the external action is added to the test flow, you can add additional calls to that external action in the Expert View.

If you insert a RunAction statement in the Expert View for an external action that is not already associated with your test as a part of the test flow, the RunAction statement fails. For more information on copying or calling external actions, see the HP QuickTest Professional User Guide.

The key information to gain from that excerpt is that an Action must be associated with a QTP testin order for it to be called properly.  The only way for Test Design Studio to associate an Action with a QTP test is using the QTP API, and those problems have already been noted.

NOTE: The limitations surrounding actions are why I (and many others in the industry) prefer using function libraries instead of Actions.  Function libraries solve many of the same problems that Actions address, and are much easier to manipulate outside of QTP.  In essence, Actions are largely just a “keyword view” equivalent of a function call.


The Tandem Solution

The solution to this issue is that you must use QuickTest® Professional in tandem with Test Design Studio for certain functionality.  Many aspects of Test Design Studio were designed to work without the need for QTP to even be installed (thus a potential for saving money on QTP licenses), but some actions will simply require that QTP be available due to the need for the API.

Since we cannot live without QTP, we decided to make it as easy as possible to work with it.  Test Design Studio offers two commands that makes this tandem solution work; “Open in QuickTest” and “Open Active QuickTest File”.

‘Open in QuickTest’ Command

This command is simple, yet very useful.  It takes the file you are currently working with in Test Design Studio (QTP Test or Scripted BPT Component) and opens the same file in QTP.  While opening, it also ensures that QTP is launched with the proper add-ins for your file.  If it is not, Test Design Studio will re-launch QTP and select the corresponding add-ins for you.  Test Design Studio will even make sure you are properly connected to the corresponding Quality Center or Application Lifecycle Management server.  In other words, Test Design Studio does all the heavy lifting to make the process as quick and painless as possible.

You can access this command in two ways… either right-click on the document tab for your file and select ‘Open in QuickTest’, or you can right-click the corresponding file in the ‘Solution Explorer’ tool window and select ‘Open in QuickTest’.

image    image

This command is especially useful when you need to perform an action on your file that is only available from QTP.  For example:

  • Modify test/action parameters
  • Insert a new action
  • Call an existing action
  • Modify test flow


When you are done, you simply save your changes and return to Test Design Studio where you will be prompted to re-load the file.

‘Open Active QuickTest File’ Command

This command is accessed from the ‘File –> Open’ menu in Test Design Studio.


The purpose for this command is the opposite of what is done with the ‘Open in QuickTest’ command.  It will use the QTP API to determine the test you currently have open, and the same file will then be opened within Test Design Studio.

This command is useful for when you want to use the powerful editing capabilities of Test Design Studio instead of the basic editing experience you get from the ‘Export View’ in QTP.  When you have finished making changes in Test Design Studio, you simply need to save your file in Test Design Studio and then re-open the file in QTP.

NOTE: QTP does not notify you when a file has been modified outside of the QTP IDE, so you have to remember re-load your test.  Test Design Studio, of course, does notify you when a file has been modified.


Use Case Scenario

Let’s describe a scenario that would require tandem use of Test Design Studio and QuickTest® Professional.  Imagine you currently have a QTP test open, and you need to add a call to a new action.  Since Test Design Studio does not provide the feature, you need to use QTP.  The steps would be as follows:

  1. Save your test in Test Design Studio so that all changes are committed.
  2. Right-click the document tab for your test (or corresponding file in ‘Solution Explorer’) and select the ‘Open in QuickTest’ command.
  3. Switch to the QTP application
  4. Perform the necessary steps in QTP to add your new action
  5. Save the test in QTP
  6. Switch back to Test Design Studio
  7. You will be prompted to load the modified test, so select ‘Yes’.


With those basic steps, you can easily use Test Design Studio to gain the powerful features it offers while still working with QuickTest® Professional when necessary.  It may look like a lot of steps, but the process is pretty straight-forward and will become familiar as you use it.


Why Not Add Direct API Support in Test Design Studio?

The answer is pretty simple.  For starters, you must have the QTP API available to make changes like this, so that means you already have QTP installed on your system.  We would then have to duplicate all the GUI aspects of QTP within Test Design Studio while still supporting multiple versions of QTP.  Even if we did use the API, we would still have to open the test in QTP (and interrupt the current session) just to make those changes.

Since QTP is available and the test will have to be opened in QTP anyway, it is much easier to use the familiar (and version-specific) GUI of QTP to perform those actions instead of duplicating the logic in Test Design Studio.  If the QTP API ever allows us to interact with files without having to take control of the running QTP instance, then we will consider providing the built-in functionality.

Do you think it is time for QTP to die?  Paul Hammant posted on his blog that he thinks so.  He makes some good points, but I disagree.

His first point discusses developers not using the tool.  In my experience, most developers have rejected the tool when offered or failed to use it once it was delivered.  Not because it was too expensive (concurrent licensing can ease the installation burden), but because they did not want to take the time to automate their tests.  Even in this modern day, many development shops still are not writing unit tests!  In the ideal world, all applications would have undergone a battery of automated tests before turning over the project to a testing team, but that is not the world most of us live in.

His second point discusses new lightweight testing tools that are either free or come at a low-cost.  The terms “free” and “low-cost” should not be taken lightly, as the cost to actually implement and use a tool is never free!  You have to be trained on the tool, gain experience on how it is used, and troubleshoot software issues with the tool itself.  Some of these tools are not actively supported or lack a lot of the training material to get testers up to speed quickly.  One of the biggest benefits to QTP is that you have “one tool to rule them all”.  A single tool to handle testing a variety of technologies should not be underestimated.  Sure, it may take a little time to adjust to testing a WPF-based application in QTP if you’ve only ever tested web-based applications, but at least you maintain the familiarity with the base tool and underlying automation concepts.

The remainder of his article primarily focuses on the growing support of Selenium.  I have not personally used Selenium and have only recently looked at the product, but my initial thoughts were far from positive.  The first webinar I attended about the technology did more to talk about what Selenium cannot do instead of what it is capable of.  I have since attended additional webinars on the tool, and have yet to see a good presentation on how you implement this technology.  Perhaps I have been spoiled by the IDE that QTP provides or the tight integration with Quality Center / ALM.  To gain anything close to the QTP/QC/ALM combo, you have to start purchasing additional, 3rd-party tools.  In the end, remember that investing in Selenium is also an investment in a single technology for web-based testing.  If you ever need to automate .NET or Win32 applications, you will have to seek out, learn, and implement an entirely new technology.

Does QTP have it’s faults?  Of course it does!  The whole reason we initially developed Test Design Studio was to cover some of those faults.  The fact remains, however, that QTP (even with it’s flaws) is a far more robust and mature product than any of the “free” or “low-cost” tools we see on the market today.  Combine that with Test Design Studio, and you have a winning combination!

What do you think?  Feel free to post your thoughts in the comments.

The next release of Test Design Studio 2.0 will include a new feature to perform file locking in Quality Center / ALM.  When you open a test, attachment, resource, or BPT component for editing, Test Design Studio will attempt to acquire a lock on that file.  If the file is already locked by another user (either through Test Design Studio or tools like QuickTest), you will be notified that the file is locked.  At that time, the file will open in read-only mode.

This new feature should help teams collaborate without impacting the work of someone else.  If you prefer to disable the locking feature, you may do so using Test Design Studio options.  Select ‘Tools –> Options’ from the main menu, then expand the path for ‘HP –> Quality Center’.  Here you will find the option to enable/disable file locking.

We hope you enjoy this new feature coming in build 2.0.4571.

[Update] The new release of Test Design Studio 2.0.4572 is now available and includes this new feature.