A Test Design Studio Success Story : Dim Those Variables

Back Story

During some recent work with a client, I had the task of pulling up about 100 automated regression tests for a critical business application.  These scripts were frequently executed, and took hours to complete.  They had also been in service for years and seen many updates, but we knew they worked… or did they?

Building the Project

The first thing I did was create a new project in Test Design Studio to include these various tests.  In addition to the tests, I added all the relevant function libraries and object repositories.  Each of these assets were stored in Quality Center/ALM, and Test Design Studio handled them perfectly.  That’s when the fun begin.

Hello “Option Explicit”

Test Design Studio features a code analysis feature that helps you focus on improving the quality of your code.  Now that my project was established, the code analysis was lighting up all the areas I needed to address.  If there is one practice I have always preached for writing VBScript-based code, it is this… turn on “Option Explicit”.  When set, this requires the VBScript run-time engine to throw an error if you attempt to use an undeclared variable.  Anyone who has ever mistyped the name of a variable and tried to debug why their script failed knows exactly what I’m talking about (hint: VBScript just uses the mistyped name as a new variable with an empty value).  When over 50 of the tests were displayed in my Error List as not having Option Explicit set (which is one of the code analysis rules you can turn on), I knew it was my first order of business.

Updating the Files

Remember, all of these tests are in Quality Center/ALM and are scattered between folders.  What would normally be a daunting task of searching out the noncompliant tests, opening in QuickTest (switching to Expert View), and saving back was made remarkably fast by Test Design Studio.  The process was simple…

  1. Double-click the error in the Error List that indicated the lack of Option Explicit. It did the heavy lifting of finding the right file.
  2. The file was opened directly in Test Design Studio with the code readily available.
  3. A pasted in my line for “Option Explicit”.
  4. Saved and closed the editor.
  5. On to the next error; repeat.

What a relief!  I had those 50-or-so tests updated quickly.

What About Those Undimmed Variables?

Now comes the tricky part.  Turning on Option Explicit may sound like a simple task, but the consequences can be devastating for an existing script.  If I run the tests “as-is”, they will throw an error and halt execution any time an undeclared variable is used.  These tests are critical, and silly failures like this cannot be allowed.  Executing, fixing, executing, and fixing would take hours for each test.  Many of these scripts were 1000’s of lines long and could take over 30 minutes to complete.  Variable declaration was never required, so the assumption was that many of the variables in use had never been declared.  That’s when I saw the new Error List from Test Design Studio.  It contained over 1,200 errors, most related to the use of an undeclared variable.  Thankfully, that’s another code analysis rule you can turn on in Test Design Studio!

Without code analysis, I never would have dared to scour all those lines of code looking for every possible variable reference and making sure it was declared.  When adding all those declarations, it’s also easy to accidentally declare a variable in one section of code that was already declared somewhere else.  That, too, can cause a run-time error.  You guessed it… Test Design Studio has a rule for that too!

My process was simple… I would find one of the errors in the list and open that test.  I’d then filter the error list to only show me the errors for the currently opened file.  That let me know exactly how much work was before me.  When I’d find the usage of an undeclared variable, I’d do a quick “Find in File” to see all the places in the test where the variable was used.  Once the file was clean, I’d save/close, restore my error list to the unfiltered view, then pick the next error from another file.

Most of the time, the variables were legitimate and needed to be declared.  Sometimes I found that variables were assigned values but never actually used in the test!  That’s confusing to new authors trying to understand a test, so I got rid of those (they were left over from previous versions of the test that were later modified).  The worst is when I found variables that were used but never assigned!  The author of the test clearly expected a value to be in the variable, but it was always going to be blank.  That could lead to the test not validating the functionality it was designed to test.  Was this test even valid?

How Did It Turn Out?

After spending a couple hours going over all the tests, adding Option Explicit, and fixing all those variable references, I found several logic errors in the script that never would have happened if Option Explicit had been turned on to begin with (confirming my theory that you should always use Option Explicit).  When the tests were executed, not a single run-time error was encountered from all those changes.

Tens of thousands of lines of code, and I didn’t miss a single variable… THANK YOU TEST DESIGN STUDIO!

Use Test Design Studio For Your Own Projects

You can find out more about how the Code Quality features in Test Design Studio on this special feature page.  Of course, you can also download a fully functioning trial version of the software and try it out for yourself.

Book Review: QTP Descriptive Programming Unplugged

