Using Triggers to Assign and Set a Defect State When a Test Run Fails

From Seapine Labs

Contents 1 Introduction 2 Requirements 2.1 Technical Requirements 2.2 Project Requirements 2.3 Usage Requirements 3 Creating the Trigger 4 The SOAP Script 5 Improvements/Enhancements

[edit] Introduction

The following examples shows how you can use TestTrack triggers along with the TestTrack SDK to automatically perform the "verify" event on a defect when a test run enters a failed state.

[edit] Requirements

[edit] Technical Requirements

• TestTrack 2008
• TestTrack Pro license
• TestTrack TCM license
• TestTrack SDK
• .NET 2.0 Framework
• Visual Studio 2005 - only needed if you want to modify the source code and re-build the application

[edit] Project Requirements

This example uses the Sample Project that is installed with TestTrack. The only modification made is to the the "verify" event, and the change is so the "event results in a new assignment". Please refer to the TestTrack User Guide for more details on how to make this change.

[edit] Usage Requirements

In order for this script to work, the test runs that enter the failed state must have been generated from a test case that is linked to a defect. This link is automatically created when you create a test case from a defect.

However, this will also work if you create a test case from scratch and then manually add a link to a defect.

Keep in mind that this script will only look at the newest link to a defect. If a single test case is linked to multiple defects, it will only modify the defect indicated in the newest link.

[edit] Creating the Trigger

The trigger used in this example is quite simple. Following is the trigger summary:

[TestRun Failure] applies to all [test runs] -- when [enters state Failed] Run executable located at "D:\TTScripts\TestRunFailAssignment\TestRunFailAssignment.exe" [after] save

Please refer to the TestTrack User Guide for more details on how to set up triggers.

[edit] The SOAP Script

You can download the SOAP application I created in Visual Studio 2005 using C# from here:

TestRunFailAssignment.zip

There are a some modifications that may be needed:

• The script uses "Administrator" to log in and perform the verify event on the defect. You may want to change this to a dedicated SOAP account.

• The SOAP server URL is hard coded. You may need to change this, depending on the location of your SOAP server.

• If your workflow is drastically different from the one in the Sample Project, you may need to change the event names and resulting state.

[edit] Improvements/Enhancements

• A possible improvement could be to have the trigger launch a batch file. The batch file could then call the application and pass some arguments. Some of the arguments could be the SOAP user account, the SOAP server URL, or the event names. The idea being that if any of those change, you only have to edit a batch file, instead of having to edit the source code, recompile, and rebuild.

• A duplicate script could be created, except that the resulting state of the verify event would be "Closed (verified)" and it would not assign the defect. This script would be used with a new trigger that would be fired when a test run enters the "Passed" state.

• The trigger could be set up to fire when a test run changes state. The script would perform a verify event if one of the resulting states is passed or failed (as oppossed to "in progress", "waiting", etc.). The resulting state of the verify event would depend on the resulting state of the test run. If the test run ends up in a "failed" state, the defect would be set to an "Open (Verify failed)" state. If the test run ends up in a "passed" state, the defect would be set to a "Closed (verified)" state.

• If you have configured your defect event with several custom fields, you could use other information from the test run or parse the event comments to set these custom fields.

Note: Seapine does not provide support for sample triggers.