14 May

HP ALM – A Few Tips and Tricks

A collection of bits and pieces for HP ALM. Tips, tricks, and workflow coding.

HP ALM – Template for Defect Description Field

I want to create a Description field template in the Defects module in HP ALM so that some of our newer users have reminders of what to enter into the bug report.  The intention is that when they create a new defect directly in the Defects module (rather than via test execution in Test Lab) the Description box is pre-populated with headings to show the important information to be captured.

I already have important required info included on the defect template in mandatory drop-down lists (severity, priority, system, environment, etc), so the template is more to promote good behaviour in the descriptive field.

Sub Bug_New
 On Error Resume Next
 'Set template Description on new bug opened from Defect Module
 If Bug_Fields("BG_DESCRIPTION").IsNull then
 sAfterDescription = "<html><body>"
 sAfterDescription = sAfterDescription + "<b>Transaction / Process / WRICEF ID being executed when error occurred:</b><br><br><br><br><br>"
 sAfterDescription = sAfterDescription + "<b>Summary and steps to reproduce the problem:</b><br> <br><br><br><br>"
 sAfterDescription = sAfterDescription + "<b>Relevant Data:</b><br>Customer(s), Material(s), Vendor(s), quantities, etc<br><br><br><br>"
 sAfterDescription = sAfterDescription + "<b>Expected Results:</b><br><br><br><br><br>"
 sAfterDescription = sAfterDescription + "<b>Actual Results:</b><br> <br><br><br><br>"
 sAfterDescription = sAfterDescription + "<b>Immediate Workaround (if any):</b><br> <br><br><br><br>"
 sAfterDescription = sAfterDescription + "<b>Regression / Isolation Impact:</b><br> <br><br><br><br>"
 sAfterDescription = sAfterDescription + "</body></html>"
 Bug_Fields("BG_DESCRIPTION").Value = sAfterDescription
 End if
 On Error GoTo 0
 End Sub

A screenshot of the Description field shows the template as it appears when called:

Defect Description Template

There’s still a piece of work to do to update the code to use ActionNames to ensure it’s the New Defect button in the Defects module that is triggering the New Defect dialog box, and not when creating a new defect from a test run, but overall the new template helps the testers to identify the information required.

 


 

Adding a Custom Calculated Field

I’ve added a few custom fields to my Defects module, including several forecasting fields for breaking down various expected delivery times, and I now want to add a custom calculation field to add the forecasts together.

In the Script Editor add a new sub (or modify the sub if it already exists):

Sub Bug_FieldChange(FieldName)
' Call Update Hours sub to sum estimated hours
Bug_UpdateHours
End Sub

Create a new sub (Bug_UpdateHours) as follows. Here we’re assuming that BG_USER_01 to BG_USER_04 are the forecasting fields containing an integer representing “number of days”, and BG_USER_05 is the new summed field – replace these with the relevant field names from your own project:

Sub Bug_UpdateHours
On Error Resume Next
'Update Total Hours
Bug_Fields(BG_USER_05).IsReadOnly = False
Bug_Fields("BG_USER_05").Value = (Bug_Fields("BG_USER_01").Value) + (Bug_Fields("BG_USER_02").Value) + _
(Bug_Fields("BG_USER_03").Value) + (Bug_Fields("BG_USER_04").Value)
Bug_Fields(BG_USER_05).IsReadOnly = True
On Error GoTo 0
End Sub

You now have a read-only field that updates automatically with the total.

 


 

Quality Center – Calculate the Closed Date of a Defect

Problem: I need to create a graph showing the trend in closure of defects. However, using the Last Modified date field isn’t accurate – it records the Last Modified date (surprise!) rather than the date the defect was closed.

Investigation:  The History of a defect contains the change log, and I can see that the date that the defect was set to Closed is recorded somewhere in QC.

A check of the tables using the Excel Report Generator shows that the information required is held in the AUDIT_PROPERTIES table ( SELECT * FROM  AUDIT_PROPERTIES).

A closer look at an individual record ( SELECT * FROM  AUDIT_PROPERTIES WHERE AP_ACTION_ID = ‘11788’) shows that there are three rows created when the record is changed: one for the change in Status from ‘Fixed in Next Release’ to ‘Closed’, one for the change in Modified date, and one for the change in BG_CLOSING_DATE Due Date property with a new date value.

It looks like there are two solutions to the problem – one involving a bit of SQL to join the rows for the change in Status to Closed and the change in Modified date; the other (simpler) solution appears to be the BG_CLOSING_DATE field.

To confirm the validity of the two solutions I need to test them.

The Test:  I extract the following two reports:

From the Excel Report Generator

