Welcome to the Patterson Consulting Blog

Test Design Studio Updates to Build Process

Sat, 05 May 2012 14:41:51 GMT

We have just posted a new release of Test Design Studio, and it is available for download.

The most notable additions to this release are related to the build process. For those who may not be familiar with this feature, the build process allows Test Design Studio to perform routine tasks associated with the collection of files in your project.

A Little Background on Build

Perhaps the most important of the build tasks is the ability to update your QuickTest tests. QuickTest does not have a centralized approach to test configurations unless you use Business Process Testing. Each test is a self-contained entity requiring its own configuration. This is great if you write tests in isolation, but most users typically create a suite of many tests for a given application. Shared resources such as function libraries and object repositories are used by most (if not all) of those tests. When you add a new library or object repository to your shared resource pool, you must update each test to add this new resource. That process is time-consuming and easy to overlook.

The Test Design Studio build process changes that! Test Design Studio already has an excellent project-centric approach to test management, and keeping your tests updated is as easy as running the build process. Once initiated, Test Design Studio looks at all the tests in your project as well as all the shared resources. Each test is then opened in QuickTest through their API, object repositories are associated with each action, and function libraries are associated with each test. Test Design Studio even makes sure you have the proper add-ins set.

When I develop automated tests, I place most of my functionality in reusable function libraries. I keep libraries small and each one focuses on specific aspects of the application. This keeps my code organized and easy to manage, but can easily create 10 to 20 function libraries. Managing that many individual files would be cumbersome without Test Design Studio. When I need a new test, my actions are simple:

Add the test to my project using the ‘Add New Item’ command and selecting my QuickTest file template
Right-click the file in Solution Explorer and select ‘Build’

That’s it! My new test is immediately configured with all the function libraries and object repositories that are defined for my project. When I need to add a new function library to my projects, the process is equally simple:

Add the library to my project using the ‘Add New Item’ command and selecting library file template
Right-click the project in Solution Explorer and select ‘Build’

Just like that, Test Design Studio will process all of my tests to make sure they reference the new library.

What Changed in New Release

The build process is key to increasing your productivity and working in conjunction with QuickTest. One of our newer customers recently posted a series of suggestions for improving the build process, and we were pleased to make those enhancements (you know how you are, and thank you!).

Hint: If you have an idea on how to improve Test Design Studio, it’s a great idea to share it!

Test Left Open after Build

If you initiate the build process for a single test, Test Design Studio will now leave that test open in QuickTest after the build is complete. This is a great time-saver when actively writing and debugging a test since you can essentially use the ‘Build’ command to open the test in QuickTest (something always available off the context menu) but also ensure that all resources are properly associated to the test.

Version Control Improved

We made many adjustments to how version controlled tests are managed. A test must be checked out in order to modify it, so the build process will check out any test that was not already checked out. If no changes were necessary from the build, that check-out will be cancelled. When the test is modified, it will be checked back in only if the test was not already checked out. Those tests that were already checked out before initiating the build will remain checked out afterwards.

Keeping a test checked out proved to be a complex task due to an issue with the QuickTest API. If you save a version-controlled test and try to close it without checking it in, QuickTest displays a prompt asking if you want to check it in. It even does this if you are using the API, and that dialog was blocking the build process while waiting for user input. Even worse, the dialog displayed by QuickTest was often not visible on the desktop giving the illusion that Test Design Studio had stopped responding. To keep the build process operating smoothly, we actually had to use GUI automation to detect and dismiss that dialog when displayed.

Build Selected Command Updated

The ‘Build Selected’ command was originally designed to build the selected item in the Solution Explorer tool window. For those that do not have the Solution Explorer track the currently selected document, this caused some confusion. If you had one test selected in Solution Explorer but were actively editing a different test in an editor, the ‘Build Selected’ command would build the test in Solution Explorer instead of your current document. That has now changed. The command will only process the selection from Solution Explorer if that tool window is selected when activating the command. Otherwise, it will attempt to process the actively edited document.

Summary

For those not familiar with the build process, we hope you integrate it into your project management process. For those already using it, we hope you enjoy these enhancements. Thank you again to the customer who brought these suggestions to us, and keep that feedback coming! We all benefit from the ideas of others.

Test Design Studio 3: Member List Enhancements