Most areas of computer programming have the privilege of access to many reference books.  QuickTest automation, which I have always stated is more of a programming activity than testing activity, is not one of those areas.  This is why a new book on QuickTest programming is always a gem!  The latest work by Anshoo Arora and Tarun Lalwani, titled “QTP Descriptive Programming Unplugged” does not disappoint.

This is not the first book for Tarun.  Those who are still learning the in’s and out’s of QuickTest should check out his first book titled “QuickTest Professional Unplugged”.  I also reviewed his second book “And I thought I knew QTP!” which utilizes a narrative technique to introduce technical concepts.  This latest book, with the help of Anshoo Arora, is a return to the typical style of a technical reference manual.

I have been working with GUI test automation for 13 years, and there is one key aspect of interacting with a GUI that has never changed; you must be able to recognize the UI objects!  Anyone who has ever been given a new application to test has had the realization that comes when you fire up your automation tool only to see that few, if any, of the screen objects are recognized by the tool.  This is the “knife to the heart” of any automation effort because object recognition is so vital to successful automation projects.  We face enough challenges with GUI automation, that object recognition should not be one of them.

When you find that QuickTest is able to recognize your objects, be thankful!  The journey typically does not end there, and that is where this book is a valuable resource.  Even when working with supported technologies, getting QuickTest to properly and consistently recognize your objects is a must.

This book is a valuable resource because it takes many years of experience in QuickTest object recognition and presents it in a clear, well-organized fashion.  You will learn the differences between Local and Shared object repositories, and which strategy to use.  Those who prefer to avoid object repositories will receive a healthy discussion on descriptive programming, the art of defining your objects at the time you use them instead of within a repository.  Even advanced topics such as using the Document Object Model (DOM) for web applications or XPATH to identify elements are covered in detail.

The authors do more than just introduce topics.  Topics are what you can expect from the QuickTest-provided documentation.  This book takes those topics and discusses the risks and benefits of each.  This was evident when I read about the topic of “Smart Identification” (I’ve always believed it’s one of the biggest misnomers since Little John in the Robin Hood stories), how it works, and why disabling it is the first thing you should do.  For example, you can quickly learn about the concept of descriptive programming, but this book explains why you might want to use it, suggestions for improving success on large projects, and the potential pitfalls like escaping regular expression characters.

While primarily a discussion on object recognition techniques, the book does go off-topic on a few extras such as how you could write test code in a .NET language.

Those who are new to QuickTest should still start out with “QuickTest Professional Unplugged”, but they should quickly follow it up with this latest title.  Even automators with several years and projects behind them have something to gain through the reference.

Workflow Editor Preview Available

Product Discontinued Notice:  We have learned that HP's roadmap for ALM is to move to a thin client with rules-based customization instead of the current workflow-based customization, so the need for a more advanced editor for workflow files will be short-lived.  We have decided to stop development of this product so our resources can focus on projects with longer-term benefits.

We are pleased to announce that the first public preview of Workflow Editor is now available for download!  Since giving a sneak peak, a lot of work has been completed to improve the core editing backend of the software.  We took extra time to get the editing engine closer to where it needs to be for a full release.  In that time, we also made some tweaks to the UI to give it a more modern look-and-feel.  One thing that has not changed is the price… this product will still be free!


Before taking a quick tour of the product, let’s talk about what it takes to make it work.

.NET Framework 4.5

This product is built using Microsoft’s .NET Framework 4.5 (download), so you must have this framework installed.  As of this writing, it is the most recent release of .NET Framework, and we wrestled with moving from 4.0 to 4.5.  In the end, the benefits (especially asynchronous programming and bug fixes) outweigh the bad (more limited install base).  Many of you will not have .NET 4.5 already installed, so it is an extra download.  Those of you running Windows XP will find that the download is not even available.  That’s right, we will not be supporting Windows XP.  Microsoft has now released it’s 3rd operating system since Windows XP, and it’s time to move on.  Most corporations that were hanging to Windows XP have now moved on to Windows 7, and expect most others to complete this transition by the time Workflow Editor and Test Design Studio 3 are ready.

Application Lifecycle Management (ALM)

You must be running ALM 11.  You should also be able to use ALM 11.5, but we have not been testing against this latest release of ALM yet.  If you do use ALM 11.5 successfully, please share your feedback.  Additionally, ALM 11 users must have installed at least Patch 1 or Service Pack 1 (which includes Patch 1) to enable the FTP server functionality.  More on that to come.

