October 7, 2009
Managing Defects Across Branches
If you use Surround SCM or any other robust software configuration management tool (gasp!), chances are you are using branches to manage your software development process. Depending on your branch strategy, you may find yourself with a defect that exists across multiple branches. There are many ways to manage this situation, the best one for you will depend on your environment and needs. In this post, I am going to take a look at a new feature in TestTrack Pro that might help you implement the best solution for you. In TestTrack Pro 2010 a feature was added to mark linked items as suspect. This feature was originally designed for our requirements management application, TestTrack RM. However, once it became evident of how powerful this feature is, we decided to make it available across all of the TestTrack applications. The original use case for this was for requirements and test cases. If a requirement changes, those testing against that requirement need to know immediately; otherwise time (money) is wasted testing against stale requirements. Once an item is marked as suspect, you can trigger an email notification to let the assignee know that a review is needed. The use case for defect management across branches calls for a defect in each branch to be created. Each defect will have its own workflow, own fields, etc. When a fix is performed, all linked items can be marked as suspect. Marking an item as suspect does not automatically fix them or change them in any way. It simply flags them. This allows the currently assigned user to investigate the changes made to the defect. This could be the queue to merge changes from one branch to another branch. You may be wondering how you would set this up. First, you define a link definition that allows dependent items to be marked as suspect. Note that this is available for parent/child and peer links. Figure 1 below illustrates the option that allows linked items to be marked as suspect. [caption id="attachment_1093" align="aligncenter" width="462" caption="Figure 1- Link Definition Window"][/caption] This link definition will be used when linking the defects for this use case. Next, you configure a workflow event to allow the marking of suspects. As illustrated in Figure 2, the Fix event is being used for this example.Email sign up
[caption id="attachment_1095" align="aligncenter" width="487" caption="Figure 2 - Edit Event Dialog (fix)"][/caption]Last thing you should do is configure a notification rule to send an email to the currently assigned to user when an item is marked as suspect. [caption id="attachment_1100" align="aligncenter" width="402" caption="Figure 3 - Notification Rule"][/caption] Once you do this you are all set! You now have an automated way to flag all defects across all branches when any of them is fixed. The next time a Fix event is entered, users have the option have marking dependent items as suspect. [caption id="attachment_1098" align="aligncenter" width="404" caption="Figure 4 - Fix Event Dialog"][/caption] If you want to enforce this option, you can use field security to hide it. When a Fix event is entered, the dependent items will be marked as suspect and users will not be able to clear the option.