Mon, 16 Apr 2012 18:34:21 GMT

While the majority of the work going into the Test Design Studio 3 (TDS3) rewrite has focused on reorganizing and updating the base code, we are still bringing some new features and usability enhancements. One such area getting an update is the standard IntelliSense® member list. This is the list that offers suggestions for language elements as you type.

In TDS 2.0 and prior releases, the member list would automatically highlight the item in the list that started with the text you were typing. So if you typed “date”, your member list might look like the following in TDS 2.0:

This works great if the member you are looking for starts with the word “Date” like “DateAdd”, “DateDiff”, etc. This technique, however, is not useful for finding other date-related functions like “FormatDateTime” where the matching text is not at the beginning of the term.

With TDS3, your member list might look like this:

This list shows you exactly what you are looking for! It includes all the known functions that include the text “date”. In particular, we can discover the functions “CDate”, “FormatDateTime”, and “IsDate” that were not easily found in the old-style member list. The list even highlights the search term within the list so you can easily determine why that item is being matched. The list also auto-filters to the matched entries, so you no longer see the entries that are not a match.

This enhancement will make it that much easier for you to find exactly what you need in the member list. This new member list does not stop there… you can also match items based on partial matches. For example, if you were searching for “DateDiff”, you could use a shorthand notation of “dd” (e.g. each capital letter in the name) to return the function as well.

This list automatically matches on “DateDiff” because of the use of capital letters in the name, but you will also see that it matches on “DateAdd” because it also contained the two “d” characters.

While it may not seem like much, these little changes can have a big impact on your ability to discover what you need and increase your efficiency while writing code.

Test Design Studio 3: Document Navigation Updates

Mon, 16 Apr 2012 18:34:01 GMT

One of the new features in the upcoming Test Design Studio 3 release include some updates to how you navigate documents. Below is a screen shot of a class library for interacting with the Windows® Calculator application (click the image for larger resolution screen shot if desired):

This is a simple class with multiple methods and a property. Before going any further into what TDS 3 will offer, let’s take a look at the equivalent functionality in TDS 2. Below is the Navigation Bar you see in TDS 2:

This allows you to see a drop-down list of “containers” on the left (e.g. a VBScript class), and the drop-list on the right shows the items that are in that container (e.g. a list of class members). This list was effective, but only offered two techniques for grouping items. In TDS 3, these two drop-down lists have been replaced by a single “breadcrumb” style navigation control where every point in the hierarchy of the language element is displayed.

This new control allows us to display three elements at the same time: the root element (e.g. the VBScript code document), the container element (e.g. the ‘Calculator’ class), and the current member (e.g. the ‘PerformBinaryOperation’ function). When QuickTest® Pro script support is added, you may see a new level to allow you to switch between Actions in the script. The drop-down arrow next to each element allows you to jump to a different part of the document.

As you move the caret through your document, the Navigation Bar updates to show the current location in the document. You may also notice that we have added the parameter signature to any invocation members of the class (i.e. ‘Sub’, ‘Function’ and ‘Property’). Having this data readily available in the Navigation Bar can help keep track of which parameters are passed in as you work on the body of that code element.

While the Navigation Bar is very convenient for jumping to specific code elements in your document or keeping track of your current location, it is still a flat view of your document that makes it difficult to see all the available code elements at the same time. That is why we have introduced a brand new tool window called ‘Document Outline’!

This tool window allows you to see the full hierarchy of your document, all in a single view! Just like the Navigation Bar, the current selection will always be updated based on the position of your caret in the document. You can also double-click an item in the Document Outline to jump to that part of the code.

We believe these subtle enhancements will make you even more efficient when using Test Design Studio.

Sneak Peak: Workflow Editor

Mon, 16 Apr 2012 18:32:42 GMT

We have spent the last couple of weeks putting together a tool for editing Workflow scripts used with Application Lifecycle Management 11 (ALM). This is the latest release of the Quality Center product line. Test Design Studio has long had the ability to open and edit workflow scripts, but this process involved exploiting a security hole that was plugged by default. In the past, there was simply no supported way to download and upload the workflow script files.

That has finally changed with ALM 11!

Beginning with ALM 11 Patch 1, a feature was added to ALM 11 that enables an FTP server which can be used to browse files in the repository of a project. Using standard FTP protocol, users with the right permissions can upload and download files… including workflow scripts! Now that there is a supported way to handle these files, we can finally bring a product to the community that will improve the experience of editing those scripts.