Why no Quality Center 10 support?  The answer is simple… HP does not provide an approved or secure way to transfer workflow files between the Quality Center server and your computer.  Their own tools handle the transfer of files through private APIs that are not available for 3rd-party tools.  The only way to enable the file transfer is to expose Extended Storage access on the server.  This works, but is a security concern since anyone with project access and programming knowledge can access and modify most of the files on your Quality Center server!

ALM 11 began offering an FTP server for project repository browsing, and the workflow files are part of that repository.  We have wanted to provide a workflow product based on our Test Design Studio code engine for many years, and the FTP feature finally makes it possible to provide mainstream support without the security issues of the technique necessary for Quality Center.

ALM Configuration

The FTP functionality is required, so it must be turned on.  In most cases, it is as simple as adding the ‘FTP_PORT’ site configuration parameter to your server.  Refer to the ‘Browsing the Project Repository’ section of the ALM Administrator Guide for details.

Your user account must also be a Site Administrator.  This is required by the FTP server in ALM.  We realize that some users will have access rights to modify workflow for specific projects (through Project Customization) and not be a Site Administrator.  Regrettably, we know of no other reasonable way to transfer the files at this time.

Your user account needs access to the individual project whose workflow you want to edit.  While not presently enabled, the goal for Workflow Editor is to provide context-sensitive IntelliSense about available field names.  To access that information, the tool will need to access the project customization through the API.  Currently, your project access is used to display a list of available projects to open.

While this should be a non-issue for most, your user account must have a password.  While ALM does not require it, the FTP server in ALM does.

Finally, our tool uses the COM API, so you must register the ALM Client Components on your machine to make the API available.  This option is available from the ALM Add-ins page.

Product Tour

Now to the fun stuff!  We are very excited to make Workflow Editor available.  This product is sharing a lot of the code from our Test Design Studio 3 product currently  under development.  We have been working on Test Design Studio 3 for a few years and made many exciting improvements.  We finally get to show off those improvements to the public!

When you open Workflow Editor, you will see the basic IDE framework.


Aside from the ‘Welcome’ message, most of the IDE is empty.  Please take a moment to read the important information on this page.  Most of the ‘Getting Started’ information is available on this blog post, but please refer to the ‘What’s Missing’ and ‘Feedback’ sections.

Open a Project

Your first step will be to open a project’s workflow code.  Click the ‘File’ button on the application ribbon to expose the backstage menu.


The default tab ‘Info’ will be selected to show you the status of your current connection.  Click the ‘Open’ tab to open a project.


Step 1 is to define the connection information for your server.  Hover your mouse over the image icon on the screen to see helpful information about relevant fields.  You will need to enter the URL of your ALM server, the FTP port you configured for file access, and indicate if you setup FTP for secure transfer.  Finally, enter your user name and password.  Once all fields are complete, click the ‘Connect to ALM’ button.  At this time, Workflow Editor will attempt to connect to the ALM server to pull back a list of projects and will also validate the FTP connection is available.


Step 2 allows you to select the specific project (based on domain) that you would like to open.  Even though your account will be setup as Site Administrator, you will only see the domains and projects to which you have been granted explicit access.  After selecting your project, click the ‘Open from ALM Project’ button.  Workflow Editor will begin downloading the workflow files and preparing the IDE.  We are using the demo project that ships with ALM.


You are now returned to the core IDE.

Script Explorer and Document Navigation

You will see that the ‘Script Explorer’ tool window has been populated with entries for each of the workflow scripts that exist for this project.  Double-click any of the scripts in ‘Script Explorer’ to open the text editor for that file.


In the example above, we have opened the ‘Defects’ workflow.  At this point, you are essentially working with a VBScript-based code editor, and some of the great editing experiences are described in the sections below.

Since an editor is open, the ‘Document Outline’ tool window has been populated with a list of relevant language elements in the file (e.g. variables, functions).  The ‘Document Outline’ is a great way view the defined elements in your code as well as jump to the code that is important to you.  The ‘Document Outline’ also helps you keep track of where you are in the document because the selection is synchronized to your location in the editor.  You will find the same functionality in the navigation bar at the top of the editor document.  For more details on documentation navigation, please refer to our previous blog post highlighting the feature.

Most importantly, a new document tab has been opened to edit the code.


Our editor supports code outlining, so you will probably see many lines of code have been collapsed to show image indicators instead of the full text.  This helps you focus on the overall structure of the document and only drill in to the details as you want.  You can click the image icon in the margin to expand the code regions.  You can also fully manage outlining use the options on the application ribbon (also available on the editor context menu) including an option to disable the feature entirely if you prefer.  For the purposes of this tour, please select ‘Stop Outlining’ so you can see all the code in the editor.


