If you are not already following Joe Colantonio's excellent automation podcast called Test Talks, Episode 103 is a great place to start. This podcast featured noted automation expert and "Dark Arts Automation Engineer" Paul Grossman, and we were honored that Paul mentioned Test Design Studio and this company's founder, Boyd Patterson, in his list of mentors and recommendations.
What exactly did Paul have to say? He highlighted Test Design Studio’s unique static code analysis feature for VBScript saying “Nobody else has that! I’ve Googled it. It’s not there.” Thanks, Paul! We’ve Googled it, too, and have to agree.
You can read more about static code analysis in Test Design Studio here if you want to see what has Paul so excited.
As our way of saying thanks to both Joe and Paul for this mention, we’re giving away a FREE seat license of Test Design Studio! All you have to do to enter:
- Listen to Test Talks Episode 103
- Leave a comment at the bottom of the episode 103 page
- Joe will randomly pick someone from the comment list on June 20, 2016 to receive the free license (extended from previous date of June 13)
The seat license includes 1 year of maintenance and support and can be used for personal or commercial use. The only restriction is the license cannot be sold or transferred. Good luck!
It’s been a long journey, but we are pleased to announce the general availability of Test Design Studio 3.0!
If you have not already, please read our post about the new focus for Test Design Studio to understand how we got here and where we are going. That post also highlights the most significant change in functionality in this release; connecting to ALM\Quality Center servers. This is a transformational release, so check our release notes about some functionality which, unfortunately, needed to be deprecated in order for us to move the product forward.
The new release is available to download right now from our Downloads Page and all users are strongly encouraged to upgrade if you can.
How to Upgrade
Customers with an active maintenance agreement can upgrade to Test Design Studio 3.0 at no additional charge (see below for details on licenses)! Customers without an active maintenance agreement are encouraged to evaluate the new release and our new focus for Test Design Studio to see if they want to come back. Then you can contact email@example.com to discuss options to upgrade to the latest version at promotional rates.
First and foremost, the requirements for running Test Design Studio have changed since the last release. Primarily, this involves a shift to Microsoft .NET Framework 4.5, so you must first install the right version of .NET Framework before you can install and use Test Design Studio. The newer .NET Framework also means Windows XP is no longer supported, so users on that operating system should continue to use v2.5. Test Design Studio 3.0 will run on any system that is supported by .NET Framework 4.5.
Acquiring New Licenses
In the coming days, all existing customers with an active maintenance will have updated license information sent to their primary contact. If you have not received your new license or want to upgrade sooner, simply contact firstname.lastname@example.org to inquire about the new license. You can go ahead and install Test Design Studio 3.0 today and use the included 20-day trial until your new license is available.
Users with seat licenses will receive new serial numbers that begin with “TDS30”. The old serial numbers will not work with the latest version, so you must acquire, register, and activate the software with a new serial number.
Users with concurrent licenses will receive a new license file for use on each client, but your license server will not require any updates.
We hope you enjoy this new release of Test Design Studio, and we are already working on the next round of feature updates due later this year. We look forward to any and all feedback you might have about the release.
It is with great pleasure that we announce the pending arrival of Test Design Studio 3, and the following is a glimpse of what is to come:
A New Focus
Those who have been using Test Design Studio for a while know that the idea of what would be TDS 3 has shifted over time. Our initial goal was to take TDS into the future with an entirely rebuilt user-interface and re-architected back-end services. That undertaking proved to be bigger and more complicated than expected, and resulted in one delay after another. As time wore on and we analyzed each part of the system, we realized what we already had was pretty great. The passion and commitment to build a first-class editing experience for QuickTest Professional code authors was prevalent throughout, and could not be ignored. Instead of making our loyal fans wait any longer for the new release, we decided to refocus our efforts on bringing the already great application forward into the expectations of today.
We started with the user interface. While purely aesthetic, the appearance of an application is something that impacts every user during every moment they are using the software. The moment the TDS splash screen goes away, you are presented with a clean and modern UI. Gradient effects of yester-year have been replaced with a flat and clean appearance that result in fewer visual distractions and improved focus on your work.
What came next was a tremendous effort that, had we not told you, you may never have known. We refactored our code. A lot of code! Test Design Studio was first built in the age of .NET Framework 1.1, and the .NET Framework has seen significant improvements since. Design choices that had to be made based on the limitations of the early .NET Framework were no longer necessary. There was functionality written for TDS v1.0 that had exceeded its relevancy or had eventually gone in a different direction through the iterations of our software. We looked at everything with fresh eyes and adjusted the design as needed. Even many of the rewritten subsystems for the new design were incorporated into the existing design where possible. What was the result? The code is now cleaner and more structured. This translates to easier debugging, reduced maintenance, eradication of many existing bugs, and increased confidence to make changes without introducing regressions.
A New Integration
Perhaps the largest user-facing difference in this release over prior releases is a change to how we integrate with HP Quality Center or Application Lifecycle Management (ALM). Many would be surprised to know that TDS 2.5 still fully works with Mercury TestDirector 8.0! It is easy to forget that TestDirector did not support the single authentication point we have today. A user switching projects would have to exit their current project, select a new project, and login again with potentially different credentials. The server- and project-centric integration design within TDS was based on that original functionality from TestDirector. As TestDirector changed names to Quality Center and beyond, we continued to support the previous versions while tweaking our integrations to support their evolved systems. One such change was the authentication model shift which occurred in Quality Center 9.0. While moving TDS forward, those decisions from the past and desire for backwards compatibility still influenced our integration.
Since use of those legacy systems has sunset, we have reached a point where no supported version of Quality Center or ALM requires that older design. Today, we are happy to announce that TDS 3 has refocused and streamlined your integration with Quality Center and ALM into a single connection dialog.
You no longer have to step through the Connection Wizard to define a server and configure your account. Instead, you are presented with a simple authentication window that is familiar to how other tools also integrate with ALM. Changing ALM servers is now as easy as just changing your connection. File references which are stored by TDS will still note the server from which they originated, but will always use the current server connection. What hasn’t changed is the ability to interact with multiple projects after connecting to the server. While ALM integrations like that found in Unified Functional Testing require you to build a connection to an individual project, TDS will still independently manage individual connections so that you can simultaneously work with content from multiple projects.
Even with our changes, we still maintain a high degree of backward compatibility and are happy to continue support for Quality Center 10 and all versions of Application Lifecycle Management.
Continuing with the theme of refocusing our efforts, this release of TDS will remove some functionality related to ALM that was not core to this product. Test Design Studio has always been about coding tests. It’s right there in the name. Yet over time, the software became bloated with features related to ALM administration. Most of this functionality required Site Administrator access in ALM which was managed through a completely separate API. Other features, like interacting with ALM workflow scripts, required changing parameters on the server that could impact the security of your system. To put TDS on a new track of growth and evolution, we had to leave those administrative features behind and focus our integration on that which was necessary for strong test design.
A New Commitment
Our new commitment starts with an admission. Our choice to execute a complete rebuild of Test Design Studio was wrong. While our hearts were in the right place and we had the right goal in mind, we simply charted the wrong path. We still believe in that future for TDS, but will use a more iterative approach to get there. A new plan has already been put in place to make that happen, and it starts with more frequent application updates. In this new day of continuous improvement, we are letting go of the idea of a “major release”. Instead of holding back new features in an effort to group them into a major release, we will release those features as they are ready. Our goal is to provide a new release of TDS every 4-6 months. The first release of a new year will receive a major version number increase, while subsequent releases that year will receive a minor version number increase. TDS 3.0 will be released very soon and followed later this year by TDS 3.1 or even TDS 3.2. Next year will bring TDS 4.0, 4.1, and so on. Customers will receive these new releases at no additional charge as part of their ongoing maintenance agreement. As needed, maintenance releases will be provided between release cycles to address issues that might arise in the software.
All these years of working on the rebuild of TDS are not in vain. We still have that code and are very pleased with the results of what we have built so far. Much of that work has already made its way into TDS 3.0, and more will be integrated over time. Each new release of TDS will bring us one step closer to the future we always imagined. We are committed to this product and look forward to the journey ahead.
A New Invitation
We want to thank all of our many devoted users of TDS who have shared their ideas and experiences with us over the years. We build this software for you, not for ourselves. Your voice has a direct impact on the software we develop and put into your hands, and we want to hear your ideas. Don’t leave us guessing about how you want to use the software. Your exact individual feedback will be directly read by every person working on this software and not simply aggregated into metrics or reports. You have a real opportunity to directly influence a piece of software you use every day and further improve your own productivity.
And now, we would like to invite you to try out the Technology Preview of TDS 3.0. The pre-release is currently invite-only, so please contact us if you are interested in evaluating the software. It has been too long since a major release of Test Design Studio, and we are anxious to step into this new era. You can install TDS 3.0 on the same machine as TDS 2.5, so you can evaluate the pre-release while continuing to use the last official release.
The foundation has been set to continue to iterate on TDS and carry it into the future. The new journey begins now with the technology preview, and we hope you will join us.
One of the most beneficial features of Test Design Studio is its ability to statically analyze your code and warn you of potential pitfalls. We want to highlight two of the new rules that are coming to the next release of Test Design Studio.
The error handling capabilities in VBScript are pretty limited, but still necessary. Using the statement ‘On Error Resume Next’ within your code is often unavoidable, and this statement is easy to abuse. We have added two rules to assist with the use of this statement:
The “Use error handling with caution” rule is very simple. Any use of ‘On Error Resume Next’ will be flagged as a warning by code analysis and you will need to manually suppress it. Ideally, your suppression comment will also indicate why you used the statement. This rule will help raise awareness to the dangers of not using the statement properly.
The “Close error handlers in routines” rule attempts to make sure that if you turn on error handling in a routine (using “On Error Resume Next”), you also turn off error handling before exiting the routine (using “On Error Goto 0”). It is not uncommon for a code author to turn on error handling within their routine to deal with a specific usage scenario, and then forget to turn it off before leaving the routine. Any calls to this routine will inadvertently turn on error handling without the callers knowledge. This can lead to unexpected code execution.
Already a Success Story
I was recently working with a client to help determine why a certain test was running in an infinite loop after a replay error. Not only was the script not failing gracefully, it was delaying the entire test suite by not freeing the lab machine for other tests to execute. I loaded the test and it’s relevant libraries into Test Design Studio with these new rules enabled, and Test Design Studio quickly located the needle within a haystack of over 100,000 lines of code.
A custom user function registered on a test object had set “On Error Resume Next” without turning it off. Later in the test, a “While” loop was processing that was encountering an error with the condition statement of the loop. Instead of failing the loop, “Resume Next” meant it continued with the next line of execution… the first line within the body of the loop! The errors continued through the loop until the “Wend” token instructed execution to return to the top of the loop and reevaluate the condition.
This process repeated until remote execution of the test was forced to terminate, but not until after more than 30,000 steps had been sent back to Quality Center/ALM for the last run. Since QC/ALM likes to show you the steps of the last run when you select a test instance in Test Lab, it also locked up QC/ALM while it attempted to process all those steps and eventually failed due to an out of memory condition. The steps had to be manually deleted from the database to restore functionality.
All this work because someone forgot to restore error handling functionality! With these new rules, hopefully that will never happen again!
Today marks the end of Mercury/HP WinRunner support in Test Design Studio, and the end of era for our products. Our Test Design Studio product of today exists only because of the early days using WinRunner. So how did we get here?
I began my career in test automation when WinRunner 6.0 had just been released. To show how far we have come, that was the first version of WinRunner to support syntax highlighting of keywords! WinRunner was a powerful automation tool, but used a proprietary language called Test Script Language (TSL). While based on ANSI C, it was still unique in the market. Being specific to WinRunner also meant you would not find much, if any, third-party support for the language.
In those early days, functions were king! Libraries of functions were amassed in “compiled modules”, and you had to create special startup scripts just to load all of those libraries to make them available for your tests. Keeping up with those libraries was the inspiration for one of our first software tools… Function Browser!
We published this utility as a download on the Mercury support website, and it quickly became one of the highest rated tools you could download (along with our stand-alone GUI Map Editor utility). You could browse all of your compiled modules and Function Browser would parse out what was available and even provide a code viewer. There was only one problem… you still had to edit your files in WinRunner.
We decided to create a more robust version of our utility that would allow full editing, and Function Manager was born.
Not only could files be edited, you had great control over your editing environment and tool windows abounded with detailed information for all of your libraries. You could even enter specially-formatted comment headers for your functions that could be parsed to expose more information about your declarations. Function Manager provided a great extension to our original utility, and was the first commercially available product we offered.
Not long after the release of Function Manager, a new product began to emerge… QuickTest Professional. The early release of the software was missing many of the features that made WinRunner such a great tool, and it was largely ignored by existing WinRunner users that didn’t have a specific need for the new object-based approach. Those of us who waited were rewarded because the early release of QuickTest Pro was not pleasant. I first began seriously using the product with QuickTest v6.5, and even then was immediately disappointed at the limited editing environment offered by the early IDE.
Around this time, the .NET Framework was still in the early stages, but had great potential over Visual Basic 6 that was used for our current products. With no upgrade path from VB6 to .NET, I had already started duplicating our Function Manager product using .NET. With the knowledge that the QuickTest IDE was severely lacking, I decided to apply our Function Manager process to QuickTest Professional and the VBScript libraries.
This early product was called Script Manager, and was only used internally as I experimented with functionality. It did not take long to have syntax highlighting and full IntelliSense for the new VBScript-based files. The tool even managed to provide a feature only recently added to the QuickTest Professional product itself… editing multiple scripts at once!
While working on Function Manager and Script Manager in .NET, the newer releases of Microsoft Visual Studio at the time were really beginning to shine and expand on an already great editing experience. Switching between the Visual Studio IDE and the QuickTest Professional IDE was jarring. I could tell a significant drop in coding productivity when using QTP compared to Visual Studio, and this lead to constant frustration. This was not something I could tolerate, and something had to be done.
This is when Function Manager and Script Manager merged into Test Design Studio… an IDE that bridged the great functionality and productivity of Visual Studio with the runtime capabilities of both WinRunner and QuickTest Professional. Many users were still using both automation platforms at the time, and Test Design Studio was a single IDE that provided support for both applications. What started as a simple way to parse TSL function declarations for WinRunner eventually grew into the feature-rich client we have today in Test Design Studio. While I always hoped the tool would be well-received by the community, I was never prepared for the run-away success it has become!
As we prepare Test Design Studio for the next phase of it’s life, we just finished removing the final lines of code that supported WinRunner. Much of that code was some of the first .NET code written for Function Manager. The old language parsing framework is not compatible with the new direction of the tool, and it’s time to let go of the past. Anyone I talk to who experienced the early WinRunner days feels like something is missing in our current environment. It was a great time, and we had a great community. I look back fondly on the experience I personally had building test automation with WinRunner and the journey it started for me and this company.
A new book titled “QuickTest Professional (2nd Edition)” is now available from author Vinnakota Ravi Sankar. I was honored to be asked by Ravi to write the foreward for this book. Instead of writing a separate review for the book, I feel the foreword I wrote sums it up. It is included below as a review.
You can purchase the book on Amazon. Before you ask, I did not receive and will never receive any compensation from the sale of this book. I hope many of you find it useful.
From the Foreward
When I first learned QuickTest Professional (QTP), my only resource was the documentation provided with the software. This primarily consisted of a tutorial and reference guide. Having been a WinRunner user for many users (the functional testing tool replaced by QTP), I was able to draw on that experience to translate my knowledge to the up-and-coming product. Even with that background, I was not certain how Actions would fit into the function-based frameworks I used in WinRunner. VBScript, the scripting language behind QTP, also opened up a world of new opportunities for programming my automated tests. There were no “best practices” because the tool was too new, and certainly no reference books available. I had many questions, and access to few answers.
Fortunately, the landscape of knowledge around QTP has dramatically changed, and this book is a prime example of the fantastic resources new users have available. Help files and user guides typically offer a narrow view of the product features with basic information and maybe a brief example. This book will take you further by introducing those topics from the viewpoint of an experienced user. Topics are littered with discussion about the feature and many verbose examples are provided to further drive home the message.
Part I of this book focuses on QTP and the many features that fuel this powerful tool. New users of QTP will especially appreciate the first half as it takes you through a tour of the functionality that will guide your automation efforts, but even experienced users may learn something new. The second half caters to more experienced users by diving deeper into the concepts of the tool and illustrating those topics through extensive discussion of real usage scenarios with detailed samples and case studies. Presentations of best practices and automation frameworks will help you lean on the experience of the author to get your automation project started quickly and efficiently.
Part II of the book shifts its focus to VBScript. QTP users quickly realize that you need to learn VBScript in order to effectively use QTP. The fundamentals of this scripting language are an essential skill, and this book demonstrates not only the features of the language, but how you can use it specifically to solve many of the challenges we face in test automation.
You have the opportunity to read an unbiased account of QTP translated from years of experience. Today’s QTP user does not have to be left with unanswered questions. While the book primarily focuses on version 9.2 of QTP, it also highlights version-specific features and spends several chapters discussing the evolution of the tool through version 11. In the end, readers will have a single reference that covers many topics from beginner to expert.
Most users of Test Design Studio are already familiar with the benefits you gain from incorporating VBScript Class objects into your code. Using classes helps organize your code and improve comprehension.
In the next release of Test Design Studio 2, we’re making it even easier to add classes to your projects with a new ‘Class Definition Library’ template. Item Templates are used to generate new content for your projects. This powerful feature allows you to generate files with pre-defined content and are highly customizable to meet your individual needs (read more in the on-line documentation).
In the screenshot above, we have selected the ‘Class Definition Library’ template, and will name our file ‘Person.qfl’. The class we are creating in this example will be to represent a ‘Person’ object, so we are naming the file to correspond to the class we are creating. This name means more than just the name of the file, the template will use this name to generate the contents of the file as well. Below is the generated template:
In the screenshot above, we have highlighted all the areas where the name of the file, “Person”, was used in the dynamic generation of the class code. By naming the file the same as the desired class, we are able to quickly generate a lot of the code that you would normally have to manual type.
A quick tour of the base template code…
Lines 4 – 36 include the class declaration itself and corresponding comments.
Lines 12 – 20 provide the skeleton to insert any code that should be executed when the class is created or destroyed.
Lines 22 – 34 include “Region” markers for outlining support of Properties and Methods that you define with your class. Note that the comments remind you to use the code snippet features of Test Design Studio to quickly generate the members of your class (read more about code snippets if you aren’t familiar with this time-saving feature).
Lines 39 – 46 include a public function to instantiate and return a new instance of your class and the corresponding documentation for the method. Some versions of QuickTest Professional have a limitation where you cannot use the ‘New’ keyword to create instances of classes that are defined in external libraries, so this trick helps resolve that issue. Note how the name of the class is used multiple times in this code block to produce the necessary function… great time-saver!
Now that you have a new class, you can easily make this class available to all the tests in your project by using the Build Process to programmatically update the library references for your tests.
While we’re happy to include this built-in template with the next release of Test Design Studio, there’s nothing to prevent you from creating your own templates right now.
Test Design Studio already comes with a built-in file difference viewer, but, admittedly, there are better tools available from vendors that focus specifically on that feature. In the next release of Test Design Studio 2, you can configure the use of 3rd-party software for file comparisons.
Select “Tools –> Options” from the main menu and navigate to “Environment \ Documents”.
In the screenshot above, you can see where we have configured Test Design Studio to use Beyond Compare for file comparisons.
Important Note: QuickTest Tests are not files, but rather folders that contain many different files. When performing a comparison for QuickTest tests, the path of the QuickTest folder will be passed to the external command. Most utilities will then perform a folder-based comparison where you can drill down on individual files.
The next release of Test Design Studio 2 will introduce a new feature: column guides.
In the screenshot above, you can see a red line displayed vertically at column position 120. These guides help serve as a visual aid to avoid lines of code that are potentially too long. The longer a line, the more horizontal scrolling someone must perform in order to see all the content. While comments are generally accepted as long lines, long statements can lead to difficult comprehension of code.
This new setting is activated by selecting “Tools –> Options” from the main menu and locating the desired file language:
You can toggle the column guide and its position for each supported language, or use the “All Languages” setting to make the value consistent.
You can also control the color. Within the same options menu, navigate to “Environment / Fonts and Colors”.
The “Column Guide” display item will allow you to change the color. You can use the same color for all editors, or pick a different color for individual editors.
This is an example of a user-requested feature that has now been implemented in the product. You can always share your ideas as well!
Test Design Studio has a macro feature that allows you to record a series of edits made in a document. You can then playback that macro at any time to repeat the same edits. As macros are recorded, they are stored in the Toolbox tool window.
While you can always execute the macros from the Toolbox, sometimes you want to execute the commands without taking your hands off the keyboard. The next release of Test Design Studio 2 will make this possible.
New Macros Commands
Test Design Studio also has an extensive command system that can be used to customize toolbars and assign keyboard shortcuts to commands. By selecting “Tools –> Customize” from the main menu, you can access the powerful command system.
The new commands are under the “Tools” category and are called “Run Macro 1” through “Run Macro 10”. You can find these commands on the “Commands” tab if you want to add one of the commands to a menu or toolbar. Simply drag the command (e.g. “Run Macro 1”) and drop it where you want it on a menu or toolbar.
Perhaps more importantly, you can also assign keyboard shortcuts to each command on the “Keyboard” tab of the “Customize” dialog. The full name of each command is “Tools.RunMacro1” through “Tools.RunMacro10”. If you type “RunMacro” in the “Show commands containing” textbox, the command list will be filtered to only include the “RunMacro” commands.
Once you find the command to which you want to assign the keyboard shortcut, click the “Press shortcut key(s)” to place focus on that textbox and then type your shortcut using the keyboard. The shortcut you type will be displayed in the textbox. If you like what you see, press the “Assign” button to assign the shortcut.
Assign Macro Command to a Macro
To tie everything together, you must now assign one of the ten macro commands to the desired macro. The assignment is done by right-clicking the desired macro in the Toolbox tool window and expanding the “Assign to Command” menu.
Pick one of the available command slots to assign to the macro. If the command is already assigned to another macro, the name of that macro will be reflected in the menu.
Once assigned, any time the command is executed, the corresponding macro will be played in the current editor document (assuming a document is open that supports macros).
This feature was the direct request of a Test Design Studio user that we are happy to make available to everyone. If you have an idea for how the tool can serve you better, let us know and we might be able to make it happen!