Introducing Workflow Editor…

If the interface looks familiar, it should. Workflow Editor is being built on the same engine as Test Design Studio 3. We have taken a “pluggable” approach to how we are developing our next version of Test Design Studio, and that has allowed us to utilize the same code base to bring up a new tool with a specific focus. The best news is that any improvements we make to Test Design Studio will be available in Workflow Editor without additional effort, and the opposite will be true as well. In fact, we are using Workflow Editor to advance our development of Test Design Studio 3. This provides us with a less-complex tool to refine the VBScript parsing engine and IntelliSense as well as other common UI design challenges.

Best of all, we plan to make this tool FREE TO THE COMMUNITY!!

The screen shot above is an early preview that is likely to change (especially the Ribbon interface), but we hope to start making Workflow Editor available soon. Stay tuned to this blog or follow us on Twitter (@PattConsulting) to keep informed about availability. We look forward to sharing this tool and hearing your feedback.

Test Design Studio Reveals Errors in QuickTest's "Web_Services.txt" File

Thu, 22 Mar 2012 00:50:45 GMT

How safe do you feel knowing your code passes a syntax check?

Keeping reading and you might change your mind.

We have talked at length about having correct syntax does not mean your code is correct. Sure, we start with getting the syntax correct, but we must also follow the rules of the language.

The ability to create functions and return values is one of the greatest tools available to a programmer! VBScript, unfortunately, does not use a simple statement such as “return” to signify the return value (as is common in “C”-style languages). Instead, it makes you repeat the name of the function in a syntax similar to assigning a value to a variable. This works great, of course… provided you type the name correctly!

While working on support for the Web Services add-in for the next release of Test Design Studio, we opened the “Web_Services.txt” file that ships with QuickTest to ensure that the user-defined functions were being properly registered to the “WebService” object. That is when we found the issue below:

Do you see what’s wrong? Test Design Studio makes it pretty obvious that the author of this file mistyped the name of the function when trying to set the return value. What should have been “GetHeaders” was typed as “GetHeader”. Test Design Studio saw two potential problems here:

“GetHeader” (since it does not match the name of the function) is the same as a reference to a variable. This file has Option Explicit turned on, and a variable named “GetHeader” does not exist. Test Design Studio will not let you use an undeclared variable when Option Explicit is enabled.
Functions, by definition, are meant to return values. This function declaration does not (due to the mistyped name). Test Design Studio warns you that you might have forgotten to return a value.

This error means that anyone attempting to use the “GetHeaders” function attached to the “WebServices” object is either going to get a run-time error or, even worse, never get the object they were trying to retrieve.

Sadly, that’s not the only error Test Design Studio caught. Elsewhere in the same file was this code:

Again, Test Design Studio makes it obvious that there is a problem here! The code author misspelled the parameter name in the function declaration, which made the reference to the parameter (using the proper spelling) inaccurate. Test Design Studio gave the following reports:

The code attempted to use an undeclared variable “XMLSchemaFile” (Option Explicit turned on). Since the name did not match the parameter, it was expecting the name to be defined elsewhere.
A warning was given that the user declared the parameter “XMLScheamFile” and never actually used it.

This function, as defined, would never properly validate the XML Schema file.

Had the author of this code been using Test Design Studio and the powerful code analysis features, neither of these mistakes would have been distributed to thousands of HP customers! Keep in mind that the syntax of this file was 100% accurate even though the file had multiple errors.

So I ask again… how safe do you feel that syntax checking is enough to verify your code?

To learn more about the Code Analysis features of Test Design Studio, check out our page on Code Quality. You may also want to download our Data Sheet.

The two major flaws in this code were caused by 3 simple characters. What might you have missed in your code?

Note: This file was analyzed from the general release of QuickTest v11.0. I have not verified if the issues have been corrected in any patched release. What to check your file? The default location is “C:\Program Files\HP\QuickTest Professional\data\BPT_Resources”. You may also find the file automatically added to your Quality Center/ALM projects in the Resources module.

New Feature: Delphi Test Object Support

Sun, 11 Mar 2012 16:44:20 GMT