Syntax Highlighting

You will see that the editing experience features full syntax highlighting of the code.  You may also notice that the colors used are a little different than those used by the ALM editor.  We are using the same colors and styles used by QuickTest Professional (remember, Workflow Editor is based on our QTP tool Test Design Studio).  In future releases, we hope to allow custom color schemes.  You will find that the color scheme defaulted in Workflow Editor is consistent with other mainstream VBScript editors.


One feature severely lacking from the ALM editor is code completion for standard VBScript language elements.  Place the caret in the editor and press the Complete Word shortcut key (Ctrl+Space) to display a member list (alternatively, select ‘Complete Word’ from the IntelliSense group of the application ribbon).  You will see a list populated with all the key elements from VBScript.


In addition to VBScript entries like ‘Mid’ and ‘MsgBox’, you will also find references to all the functions you have defined in your workflow code.  When an item is selected (such as ‘Mid’ in the screen shot above), a tooltip will even be displayed to give you information about the context of that function.  The benefits of IntelliSense are well-understood, and Workflow Editor comes fully loaded!

You can read our feature highlight about member list enhancements to learn about some of the unique features you will find in Workflow Editor’s IntelliSense engine.  For instance, type “mb” when the member list is displayed and you’ll see that ‘MsgBox’ is in the short list of options because it is a shortcut for the full word.


You can also type “date” to see all entries related to date even if they do not start with those letters.


IntelliSense also covers parameter information when calling functions.


You can even use specially-formatted XML comments to provide descriptions for your custom code so that you receive the same full IntelliSense features as built-in functions.


In the screen shot above, notice that the parameter information for the ‘SetFieldProperties’ function includes summary information about the function, the expected type of each parameter (e.g. String, Boolean, or Integer) and a summary of the purpose for each parameter.  The XML-formatted comments before the function declaration are what power the IntelliSense.  XML-formatted comments even get special syntax highlighting to improve readability.  Note: We will be adding functionality in the future to help speed the entry of XML-based comments including the ability to auto-generate a skeleton of code just by typing three comment characters (‘ ‘ ‘) immediately before any declaration.

The final IntelliSense topic is Code Snippets.  This feature allows you to quickly insert a common block of code and focus only on changing the elements of the code that are important.  Many Code Snippets have shortcuts to activate them in the editor.  For example, type the shortcut text ‘for’ and then press the Tab key to activate the ‘For Loop’ snippet.


You will see the editor inserts all the “boiler plate” code and has highlighted the three elements that actually need your input; iterator variable name, start value, and end value.  As you change each entry, press the Tab key again to move to the next entry.  When you are finished, press the Enter key to complete the snippet and move the caret inside the code block so that you may start entering the elements to be included in the loop.  You can also press the Esc key at any time to exit the snippet.  This is a very simple example, but you can also use code snippets to provide guidance on larger blocks of code.  From the main ribbon, click the ‘Code Snippets’ command and select ‘Insert Snippet –> Regular Expressions –> Test Partial Match’.  This will activate a code snippet to use a regular expression to see if a certain pattern is found in a string.


You will see this code is more complex than the original For loop sample, and it highlights another key aspect of code snippets.  Notice that the variable ‘oRegEx’ is used four times in this snippet.  If you change the value in one place, you much change the other values to match.  Code snippets handle this redundancy for you.  If you decide to rename the ‘oRegEx’ variable as ‘objRegExp’ and press Tab to advance to the next field, all the other instances are updated as well!  Many code snippets are included with Workflow Editor.  In future releases, you will be able to create your own.

Syntax Checking

With any editor, Syntax Checking is a major “must have” feature, and Workflow Editor delivers.  Errors in syntax are highlighted as you create them.  There is a syntax error in the following code, and Workflow Editor makes this mistake obvious.


The error is underlined with typical “red squiggle” line to emphasize the mistake, and hovering the mouse over the error will display a tooltip of the problem.  The ‘Error List’ tool window is also available to show you details of all errors in all files.


You can optionally filter the ‘Error List’ to only show errors related to the actively edited file, and double-clicking any error in the list will open the editor for the relevant file and move the caret to the location of the error.  The ALM editor does not show you errors until you explicitly invoke the ‘Syntax Check’ command or try to save the file.  Fixing errors immediately as you create them is always more efficient than being told later (perhaps after many edits have been made) that you introduced an error.

