TestTrack allows you to set fields as required, which applies throughout the entire lifecycle of an item. Sometimes, however, you may want to set a field as required based on the workflow state or another field. You can use triggers to ensure a field has a value before it reaches a state, or to ensure a field has a value based on another field. In both instances, the mechanics are the same, and this applies to all development, test, and requirement artifacts tracked by TestTrack.
Share on Technorati . del.icio.us . Digg . Reddit . Slashdot . Facebook . StumbleUpontriggers
Automation in your process is key to reducing human error and delays. While automation also includes things like automatically assigning bugs to developers and setting fields to specific values based on certain conditions, I’ll talk about email notifications in this post.
Seapine ALM can send automatic notifications. Surround SCM and TestTrack can notify users when something happens under specific circumstances. In fact, Surround SCM 2011.1 introduces enhancements that provide more dynamic notifications, such as notifying the last user that checked in files, the user selected in a custom field, and more.
If notifications are not set up properly, you risk spamming your users with emails that are not of interest and just make noise. Before you know it, users set up a rule to route emails sent from Seapine ALM to a folder that will rarely be reviewed.
While the mechanics of notifications in TestTrack and Surround SCM are different, the following high-level best practices apply to both.
Share on Technorati . del.icio.us . Digg . Reddit . Slashdot . Facebook . StumbleUponEvery once in a while we get feature requests for new columns in the Surround SCM Source View window. Some of the most popular column requests are for the comments that were part of the last check in of a file, the last user who performed a check in, and the last defect number the file was attached to. (By the way, make sure you are submitting your feature requests. That’s the only way we’ll know about them.)
While all feature requests are reviewed, and may be implemented in a future release, we haven’t yet added new columns to the Source View. So, I’m going to show you how to use Surround SCM’s customer fields and triggers to create your own Source View columns.
Share on Technorati . del.icio.us . Digg . Reddit . Slashdot . Facebook . StumbleUpon
Custom fields allow you to define metadata you want to capture about a file beyond the normal information (like last date modified) that Surround SCM inherently tracks. Each field can be typed as text, integer, float, list, SCM users, date/time or check box. You can also set default values for any of these.
By themselves, custom fields let you do some useful things. For example, Surround ships with a custom field called Owner, which is a drop-down list of your users. As a team lead you can grab groups of design specifications and, with one click, assign those files to an engineer to manage.
Share on Technorati . del.icio.us . Digg . Reddit . Slashdot . Facebook . StumbleUpon
As a consultant, I have been exposed to many different development methodologies and processes. In most cases, assignments are performed by a person that is aware of staff resources and distributes tasks according to the availability of these resources.
Continue reading…
A common question I hear from TestTrack users is how to display a value that was entered as part of a workflow event on the main issue/test case/requirement window. As some of you may know, this is not “out of the box” functionality. However, this can be configured rather easily using automation rules and custom fields.
The only requirement is that the field on the main window has to be of type “String”.
Continue reading…
Escalation rules allow you to evaluate a certain condition on a continuous, scheduled basis. The most common use for escalation rules is to prevent inactivity on items. For example, every day at midnight, check for any items that have not been modified in the last 3 days. Escalation rules also allow you to configure an action or actions to perform on any item that matches the criteria, which is specified in the form of a filter.
Continue reading…
Our support group is commonly contacted with email notification problems. This can be tricky to troubleshoot because there are many moving pieces and it is difficult to isolate the cause. This post includes some troubleshooting tips I learned as a member of the support group.
Continue reading…
This post is a follow up to my first one about Surround SCM triggers and executables.
A few years back, while still working in support I conducted an experiment to really comprehend how executables work when they are launched by Surround SCM as part of a trigger. I wanted to know “where” the script runs, what it considers to be the “current” directory, and whether it depended on the location of the executable.
Continue reading…
Automation is a key part of any software configuration management tool. Without automation you must manually perform tasks, which only increases the chance of error. Surround SCM includes triggers that allow you to automate many actions, such as sending e-mails, changing a workflow state, and preventing actions under specific circumstances.
Most of the actions available in triggers are visually oriented. For example, to send an e-mail you can select the recipient(s) from a list, configure the e-mail template, etc. However, inevitably you will have needs beyond what is offered out of the box. In those situations you may want to consider running an executable through the trigger mechanism.
Continue reading…
