While creating or debugging a Process, you typically run it multiple times to verify proper playback. If you also have the “Open Results After Run” option enabled, the document area can quickly become cluttered with too many open results. Most users typically don’t care about keeping these development results around for longer than a single run, but it is easy to forgot to close the results before the next run. You can always turn off “Open Results After Run”, but then you might miss important details.
Thinking about this scenario, the ideal solution is to open the results after each run, but automatically replace those with new results on the next run. This is exactly what Preview Results enables.
When enabled, any results after a run are opened in Preview Mode and will appear as a special tab on the right of the document tab area as shown below:
The document tab is a different color from non-preview documents and contains a special “Keep Open” button on the tab.
If you want to keep the results open, clicking the “Keep Open” button will exit Preview Mode and the results will stay open until you close them. If you leave the results in Preview Mode and run a process again, the prior Preview Results will be automatically closed and replaced with the new results.
The Preview Results feature allows you to keep your document area clear of unwanted results while giving you full control to retain the results you need.
This setting is on by default, but can always be disabled under “Options –> Run” by clearing the “Use preview mode” setting under “Open results after run”.
We continue to iterate quickly on bringing new functionality to AutoBloks, and the latest release (19.1.1) adds two important new features… environment variables and “on error” playback control for when an activity call encounters an error.
One of the more important aspects of a successful automation strategy is to separate your data from the steps you perform. With AutoBloks, you accomplish this through the use of variables. Until now, all user-defined variables had to be defined on a per-process basis. If you have several related processes that all need the same data, this could result in unnecessary duplication of variables across those process and, most importantly, introduce a high degree of maintenance if the value of a variable needed to change. Environment variables are here to specifically address this scenario!
Environment variables are defined in XML-formatted data files. Each file represents a single variable repository, and you can instruct AutoBloks to load one or more of those repositories. Once loaded, the variables defined within each repository will be available to all of the processes you execute.
The following screen shot shows how easy it is to define your own environment variables. In this example, you can see a basic XML document which defines a single variable called “PattersonConsultingUrl”. The Options dialog of AutoBloks is used to add this file as a variable repository. Once added, the Variables tool window will include this repository and defined variables under the “Environment Variables” category. This new variable is now access to you just like all the other built-in and user-defined variables.
Tip: This file format is intentionally the same as the file format used by Micro Focus Unified Functional Testing, so you can easily share your data between the tools.
While not shown above, you can also define a “Category” property for your variables to better organize large repositories of data. For more information on using variables, refer to the AutoBloks On-line Documentation.
On Error Playback Option
No matter how hard we try to avoid them, playback errors are inevitably going to happen. For each Activity Call, you have a new option to control how AutoBloks will respond to errors.
- Show prompt with options – This is the default behavior and is how AutoBloks has always behaved up until now. The user will be prompted with a dialog to retry, continue, or stop.
- Stop running – Log the error and stop further execution.
- Continue to the next activity call – Log the error, but try to continue the execution.
These additional options allow you to refine the behavior of a process to better handle situations where errors are expected and you want to perform a specific action without the delay of being prompted.
We’ve known from the beginning that AutoBloks needed to support more advanced error reporting than just letting you know if you forgot to populate a required field. We are excited to announce that AutoBloks 18.12.1 is now available and brings support for a comprehensive rules-based engine that allows for the reporting of errors, warnings, or other informational messages based on how you use the tool.
Errors tend to be the types of problems that, when left unresolved, will cause issues if you try to run your Process. In fact, if you try to run a Process that has errors, you will get a dialog prompting you if you really want to run it.
Warnings, on the other hand, tend to be less severe. They should not be ignored, but also should not cause a Process to fail playback.
Messages are purely informational in nature.
Meet the Error List Window
NOTE: Users upgrading from a prior version of AutoBloks may not see the Error List tool window by default since your previous layout (without that window) is being restored. You can use the View tab of the Command Ribbon to select the Error List command from the Tool Windows group, or, from the same View tab, select Restore to Default from the Layout group to apply the new default layout.
This new tool window provides a central location to view and manage any potential problems. The tool bar at the top allows you to filter the view to only show the items that interest you. Specifically, you can control if the list only shows problems from the Current Document (i.e. the document you are actively working on) or Open Documents to see every possible problem from all open documents.
Additionally, each message type can be toggled on or off. If you only want to see Error messages, for instance, you can toggle off Warnings and Messages.
Each problem in the Error List also has a context menu with the available actions:
- Go To Location – When available, this command will adjust the selections within AutoBloks to highlight the source of the problem and move focus to the relevant control (Tip: This is the default action and will be executed if you double-click the item in the Error List)
- Show Help – Most commands should have a help page associated with them, and this command will open the corresponding page in your browser (Tip: The Code value in the Error List is also hyperlinked to open the same page quickly)
Error and Warning Indicators
As you use the application and introduce Errors or Warnings, you will see indicators appear throughout the user interface to help draw your attention.
Activity Call List
In the Activity Call list, small overlay icons will appear in the bottom-right corner of the standard Activity icon. When you see one of these icons, it means one or more of the corresponding problems is present in the configuration of your Activity Call. You can either look at the Error List window to review the problems or select the Activity Call to populate the Instructions pane and drill down into the issue. The following shows a Warning on the “Start timer” activity and an Error on the “Verify expression value” activity.
When defining the Instructions of an Activity Call, there are multiple tabs where details may be provided. Tabs will have a Red or Yellow indicator on the relevant tab if Errors or Warnings on present on the controls within that tab. The following shows there is an Error on the Arguments tab:
Individual controls will also have a Red or Yellow indicator next to each control with one or more problems.
If you hover the mouse over the indicators, a tool tip will display the details of the first problem and indicate if other problems are present as well. The following shows a tool tip for a control that has two errors:
The body of the tool tip displays the message for the first problem. In the footer, the text “(+1 more)” indicates that 1 additional error has also been detected and will be available in the Error List tool window.
The initial release includes rules to cover the most common problems that might arise while using AutoBloks. The full list of rules is available here. A summary of key functionality provided by these rules includes:
- Required fields for arguments and element identification must be populated
- Expression syntax must be used correctly
- Variables used within expression syntax must exist
- When arguments expect certain values or data formats, the input must match the expectation
This is just the beginning! We spent a lot of time developing a rules engine that is very flexible and, as a result, we can easily add new rules to expose additional information to the user. Have an idea for a rule you’d like to see implemented? Please contact support and share your idea.
Resolving errors is so important to successful automation that we have included some other hints in the user interface as well.
If the Error List tool window has any errors that match the current filter settings but the tool window is not selected, the tab will “glow red” (fades in an out). In the following screen shot, the “Output” tool window is selected and the “Error List” tool window is tinted red to indicate errors are present:
The following shows a button that will appear on the right edge of the status bar if any errors are detected. This is a total count of known errors and is not impacted by the filter settings of the Error List tool window. Clicking the status bar button will activate the Error List tool window.
Say “hello” to AutoBloks! Earlier this year, we set out to build a new automation tool, and the initial offering from that journey is officially launching today with support for web automation through Chrome, Firefox, and Internet Explorer. With so many automation tools already on the market, you may be asking “why build yet another automation tool?” We believe the answer to that question is easy… too many people who could be using automation simply are not doing so. The tools have been around for decades, so why aren’t people using them? Answering this question is a little harder than the first and there is surely no one answer, but we believe a big part of the problem is that the tools don’t fit the users.
While functional testers in a QA department are part of an IT organization, that does not automatically grant them the technical skills of some of their IT colleagues. Automation tools are often complicated or unapproachable to these users, so they keep doing their work manually. This is the user who is underserved by automation tools on the market today and are exactly who we believe can benefit the most from AutoBloks.
What About Keyword-Driven Frameworks?
For many years, the solution to the complexity of automation tools has been for a team of advanced users to create keyword-driven frameworks. Users of any skill level could then use familiar tools, like spreadsheets, to build their automation from a series of keywords established by the automation team. A special driver script, written in the automation tool itself, could then read these keywords one-by-one to perform an action corresponding to each. This is a great concept because it allows a small team of expert users to handle the complexities of automation while enabling a much larger group of users to translate their business knowledge into automated scripts.
While the concept is great, the execution is often flawed. The initial set of keywords is rarely enough, so users are frequently asking the automation team for more support. As the number of keywords grows, it becomes more difficult for users to know which keywords are available or to fully understand what each keyword does. Most keywords cannot properly execute without one or more arguments as input, so users now must understand which data is required, the types of data allowed, and how to populate it. That’s even before you try to tackle having the output from one keyword be used as input on another. Automation is also an iterative design process (try, fail, fix, repeat), so users are not removed from needing to use the original automation tool. What starts as a solid effort to improve automation then turns back into the exact problem they were trying to solve in the first place… a complicated automation solution.
AutoBloks builds on the great concept of a keyword-driven automation framework while addressing many of the shortcomings. First and foremost, users are given a tool purpose-built for automation at any skill level and not asked to use spreadsheets, text editors, or other tools designed for anything BUT automation.
Relying on an automation team is a bottleneck, so we have given the user all the power. Keywords are presented in AutoBloks as categorized Activities. Each one has a description of what it does and the arguments, if any, are clearly defined with all the details the user needs to know. Users simply drag-and-drop the needed activities, populate any arguments, and move on to the next activity. When it comes time to test what you’ve built, you do so directly in AutoBloks. Run your process from end-to-end, step over activities one-by-one, or set breakpoints to pause at a certain step. If your playback fails, AutoBloks will let you retry the activity, skip over it to continue, or stop playback completely. You can even correct a bad activity before retrying it, so you don’t have to start all over again!
Just the Beginning
This is, quite literally, just the beginning of AutoBloks. There are many more capabilities we want to add to AutoBloks but believe what we have today can already address the automation needs of many. In the near future, we will be adding support for important automation concepts like centralized element repository and reusable activity blocks (i.e. user-defined functions). Of course, we will also be expanding the list of built-in activities to provide more and more functionality out-of-the-box. It is going to be a long journey, and one we are excited to continue.
FREE Community Edition!
We are delighted to make this new product accessible to non-enterprise users who may not have otherwise had access to automation tools. Individuals, non-profits, and small businesses (under $1 million of annual revenue in US dollars) can all download and use the Community Edition of AutoBloks completely free! Absolutely no strings attached, although we hope the community will share their feedback with us and help us build a better product for everyone.
Go ahead and check it out today, and please let us know what you think.
Run Code Analysis from the Command Line
This is a big one! The Code Analysis functionality of Test Design Studio is perhaps the most important functionality in the tool, and this one little update opens up a world of new possibilities. You can now trigger Test Design Studio to load a Project or Solution, analyze the code, and export the results… all from the command line without having to interact with the user interface! Of particular interest, this should enable you to integrate Test Design Studio into your DevOps pipeline.
TestDesignStudio.exe "C:\TDS Solutions\MySolution.tdssln" -Analyze "C:\Results\MySolution.Analysis.csv"
The above loads a solution called “MySolution.tdssln” and outputs the analysis results to “MySolution.Analysis.csv”, a comma-separated values file. This standard format can be opened in Excel or parsed by any number of 3rd-party solutions.
We started with CSV because that format was already supported by Test Design Studio using the File –> Export -> Excel option from the main menu, but more formats can be supported. If you need a different format, please reach out and let us know what you are looking for. If you have any challenges integrating Test Design Studio with your DevOps platform, we’re ready to work with you and make sure you get the functionality you need.
Naming Convention Rules Change
The naming conventions feature allows you to create a series of rules that are applied to named declarations in your code to make sure you are following a standard naming convention. Use our built-in rules or create your own! With this release, we changed how the “Matches” rule looks at regular expressions to ensure the expression fully matches the given term. Previously, the ^ and $ characters were added to any pattern that did not include them to ensure a full match, but this caused issues with some alternation patterns. Those characters are no longer added to your pattern and, instead, we now make sure that the length of the pattern match is the same as the name being verified. Make sure any regular expressions you define will fully match the entire name to be successful.
If you are using our built-in rules, your files are automatically updated with this release. If you copied our rules or created a new one of your own, make sure you look at the changes in the macro patterns we define in our rules so you apply the same to your own files. If you modified the built-in files without copying them to a new location, your modifications will be overridden by this update. Please make sure you are maintaining your edits outside of the application installation folder to avoid future overwrites.
We always included an introduction to the Incremental Search feature in our getting started walk through, but it never had a dedicated help topic until now. For those that skip the walkthrough, you might have missed out on this great productivity booster. As a reminder for those who missed it, Incremental Search allows you to quickly and easily navigate to matching search terms in the document, all without removing your hands from the keyboard or loading a blocking UI element.
To begin Incremental Search, press the keyboard shortcut Ctlr+I to start searching forward, or Ctrl+Shift+I to start searching backwards. The status bar will then display “Incremental Search:” or “Reverse Incremental Search:” to match the shortcut you pressed.
With Incremental Search active, begin typing your search term. The characters you type will not be entered in the editor, but, instead, will be used to define the search. As each character is typed, Incremental Search will move the selection to the first match and the status bar will be updated to display your search term to help confirm what you have typed (e.g. “Incremental Search: MySearchTerm”). If at any point you have typed a term that is not matched in the text, the status bar will display “(not found)” after your search term.
Once you have defined your search term, you can easily navigate to all the matches for the same term. No matter whether your started with Ctrl+I or Ctrl+Shift+I, pressing Ctrl+I while Incremental Search is active will move forward to the next term, and Ctrl+Shift+I will move backwards to the previous term. Continue issuing either of these keyboard shortcuts to navigate through all the matched terms.
Incremental Search mode will be automatically cancelled if you change the selection with mouse or keyboard. You can manually cancel Incremental Search with the Esc key.
If you’ve never tried Incremental Search, you owe it to yourself to give it a shot. Try performing Incremental Search for the term “dim” to quickly jump between all your declarations, or enter the name of a variable to cycle through all the places it appears in the file. Once you see how easy it can be to perform these simple navigations, you’ll wonder who you ever lived without it. We put together a quick 2-min video highlighting the feature. Check it out!
We are pleased to announce the availability of Test Design Studio 4.5 (Build 7220). You can see the change notes and download now. There are two notable changes in this release that we want to highlight.
Goodbye .NET Framework 3.5
With this release, we were able to remove the final components that were forcing us to keep a dependency on .NET Framework 3.5. This is particularly nice for our Windows 10 users who would have to enable that feature in Windows if not already turned on. You will still need .NET Framework 4.5.2 (or newer). Windows 7 and Windows 8 users will still need to install the .NET Framework, but Windows 10 users should already have what they need since even the first release of Windows 10 included .NET Framework 4.6.
Next/Previous Declaration Commands
These commands have been missing since Test Design Studio 3, but now they’re back and better than ever. The restored
Edit.PreviousDeclaration commands allow you to easily navigate to major declarations in your file. They intentionally do not stop on every declaration, only the major ones. Those include:
- Script-level function/sub declarations
- Class declarations
- Class-level public variables
- Class-level function/sub declarations
- Class properties
The default shortcut for “Next” is
CTRL+SHIFT+Right Arrow, and “Previous” is
CTRL+SHIFT+Left Arrow. We created a quick 90-second video highlighting the new commands so you can see it in action.
We are pleased to announce that Test Design Studio 4.5 is now generally available and can be downloaded here. Much like version 4.0, this release continues our journey to modernize the application by shifting away from .NET Windows Forms toward Windows Presentation Foundation (WPF). While there is still a lot to migrate, we have completed the migration of all Tool Windows to WPF.
As noted in the introduction, several windows were converted to WPF for this release. Those include:
- Find and Replace tool window
- Find Results tool window
- Object Browser tool window
- Bookmarks tool window
- Solution Explorer tool window
- Task List tool window
- ALM Version History dialog
The end goal is to convert the entire application to WPF as that platform provides more flexible UI options and will better support hi-dpi monitors that are becoming more common today.
Search Solution Explorer
The WPF update enabled us to implement one of our favorite new features of this release, Search Solution Explorer. This feature adds a search box at the top of solution explorer. As you type, the entries in Solution Explorer are filter to only include the items that match your filter. In projects with a lot of files, this can help you quickly navigate to the file you are looking for.
The picture below shows a side-by-side view of a project open in Solution Explorer. On the right, the search term “check” has been entered in the “Search Solution Explorer” box, and the content of Solution Explorer has been filtered to only show items containing the text “check”
Error List Column Updates
The error list now supports two new columns of data, Code and Path. Description and File were also updated as noted below.
The Code, which is used to identify a code analysis rule, was previously displayed as part of the description, but has now been separated for display in a dedicated column. Not only does this make it easier to sort, the value of the code is now hyperlinked to help about the particular code if you are unsure why Test Design Studio is making a recommendation.
The File column previously displayed the full path of a the file. This has now been separated into two columns, Path and File. The Path will display the folder location, while File now only displays the name of the file. This helps reduce visual clutter when file path is not important, and can also make it easier to sort errors independently by either location or file name.
Object Browser Parameter Details
VBScript does not support overloads directly in the language, but many of the built-in functions provided by VBScript do. When the Object Browser would repeat these overloaded methods, it was not clear which entry matched which overload.
The member list has now been updated to show the type of data passed as parameters to each method call. As seen in the picture below, it makes it easier to determine which overloaded method matches a particular parameter signature, and the faded color of the data helps keep emphasis on the function name itself.
Task List Filter to Active File
This feature has been available on the Error List tool window for a while, so this release brings “Filter to Active File” to the Task List tool window as well. When activated, the Task List will only show entries that are related to the currently selected file. This allows you to stay focused on the file at hand.
Output Window Provider Filtering and Output Buffering
The Output tool window provides a method for various parts of the application to provide textual feedback about a process. There is a drop-down to select which output you want to see. New in this release, we now only show entries in the drop-down list that are actually providing content in the current. The first time a provider publishes content, it will also become the active selection to make sure that content is easily seen.
Some output providers, like the one used when generating documentation, produce a lot of detail in the output window. Updating the UI with the new output could cause poor performance. We are now buffering the output so that instead of pushing updates on each new line, we are building a buffer of lines and only push updates about once a second. That may not sound like much, but Documenter could easily produce many lines of output a second. With the new buffered approach, content is still updated in near-real-time but without the performance penalties.
Open Help from Options
Test Design Studio has a lot of options to allow the end user to customize the application experience, and sometimes those options need a little explaining. A new “Help” button has been added to the Options dialog to allow you to open the Help file to the corresponding topic.
Cache COM References
Test Design Studio has long supported the ability to parse a COM library and provide rich IntelliSense when editing files. Unfortunately, some of the larger libraries can take a long time to fully parse. After a library is parsed, that data is now cached in a temporary folder for future use. On subsequent launches of the application, the cached data can be read significantly faster than returning to the original COM library. This greatly improves the time needed to launch a new instance of the application.
Built-in references rarely change, yet the Test Design Studio documenter was generating HTML pages for members of the built-in references every time you generated documentation with that option. This easily exploded the amount of time it took to generate documentation. These generated files are now cached as they are generated. On future documentation updates, any previously generated cache file will be used instead of re-creating the file.
We also identified a scenario where the XML data used to provide details about a project would duplicate some information for each project. This resulted in files that were larger than they needed to be, and could result in OutOfMemory exceptions when processing the data. Any data that can be shared between projects is now shared to reduce the file size.
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!