SELECT
AU.AU_ENTITY_ID AS Defect_ID,
AP.AP_FIELD_NAME as Field_name,
AP.AP_NEW_VALUE as Modified
FROM AUDIT_PROPERTIES AP LEFT JOIN AUDIT_LOG AU ON AP.AP_ACTION_ID = AU.AU_ACTION_ID
WHERE AP.AP_ACTION_ID IN (SELECT AP.AP_ACTION_ID FROM AUDIT_PROPERTIES AP WHERE AP_NEW_VALUE = 'Closed')
and  AP.AP_FIELD_NAME = 'BG_VTS'

From the Defects module

Select Columns, Visible Columns = Defect ID, Status, Closing Date.

However, my fields don’t include Closing Date.

Back to Project Customization | Project Entities to verify the name of the field. The BG_CLOSING_DATE label name has changed to Due Date in my project, so “Due Date” is the column I need to select.

Select Columns, Visible Columns = Defect ID, Status, Due Date.

First Test: do I only have Closed defects with a BG_CLOSING_DATE field completed? Err, no. I have two defects that are not yet Closed that have dates set. Now I remember why the field label has been changed – for the past month or so we’ve been using the field as the “Expected” closing date for forecasting. Luckily the field doesn’t appear to have been used that much, so for the two errant defects I clear the field, create a user-defined field for Due Date, add the new field to the defect form in the Workflow Script Editor, update the field for the two defects, and rename the BG_CLOSING_DATE field back to Closing Date.

Second Test: do the dates match between the SQL query and the Defects module extract?  A quick vlookup between the two extracts shows some non-matches. An examination of the defect history of the non-matches shows that the reason for the differences is due to defects that have been Closed, subsequently reopened, and then Closed again. The BG_CLOSING_DATE field appears to update with the date that the defect was last set to Closed.

Summary:  The BG_CLOSING_DATE field is useful for the date that the defect was last set to Closed (as distinct from the date the defect was last Modified. This field can be used directly in the Defects grid view.

 


 

Quality Center – Restricting the Status Workflow

My old project team was very small (a handful of developers and myself as the sole tester). As we were a small team I removed the default defect status workflow for a bit of flexibility in reporting. However, I had one or two developers who persisted in setting the defect status to “Closed” on my behalf, risking that defects will pass through without retesting.

I needed to restrict this again. The requirement isn’t just a workflow for going from New to Fixed to Closed, but to ensure that only the tester can set defects to “Closed”.

The dev team are included in their own Group, so a quick and dirty way is to create a new Project List with the limited statuses available (excluding Closed) and add to the subroutine in the Script Editor:

Sub WizardBGStatusListCust
If User.IsInGroup("TDAdmin", "Defects Manager") Then
Bug_Fields("BG_STATUS").List = Lists("Bug Status")
Else
Bug_Fields("BG_STATUS").List = Lists("Bug_Status_Dev")
End if
End Sub

Now everyone that is not in the TDAdmin or Defects Manager group will see the reduced list only (“Bug_Status_Dev”).

However, they will also only see the restricted fields when filtering in the grid view in the Defects module. Not very helpful if a developer wants to filter and view all Closed defects.

A better solution is to restrict the Group status workflow, so that the users can see the Closed status but cannot change a defect to Closed.

In the Customization screen select Groups and then the group that requires changing (Defects Developer in my case). Select Change, then the Defects tab on the resulting pop-up. In the left-hand pane open the Modify Defect tree and highlight the Status field. With the Status field highlighted, the right-hand pane will display the transition rules section.

Select Add, and add in the transition rules for each status change. If a status can be changed to more than one possibility then all transitions will need to be entered separately.

Save and test the changes with a test account to ensure the status transitions are correct.

And don’t forget to change the subroutine in the Script Editor back again  😉

 


 

HP ALM – Internet Explorer Protected Mode

A new user received the following error when trying to start HP ALM for the first time. Windows 7, Internet Explorer 8:

Internet Explorer is configured to run in Protected Mode. Deployment is Aborted.
Contact your system administrator. For details, see the Loader log file.

IE Protected Mode Error

Select Tools | Internet Options | Security to enable or disable the Protected Mode:

IE Protected Mode2
 


 

HP ALM – Find the ActionName of the object and action

Looking to find the action that you want to ascribe code to?  Here’s a quick tip to get the correct ActionName of the buttonpress in HP ALM:

In the ALM Script Editor (Tools | Customize | Workflow | Script Editor) copy this function to the Defects module script:

Function ActionCanExecute(ActionName)
On Error Resume Next
msgbox "The ActionName is: " & ActionName
On Error GoTo 0
End Function

Save and exit the Script Editor and return to the main screen, selecting Major Change where prompted.

To test this we’ll go to the Defects module and press the [New Defect…] button. We get two messageboxes telling us what the ActionNames are (you’ll need to click through the first box to get the second one):

If you’re on a system being used by other testers, don’t forget to go back into Script Editor and delete or comment out your code. I’d recommend just commenting it out so that you can easily reuse it next time – be sure to add comments to the code so that other Admins know what it is there for.