Special Highlighting

One of the great new features available through our improved editing engine is identifier highlighting.  This allows the editor to visual highlight other instances in code where the same identifier is being used.  Our other blog post has details and screen shot samples.  This has been a highly-requested feature for our Test Design Studio product, and it makes a great addition to Workflow Editor as well.

Similar to identifier highlighting, we also support highlighting certain language structures.  We have a blog post that talks about that feature in depth as well.

IDE Customization

Being a modern IDE, you can heavily customize the view of the application.  Tool windows can be moved, regrouped, collapsed, resized, or docked like documents.  Even document windows can be repositioned to view multiple documents at once.  Click on the document tab, tool window tab, or tool window title bar and start dragging it around.  Guides will appear to show you the various drop targets for the item, or you can float the window outside of the IDE.  In the screen shot below, the ‘Script Explorer’ tool window has been dragged to reveal the drop targets.


Hovering over any of the drop targets will show you a preview of where the tool window will be placed.  If you end the drag-and-drop operation without being on a drop target, the window will float.  Users with multiple monitors will appreciate the fact that you can even float one or more document windows!  That allows you to have the IDE on one monitor and optionally display a second full document on another monitor.  You can also dock documents side-by-side in the main IDE and even split the view of a single document into as many as four independent views.  The following screen shows a possible customization:


The ‘Ribbon’ and the ‘Error List’ tool window have been collapsed.  The main IDE document area has been split to show three simultaneous documents.  The ‘Script Explorer’ and ‘Document Outline’ tool windows have been grouped into a single tool window and floated.  The ‘Test Lab’ document has been floated outside the IDE.  The ‘Defects’ code has been split into four views, and the ‘Common’ document has been split into two horizontal views (two vertical views also available).  The options are nearly limitless!  In the screen shot above, you are viewing eight different sections of code.  The ALM editor can only ever show you one!

Additional Features

Workflow Editor has many other useful features that won’t be discussed in detail.

  1. You can zoom your editor view in or out.  Zoom out to get a bigger picture of the document, and zoom in to help with small screen resolutions or code review presentations.  The zoom indicator is at the bottom-left of the document window.  You can also use Ctrl+MouseWheel or the Zoom buttons on your keyboard (if available).
  2. The editor margin changes colors as you make edits.  It turns “yellow” when you have modified a line, and then turns “green” when those modifications have been saved.  This helps you keep track of all the changes in your editing session as well as which changes have or have not been committed.
  3. Macro recording (available from the ‘Editing’ group of the ribbon) allows you to record a series of editing actions and then play them back.  Through combinations of typing, cursor movement, and clipboard actions you can easily perform repetitive tasks on your code.
  4. The Advanced drop-down menu on the ‘Editing’ group of the ribbon exposes many features such as converting spaces to tabs, tabs to spaces, and eliminating unnecessary horizontal whitespace.


Wrap Up

While we are very happy with the features and functionality already available in Workflow Editor, we know it is far from complete.  Most of the work so far has been related to generic VBScript editing capabilities (since that is the same work necessary for our Test Design Studio 3 project), so workflow-specific enhancements are still needed.  The built-in ALM editor is so weak that our Workflow Editor already provides many benefits over the built-in editor in spite of the current state of the project.

The product is absolutely free, and we hope you take the time to evaluate what we have done so far and provide feedback to contribute to its future.

Test Design Studio Updates to Build Process

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:

  1. Add the test to my project using the ‘Add New Item’ command and selecting my QuickTest file template
  2. 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:

  1. Add the library to my project using the ‘Add New Item’ command and selecting library file template
  2. 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.


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 Reveals Errors in QuickTest's "Web_Services.txt" File

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:

  1. “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.
  2. 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:

  1. 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.
  2. 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

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


New Feature: Additional Fonts and Colors

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:

  1. Text Area Background – Normal background color of the editor
  2. Text Area Background (Disabled) – Background color of the editor when editing is disabled (i.e. read-only)
  3. User Margin Background – Background color of the user margin (i.e. the area where icons are displayed for language elements)
  4. Selection Margin Background – Background color of the selection margin (i.e. the area where outlining indicators are displayed)
  5. 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.
  6. 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).

Sneak Peak: Workflow Editor

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.

Article on Code Quality: Software Test Professionals

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


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.

New Feature: Toggle Outlining Expansion for Selection

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.