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.

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.

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

Integration Testing Handover Sheets

I picked up a tip from a fellow tester a while ago and it's been serving us well in our last couple of deployments - handover sheets (aka runsheets).

All of our integration scenarios are in HP ALM, and given the modular nature of the scenarios we have folders for each activity in the scenario so that testers from the relevant stream can include their tests:

This layout is fine for modularisation, and we can report directly on overall test progress (total planned, executed, pass/fail) from ALM's reporting ability.

However, as we're running multiple test scenarios concurrently it did pose us with two problems - whereabouts are we with each scenario, and is there an easier way for each tester in the scenario to follow the document trail other than having to go into each preceding test to review the test results to glean the document numbers.

Enter the handover sheet. It's a paper sheet that summarises the scenario in business-speak, and the testers note down their material document numbers once they've completed their parts of the scenario, literally being handed over from tester to tester as each part of the scenario is completed.

It's an easy way to keep the trail of the scenario, and it's more visual than the document numbers hidden amongst the tests in ALM.  It's also very easy to simply hand over the finished sheet to anyone who wants to trace the scenario through the test client (auditors, etc).

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")
       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  ;-)

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

AP.AP_FIELD_NAME as Field_name,
AP.AP_NEW_VALUE as Modified



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. BG_CLOSING_DATE label has changed to Due Date in my project.
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 Centre - add a custom calculated field

Earlier, I added a custom field to my Defects module.

I've since added 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.

Create a new custom field as detailed before.

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
End Sub

Create a new sub (Bug_UpdateHours) as follows. Replace BG_USER_15 with your new field, and the other custom field IDs with the IDs of the fields you want to sum:

Sub Bug_UpdateHours
On Error Resume Next
'Update Total Hours
Bug_Fields(BG_USER_15).IsReadOnly = False
Bug_Fields("BG_USER_15").Value = (Bug_Fields("BG_USER_05").Value) + (Bug_Fields("BG_USER_04").Value) + _
(Bug_Fields("BG_USER_14").Value) + (Bug_Fields("BG_USER_07").Value) + _
(Bug_Fields("BG_USER_08").Value) + (Bug_Fields("BG_USER_12").Value)
Bug_Fields(BG_USER_15).IsReadOnly = True
On Error GoTo 0
End Sub

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

Quality Center - change the name of the Defects module

Quality Center insists on calling it's module "Defects", but we don't just use QC for reporting failures. We can also use it for logging requests for change from a business/user perspective, technical enhancements from a project perspective, etc.  And that's before we get into the discussion about whether it's a bug, failure, or any other term that your project might use.

So wouldn't it be nice if the module's name could be changed to fit the way we work?

Luckily, there's a way to change the name of any module in QC.

The REPLACE_TITLE parameter enables you to change the names of Quality Center modules in one Project or across all your projects. The only inhibitor is that you must be a Site Administrator (and not just a Project Administrator) in order to make the change.

To rename modules across all projects:
Rename one or more modules by entering the following parameter value:
For example, if you want to change the name of the Defects module to Bugs, and the Requirements module to Goals, enter the following: Defect;Bug;Defects;Bugs;Requirement;Goal; Requirements;Goals

To rename the Defects module for a single project:
In Site Administration, click the Site Projects tab.
In the Projects list, double-click the project for which you want to rename the Defects module.
Select the DATACONST table.
In the SQL pane, type an SQL INSERT statement to insert a row into the table with the following values:
In the DC_CONST_NAME column, insert the parameter name REPLACE_TITLE.
In the DC_VALUE column, insert a string that defines the new name for the Defects module, in the following format:
original title [singular];new title [singular];original title [plural];new title [plural]

For example, to change the name of the module from Defects to Bugs, type the following SQL statement into the SQL pane:


Click the Execute SQL button. The new row is added to the DATACONST table. The Quality Center project displays the new Defects module name as 'Bugs'.