Automatic Notification Best Practices
Automation in your process is key to reducing human error and delays.
You can use automation to assign bugs to developers. Or set fields to specific values based on certain conditions. But one great way to use automation in your ALM tool is automatic notifications.
What Are Automatic Notifications?
Automatic notifications keep users up-to-date. These notifications are typically set up via email.
When to Use an Automatic Notification
You should use an automatic notification to update users if something happens under specific circumstances.
In Helix ALM, for instance, you can set up automatic notifications for:
- The last user who checked in a file (if the file changes).
- A user selected in a custom field.
But you shouldn't use automatic notifications for everything. So, follow these best practices when you configure yours.
Best Practices for Automatic Notifications
When You Assign a Defect
Waiting for a user to send an email about something that happened introduces unnecessary risk. The time between assigning the bug and notifying the user is time that the item is not worked on.
If you have specific SLAs that require addressing items in a short timeframe, you cannot afford to use manual notifications.
Once you have configured rules for notifications, let Helix ALM do the work for you. You'll eliminate the gaps in your process that are caused by relying on manual intervention.
Be Smart About Conditions
Some notifications only make sense under specific conditions.
Maybe a defect needs to be a certain priority, a requirement needs to be further along in the review process, or a file needs to be reviewed by a development team lead for possible bugs.
Trigger on the Right Action(s)
Certain actions under specific conditions should trigger an email.
The action could be an assignment, a test failing, a file checked in, or other event.
You can also combine automatic notifications with the ability to mark items as suspect using Helix ALM links. If a requirement changes, mark the test case linked to the requirement suspect (this could be automated) and have Helix ALM send an email to the test case owner to review the changes for possible modifications.
Here are some actions available for defect notifications in Helix ALM. Keep in mind that the options for events and states vary depending on the workflow.
Be Selective About Recipients
Not everyone in your organization needs to receive every email.
Earlier, I discussed how you can get very specific about conditions that must be met and what specific actions must take place for an email to be sent. You can also be specific about who gets the email.
You don’t need to ‘hard code’ a user. Helix ALM provides ways to send the email to the last user that performed a specific action.
For example, if a defect fails a verification, you can send an email to the last user who performed the fix. If a file moves to a "Needs Attention" state, send an email to the user set in the file’s Owner custom field.
Control the Message
The last piece of the puzzle is the actual email content.
Helix ALM uses email templates that determine the content of email notifications. Templates are key to ensuring the email contains only the information needed for the specific situation.
You can have different templates for different rules. An email which notifies a user about an assignment should be different than an email that notifies a user that something has changed.
The following screenshot shows the body of a Helix ALM email template and the resulting email.
Use Automated Notifications — The Right Way
With Helix ALM, you have the flexibility to ensure that emails are only sent to the right person, under the right conditions, and with the correct information.
And that means you can keep development running smoothly.