We are happy to announce that the next release of Test Design Studio will add support for Delphi test objects! Support for QuickTest test objects like those in the Delphi add-in are just one of the features that give Test Design Studio an advantage over standard VBScript editors like Notepad++. Many VBScript-based editors can provide support for standard VBScript language elements, but only Test Design Studio adds support specifically for objects that are unique to QuickTest!

The added capability will bring IntelliSense to the collection of objects associated with this add-in, including: DelphiButton, DelphiCheckBox, DelphiComboBox, DelphiEdit, DelphiEditor, DelphiList, DelphiListView, DelphiNavigator, DelphiObject, DelphiRadioButton, DelphiScrollBar, DelphiSpin, DelphiStatic, DelphiStatusBar, DelphiTable, DelphiTabStrip, DelphiTreeView, and DelphiWindow.

This addition means that Test Design Studio now has full IntelliSense for all of the following add-ins:

Standard Windows (i.e. Win32)
Web
ActiveX
.NET
WPF
Silverlight
Visual Basic
Java
Terminal Emulator
Delphi

If there is another add-in you are interested in that is not listed here, please e-mail our support team so we can get it added for you!

New Feature: Additional Fonts and Colors

Thu, 09 Feb 2012 22:58:05 GMT

Test Design Studio has long offered the ability to modify the fonts and colors used by the editing control. This is done by selecting ‘Tools –> Options’ from the main menu, expanding the ‘Environment’ node and selecting ‘Fonts and Colors’.

Until now, however, there was never a way to change the background of the text editor from the system default settings provided by the Windows theme in use. Many users have requested the ability to create a “dark” editing environment, and now you can! The screen shot below shows what is now possible with the new customization options:

This was achieved by the addition of the following new entries in the “Fonts and Colors” list:

Text Area Background – Normal background color of the editor
Text Area Background (Disabled) – Background color of the editor when editing is disabled (i.e. read-only)
User Margin Background – Background color of the user margin (i.e. the area where icons are displayed for language elements)
Selection Margin Background – Background color of the selection margin (i.e. the area where outlining indicators are displayed)
Outlining Indicator – The Foreground color controls the border and lines of the outlining node, while the background color determines the background of the expand/collapse indicator.
Line Numbers – While not a new entry, the “Background Color” is now supported to control the background of the line number margin.

We hope you enjoy this new level of customization that is coming in the next release (expected by mid-February).

ALM Tip: Convert QTP Business Process Component Back to Manual

Wed, 14 Dec 2011 21:17:10 GMT

Overview

When a manual business process testing (BPT) component is ready to be automated, ALM makes it easy to convert to a QuickTest (QTP) scripted component. It is even kind enough to give you this warning:

For any number of reasons, someone might ignore this warning and convert a component that was not meant to be converted. Or perhaps you have a component that simply cannot be automated despite all your hard work, and you want to convert it back to being just a manual test. ALM warned you… conversion “cannot be reversed”. Or can it?

True, ALM does not provide a mechanism for your to reverse your conversion, but you can accomplish the same thing with a little effort. You simply have to undo everything that was done during the conversion. I recently worked though this same issue, and wanted to share the solution for others facing the same challenge.

The process is pretty simple…

Update the component table to indicate it is a manual component
Remove the file references from the logical tables of the smart repository
Remove the user assets associated with the automated component

Disclaimer: Proceed at your own risk! This process was tested on ALM 11 Patch 6 with and without version control enabled, but that does not guarantee it will work for you or that something else is missing from the process. I feel very good about the solution, but you should make a backup of your project “just in case”. This process will not work on QC 10 or prior releases without some modification, but you can use these steps as a guide.

Note on Version Control: If your project is under version control, your steps will vary slightly based on which database tables you update. Each database query is marked to indicate if it is for projects with or without version control enabled.

Prepare the Component

For projects under version control, you will want to check out your component. This will ensure that all your changes can be wrapped up as a single change. More importantly, it should also allow you to revert back to the automated component if needed.

Most importantly, everyone will need to identify the ID of your component. This value will need to be placed in all the SQL queries where you see <ComponentId>.

Update the COMPONENT Table

The COMPONENT table stores the details about your component. Two columns need to be changed to indicate that the component is manual instead of scripted.

Execute this query for projects NOT under version control:

UPDATE component
SET co_script_type = 'MANUAL', co_subtype_id = 'hp.qc.component.manual'
WHERE co_id = <ComponentId>

Execute this query for projects under version control:

UPDATE vc_component
SET co_script_type = 'MANUAL', co_subtype_id = 'hp.qc.component.manual'
WHERE co_id = <ComponentId>

Remove Smart Repository Files

ALM 11 uses a smart repository where one table stores logical references to files, and another table stores the physical location of files. This allows multiple logical files to refer to the same physical file. We need to remove the entries from the logical portion of the smart repository that refer to the QuickTest script of our component.

NOTE: We do not have to delete the physical files. The next time the repository cleanup is initiated by the system, it will remove the physical files that are no longer referenced.

Execute this query for project NOT under version control:

DELETE FROM smart_repository_logical_file
WHERE srlf_parent_path LIKE '.\components\<ComponentId>\COMPONENT_SCRIPT\%'
OR (
srlf_parent_path = '.\components\<ComponentId>\'
AND srlf_name = 'COMPONENT_SCRIPT'
)

Execute this query for projects under version control:

DELETE FROM smart_repository_logical_file
WHERE srlf_parent_path LIKE '.\checkouts\components\<ComponentId>\COMPONENT_SCRIPT\%'
OR (
srlf_parent_path = '.\checkouts\components\<ComponentId>\'
AND srlf_name = 'COMPONENT_SCRIPT'
)

Remove User Assets

The USER_ASSETS table stores the assets associated with your component, and we need to remove any QTP-related assets.

Execute this query for project NOT under version control:

DELETE FROM user_assets
WHERE uas_owner_id = <ComponentId>
AND uas_owner_type = 'COMPONENT'

Execute this query for project under version control:

DELETE FROM vc_user_assets
WHERE uas_owner_id = <ComponentId>
AND uas_owner_type = 'COMPONENT'

Finalize Component in ALM

If you did not log out of your project, you will need to refresh the component within ALM. At this time, ALM should recognize the component as a Manual component!

Book Reiview: And I thought I knew QTP!

Fri, 04 Nov 2011 13:16:52 GMT

Tarun Lalwani, author of well-received book “QuickTest Professional Unplugged”, just released a new book titled “And I thought I knew QTP!”. I just finished it, and am very impressed with the content!

For starters, this is not your typical reference book. In fact, it’s far from it. Instead, this is being appropriately coined as a “technical novel.” The words “technical” and “novel” seem to mix as well as “oil” and “water”, so how could any technical book be a novel? It all boils down to how the content is presented.

This latest work by Tarun follows the story of Nurat, a consultant in India who finally finds himself with some extra time on his hands after completing a high-pressure consulting engagement. The thought of being on bench is oddly overwhelming as he tries to keep himself occupied and catch up with friends. The timing could not have been better for Nurat to receive a phone call about an opportunity at a new company. Not just any company… his dream job!

The bulk of the story follows Nurat as he encounters a series of interviews for the new position. It is through these discussions that the technical aspect of the novel begins to shines through. The author uses the “question and answer” style of an interview to introduce and address various challenges of automating with QuickTest® Professional. With each question asked by the interviewer, I found myself searching for the right answer before continuing with Nurat’s response. Mixed in with the back-and-forth conversation are detailed code samples as well as notes from the author to supplement and inaccurate or incomplete answer. The natural language with which each topic is presented is a refreshing approach that made this book an easy read from cover-to-cover.

While this is a novel, it is still full of a lot of technical information. The one downfall of the novel-based approach is you will not find a detailed Table of Contents or Index to use as a cross-reference for all the topics discussed. I advise everyone to read this book with either a highlighter or note paper at your side so that you may mark the many sections of the book to which you will later want to refer. You will certainly want to re-read some topics of the book, and having notes will be easier than flipping pages to visually scan for the right text.

I hope I never face an interview process as grueling as this. If I ever do, I hope to perform half as well as Nurat!

Those just getting started or with limited experience in QTP will find a lot of useful information in this book. Even experienced users of QTP will find this book as a validation of the knowledge you have attained over the years. No matter your experience level, it would be difficult to read this book and not learn something new. In fact, most of you will probably end up thinking “And I thought I knew QTP!”

You can order the book at Amazon from the following URL:

http://amzn.to/vXSdX5

You can also order the book off Lulu at the following URL:

http://www.lulu.com/product/paperback/and-i-thought-i-knew-qtp---qtp-concepts-unplugged/17580430

Article on Code Quality: Software Test Professionals

Mon, 08 Aug 2011 01:12:45 GMT

Boyd Patterson (President of Patterson Consulting, LLC) just had an article published on the Software Test Professionals site:

http://www.stpcon.com/Item/1022/?utm_source=Email&utm_medium=email&utm_content=080211-TQA&utm_campaign=NEWSLETTERS

This article introduces the importance of code quality in test automation, and lays the groundwork for a more in-depth conference session at the Software Test Professionals Fall 2011 conference in Dallas, TX. More on that session is available here.

Test Design Studio 3: QuickTest Script Updates

Fri, 15 Jul 2011 17:35:44 GMT

Summary

One of the design goals for TDS3 is to improve how QuickTest scripts are managed in the IDE. Most file editors are designed to work with one file at a time, but a QuickTest script is actually multiple files grouped under a common folder. This has always presented challenges when designing the editing experience, and is one of the reasons why it is more difficult to use common file editors with QuickTest scripts.

You need to be able to open a QuickTest script as a single entity, but must still be able to access the individual files that are part of the script.

Previous Implementation

In previous versions of Test Design Studio, the Solution Explorer tool window would only show you an entry for the QuickTest script as shown in the screen shot below:

When editing this script, the editor would include a drop-down list was displayed above the navigation bar for you to switch between the different actions in the script, as shown here:

This concept worked well when you needed to edit the individual action files, but what about opening the Data Table or Local Object Repository files? Those files were not displayed in the Solution Explorer tool window, so we added special context-menu comments that allowed you to select those files.

This solved most usage scenarios, but some people choose to store additional files or subfolders along with each QuickTest script. The only way to get to this data was to create a link to the corresponding file, but then it was no longer clear that the file was part of the script.

New Implementation

With TDS3, these problems are gone! We have already discussed the new Document Navigation features, and have expanded on that functionality.

The Navigation Bar now combines the action selection along with the document elements, so you end up with a cleaner presentation that does not waste screen real estate:

The left-most entry in the Navigation Bar allows you to toggle between the available actions. Then the normal document contents are displayed.

The Document Outline also breaks your code out by the individual actions and allows you to quickly jump to the relevant code in the editor:

Finally, the Solution Explorer tool window has been updated to show the contents within the QuickTest script folder itself:

All the standard binary files that are part of a QuickTest script are hidden from view, but the key files are still visible. You will notice the ‘Default.xls’ entry for the Data Table as well as the ‘ObjectRepository.bdb’ files for each local repository. There is also a folder called ‘Support Files’ that was part of the script as well as a file called ‘Script Details.txt’. With this change, you will be able to access all the files that are important for your QuickTest scripts! Of course, you can also collapse all that information out of view when it is not needed.

Wrap Up

We believe these changes will make it even easier to work with QuickTest scripts. Since Test Design Studio is specifically designed to work with these file types, you also get a unique experience that is not available with standard text editors.

Presenting at STP Fall Conference in Dallas [Updated]

Wed, 06 Jul 2011 19:56:34 GMT

I am happy to announce that I will be presenting a session at Software Test Professionals Conference 2011 Fall in Dallas, TX!

Session Title: Improve Automation Code Quality, Clarity, and Comprehension
Session Track: Test Automation
Session #: 602
Date/Time: Wednesday, October 26, 11:30am – 12:45pm
Session Description:

How many times have you looked at someone else’ automation code and
wondered what they were doing? How about your own code months after you
wrote it? Much of the effort to perform test automation comes months or even
years after the initial scripts have been written. Before you can begin to debug
broken code or write new functionality for a test, you must first comprehend
what was previously written.

This session will teach you about many of the common pitfalls in authored code
and how you can refactor your code to dramatically improve comprehension.
Topics of discussion will include good naming conventions for variables and
methods, when to use callable routines, effective use of parameters in routines,
variable usage, avoiding “magic values”, code formatting, and objective
measurements of code complexity. Examples from the presentation will be
provided based on HP QuickTest(R) Professional, but the concepts can be
universally applied to any programming language.

