We are pleased to announce that Test Design Studio 4.0 is now generally available and can be downloaded here.
This release continues our push to re-architect and modernize the back end code of the application while also moving the front-end away from Windows Forms and toward Windows Presentation Foundation with a modern look-and-feel. The tool windows for Output, Server Explorer, and Toolbox were all converted in this release. Even the splash screen saw the first update since v2 with a flatter design.
The following are some highlights from the 4.0 release
We’re very excited about this feature. So excited, in fact, that it gets its own blog post!
Floating Document Windows
Those with multiple monitors know how convenient it can be to float your tool windows on a secondary monitor while leaving Test Design Studio on a primary monitor, but document windows were also bound to the main window. Not anymore! You can now drag the document tab outside of the main window to float it, or simply right-click the document tab and select ‘Floating’. When combined with the long-standing ability to dock document windows side-by-side in the main part of the application, you now have a new tool to customize your view to see exactly what you want and where you want to see it.
Disable Code Analysis Rule from Context Menu
We love the code analysis feature, but sometimes a rule just isn’t a good fit for your organization. You no longer have to dig through the options dialog to find the rule you want to turn off. If it shows up in the Error List and you don’t want to see it, simply right-click and turn it off. You can always turn it back on from the original Options dialog.
Sometimes it’s the little things. Many users were confused about how to get Test Design Studio connected to ALM or, even worse, didn’t know the feature was available. The Server Explorer tool window, when not connected to ALM, should remove all doubt about the capability and how to get started:
We even redesigned the login screen with a friendly reminder that you must register the ALM Client for the integration to work properly:
We also removed the special feature called “Offline Mode”. This was a carry over from functionality prior to TDS 3 where server connections were managed very differently, and it created a confusing interface. You no longer have to enter “Offline Mode” to work with any files offline. If you’re not connected to ALM, you’ll be in offline mode. Simple as that! We even added the option to have your credentials stored so that your ALM connection is automatically restored every time you launch TDS.
Now TDS even scans a project before you open it to look for any ALM files and will prompt you to connect to ALM before opening (with the option to cancel) so that you are not presented with errors opening the files.
All customers with an active maintenance agreement will receive this upgrade at no change. Users with a Seat License will need a new serial number for this version and it will begin with "TDS40-". Users with a Concurrent License will not need to modify their License Server, but will need a new client license file to use along with the new version.
Please contact email@example.com if you are ready to upgrade and have not already received your new license.
The feature we’re most excited about with TDS 4.0 is support for naming conventions. Most of us work on teams that contribute to the same code base. It is important that the unified product of that team’s effort be presented consistently no matter who contributed the code. Choosing to name variables or functions a certain way can make your framework more cohesive and easier to use by everyone.
By default, Test Design Studio comes pre-configured for the most basic naming conventions around character casing for language elements. These defaults are based on generally accepted industry norms for VBScript and include:
- Variables and parameters start with lower-case letter and capitalize each new word.
- Functions, subs, and properties start with upper-case letter and capitalize each new word.
- Class names start with upper-case letter and capitalize each new word.
- Constants use all upper-case letters with underscore between words.
The following illustrates a Sub whose name begins with a lower-case letter instead of upper-case
The violations for naming rules are displayed in the Error List along with any syntax errors and code analysis feedback. Each violation is also underlined in the editor with green “squiggles” to draw attention to the oversight.
These default rules are a great start for naming conventions, but individual policies at your organization are likely far more complex. Since every organization is different, we designed this feature from the beginning to be user-driven. All naming conventions are based on a series of rules in an XML-formatted file. We’ve provided a powerful set of criteria to help you define your individual conventions. We’ve even provided a working sample of a much more complicated rules file that you can use as a template for your own rules (look at ‘CodeAnalysis\rules.sample.typePrefix.xml’ under the TDS installation directory).
Not only can you define different rules based on item type (e.g. Sub, Function, Variable), you can also define rules based on the content. Do you name integer variables one way and boolean variable another way? No problem! Different convention for public vs. private items? We have that, too!
You can change the location of the naming rules XML file in the same spot where you turn individual code analysis rules on/off by selecting “Tools –> Options” from the main menu.
While we’ve tried to prepare a solid foundation for the rules engine, we know our customers will be the truest test of when the feature is complete. We fully support the functionality, but are releasing it under a “Beta” tag for now. We’re confident in the core functionality for the default rules we have provided, but we need to hear from more customers about how they want to implement rules.
If you are unable to implement your naming conventions using our present rules engine, we want to hear from you! Please contact us with examples of the rules you want to implement. If we can’t make the current rules engine work, we’ll see what we can do to add the support your need.
We hope you enjoy this new feature, and look forward to hearing your feedback.
With the recent release of Unified Functional Testing 14, we are happy to report that Test Design Studio continues to be fully compatible with the latest version. In fact, it doesn’t appear that the core GUI Test functionality has changed at all… and hasn’t for years! That should speak volumes about how much this manufacturer cares about those who still write code for UFT, but that’s why we have Test Design Studio anyway!
We woke up to a nice little surprise a few days ago… our web host of 10 years had mysteriously started turning off our servers! First to go was e-mail delivery, and that’s what tipped us off to the problem. It turns out our web host had migrated our account to a new platform a couple of months ago, but failed to tell us. Not only did communication fall apart, their migration was a total failure. They copied some files… that’s about all the credit they get. None of our web services worked, the server was configured incorrectly, our database was empty, and their control panel tools were useless!
After juggling support from multiple contacts, we quickly realized this was a situation we never wanted to be in again. We abandoned any effort to get our site working on their new platform and looked for greener pastures. And boy did we find them!
A Brave New World
A lot can change in 10 years. When it comes to technology, 10 years is like a lifetime. Needless to say, the landscape has improved greatly! We settled on building all new web apps on Microsoft’s cloud computing platform, Azure. The service is amazing and highly recommended for anyone looking for web hosting. We’ve also migrated our email handling to new Microsoft-powered cloud services, and everything is working great!
How Does This Impact You?
For the most part, there is no impact. The same web address gets automagically ported to our new servers. We’ve tried to re-write any old URL’s that were no longer valid, so those bookmarks will keep working. Two important aspects did change, however.
We needed to relocate some of our web services into stand alone web apps. This is a much better design, but does break compatibility with prior applications. Most importantly, this impacts web-based license activation. The “check for updates” feature will also stop working, but you will continue to get news alerts on the Start Page.
Test Design Studio v3.0.7020 and higher will support the new server, and you can download it now. All users who have ever owned a license to v3.0 will be able to upgrade to this release even if your maintenance has expired. **There is not an upgrade path for Test Design Studio v2.5 or prior releases!** You will still be able to activate your licenses, but the activations will need to be performed manually. Contact firstname.lastname@example.org if you have concerns about applying any legacy licenses or if you want to explore options to reinstate your maintenance.
The Concurrent License Server is also impacted by the change to the licensing service, and we will be working on a fix in the near future. Concurrent licenses of Test Design Studio will continue to operate without issue on an already activated Concurrent License Server instance. If you have immediate license activation needs, please contact email@example.com and we will make sure your request is handled.
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 firstname.lastname@example.org 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 email@example.com 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.
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
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!