This will be my first time presenting at a conference, so I am very excited about the opportunity and look forward to bringing the spotlight to code quality. Perhaps equally exciting is the chance to meet many of the Test Design Studio users out there. Are you planning to attend the conference? If so, drop me an e-mail. And of course… be sure to sign up for my session!

UPDATE: Here's a link to the official website:

http://www.stpcon.com/Session/29/Improve-Automation-Code-Quality-Clarity-and-Comprehension

New Feature: Toggle Outlining Expansion for Selection

Fri, 01 Jul 2011 16:49:53 GMT

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.

New Feature: Member List for VBScript "Call" Keyword

Fri, 01 Jul 2011 16:42:33 GMT

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.

New Feature: Enum Member Lists for Assignment and Equality

Fri, 01 Jul 2011 02:44:25 GMT

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!?

Test Design Studio 3: External Tools

Wed, 15 Jun 2011 19:22:27 GMT

As part of the ongoing effort to bring Test Design Studio to a new platform, we are having to rewrite a lot of the functionality that is present in Test Design Studio 2. We are taking the time to re-engineer the back-end code that powers each feature as well as updating the user interface to WPF. The latest feature completed is External Tools!

Test Design Studio uses external tools to allow you to integrate with 3rd-party applications. The real benefit to this feature comes in the form of replacement parameters for your command-line arguments. These special parameters are replaced at the time the tool is executed, and the replacement value is determined based on the current state of Test Design Studio.

For example, the “$(ItemPath)” value will always be replaced by the full path of the currently selected file. This makes it easy for you to open the file in another tool or perform other operations on the file. Test Design Studio is smart enough to recognize different states in the application. If you select a document, the “$(ItemPath)” parameter will represent the full path of the open document. If, however, you have selected a file in the Solution Explorer tool window, the “$(ItemPath)” parameter will represent the full path of the selected file.

All of the replacement parameters from Test Design Studio 2 will continue to be supported. As part of the rewrite, it will be much easier for different parts of the application to provide context-sensitive replacement values, and new replacement values can be easily added.

This feature is very versatile, but under-utilized. Hopefully these enhancements to the feature will help it bring new value to your organization. Some customers have even used external tools to provide basic support for version-control systems!

In Test Design Studio 2, you used a very generic “Wizard” interface to configure your tools, and each tool showed up in the ‘Tools’ menu. Time to introduce you to the new interface!

You have four options on the left:

Execute/Manage External Tool
Add a New External Tool (shown in screen shot)
Learn More about External Tools
Replacement Parameters

In the screen shot above, I am adding ‘Notepad’ as a tool in the ‘Text Editors’ group. All the necessary controls are easily laid out, and tooltips are provided (although not shown above) to guide you on the purpose of each field if needed. The drop-down next to ‘Arguments’ will present you with a listing of all available replacement parameters, and hovering over a menu selection will reveal the purpose of that value.

Need even more assistance on Replacement Parameters? Just select the ‘Replacement Parameters’ tab in the dialog. You will then be presented with all the available replacement parameters and how to use them:

From the ‘Execute/Manage an External Tool’ tab, you can manage your available categories (categories can even have sub-categories… new in Test Design Studio 3), edit your tools, or execute them.

Context menus on the category nodes allow you to create or delete categories, and selecting a tool from the list will present you with the available run, edit, delete actions for that tool.

This dialog is meant primarily to manage your tools. Even though you can execute your tools from the dialog, the process of locating and executing the tool could quickly become time-consuming. That’s why we’ve added the tools directly to the Ribbon interface in the form of a Gallery.

You can easily scroll up/down through the available external tools, and your selection will be retained so you can easily execute the same tool again. If you select the drop-down arrow, you’ll be able to browse the tools by category, and will also find the command to open the full dialog to manage your tools.

Since replacement parameters are meant to be “replaced” with something more meaningful, we have also added a dialog to warn you if you attempt to execute a tool when all the values could not be replaced. This allows you to cancel the tool instead of allowing it to be executed with incomplete command-line arguments.

The one feature currently missing from Test Design Studio 3 is the ability to execute an action before/after the tool is executed (e.g. save a document before running the external tool). This is a feature currently in Test Design Studio 2, and we hope to incorporate the feature in TDS 3 before the launch. If the feature does not make the launch, it will be the target of a follow-up release that we expect to happen with a couple of months of the first release. Due to the large amount of work required to get TDS 3 rewritten and ready for release, some lesser-used features like the external tool actions may have to wait until after the initial launch so that we can get the core product out as soon as possible.

We hope you enjoy the updates to the External Tools feature. The most significant updates were made in the code itself, but hopefully the GUI updates will be a welcome change.

New White Paper: QuickTest(R) Project Management

Sun, 22 May 2011 17:01:01 GMT

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.

Using Test Design Studio and QuickTest(R) Together

Wed, 04 May 2011 14:44:24 GMT

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 (a problem Test Design Studio does not have, as shown here).

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:

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.
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.
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).
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 test and 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 test in 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’.

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:

Save your test in Test Design Studio so that all changes are committed.
Right-click the document tab for your test (or corresponding file in ‘Solution Explorer’) and select the ‘Open in QuickTest’ command.
Switch to the QTP application
Perform the necessary steps in QTP to add your new action
Save the test in QTP
Switch back to Test Design Studio
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.

Edit Multiple QuickTest(R) Pro Tests and Actions at Once

Sat, 30 Apr 2011 15:09:17 GMT

One of the biggest limitations that QuickTest® Pro users face is that you can only edit a single test at a time. You can open multiple supporting documents like function libraries, but you are always restricted to the single test.

Test Design Studio does not face the same limitation! You can open as many tests as you want and even view multiple documents at the same time. Let’s walk through the basics.

Opening Multiple Tests

Opening multiple tests is easy. You simply select the ‘File –> Open –> File…’ command from the main menu, browser to and select the file you want to open. Repeat the process for as many tests as you want to open at the same time (you can also open your tests directly from an open project in the ‘Solution Explorer’ tool window). The screen show below shows two tests open at the same time on separate document tabs. The tests are ‘CalcTest’ and ‘Test2’.

By simply selecting the different document tabs, you can easily switch between the two (or more) open tests. What if you wanted to be able to view two tests at the same time? Test Design Studio can handle that as well! The document area can be divided into multiple horizontal or vertical groupings of documents. Simply select the document you want to move and select ‘Window –> New Horizontal Tab Group’ or ‘Window –> New Vertical Tab Group’.

In the screen shot below, I have decided to create a new Vertical tab group to take advantage of the extra width provided by widescreen monitors.

You could even create a third, forth, or fifth (and it doesn’t stop there) tab group to view three or more tests at the same time! Once your tab groups are created, you can easily move your documents between the tab groups by drag-and-drop. Simply drag the document tab from one group into the tab area at the top of another group.

Working with Multiple Actions

The implementation within Test Design Studio 2.0 is that all the actions of a test are represented within the same editor (note we are considering altering this for Test Design Studio 3 where each action is opened separately). The drop-down list at the top of each editor window allows you to switch between the available actions in that test, but you can only view one action at a time within the editor window. So what happens if you want to view two or more actions from the same test at the same time? Test Design Studio has you covered. The solution is to duplicate your editor window! You can do this with any editor, but it is especially useful when working with multi-action QuickTest® Pro tests.

To duplicate an editor, first make sure you the editor you want to duplicate is the current selected document. Then select ‘Window –> New Window’ from the main menu.

When this command is selected, the current document window will be duplicated to create two document windows for the same file. Each editor instance will be suffixed in the title bar with “:1” for the first editor, “:2” for the second editor, and so on. Once you have duplicated the editor for your test, you can use the same technique shown above to position the two editors side-by-side in different tab groups. You can then independently choose the action from the drop-down list that you want to view. Below you will see the same test (e.g. ‘CalcTest’) displayed in two vertical tab groups. On the left you can view ‘Action1’, and on the right you can view ‘Action2’. Try doing that with the QuickTest® Pro IDE!

New Feature: Test Design Studio 3

To give you one more thing to look forward to, Test Design Studio 3 will offer the ability for you to “float” your document windows out of the main IDE interface! This is primarily beneficial to users with multiple monitors as you will be able to place documents (or groups of multiple documents) on separate monitors!

Summary

The focus of Test Design Studio has always been about enabling test developers to reach new levels or productivity, and the features outlined here are just a few of the ways you can use Test Design Studio to improve your efficiency.

New Feature: Quality Center File Locking [Update]

Wed, 27 Apr 2011 12:47:20 GMT

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.