This is a technical entry with my research-and-experiment notes. Feel free to add or argue. Try at your own risk.

..And here it is – HP ALM version 12. Test Director (TD) became Quality Center (QC) which is now rebranded as Application Lifecycle Management.
The main positive thing I notice immediately – it’s not painfully slow anymore. The UI also became more intuitive.

As I quickly discovered, the default project setup would probably fit some dated Waterfall model. So customization is certainly needed.

Areas of customization

Entities. Just a “defect” is not enough, while we have such issues as “System Problem”, “Enhancement”, “Configuration Problem”, and so forth. The big chunk of work is to define new “root” type as issue, and custom fields for issues.

Workflow. “Lifecycle” of issues and “permissions” (as well as definitions of roles) also must be defined. Which includes writing and debugging workflow scripts (that’s the way you customize with QC). Custom scripts must handle desired defaulting and auto-population of fields, but also visibility and access to fields.

Reports. If you add custom fields for reporting purposes, then you of course need to create custom reports utilizing those fields. Which may again require VB and SQL scripting.

Tiers of customization

As I’ve identified, 3 ‘tiers’ are accessible for customization

• DB level. You can change DB schema and contents by executing SQL queries from QC Site Admin. But beware to screw up.
  • Changes on this level typically apply to all projects.
  • Most likely, they will not be forward compatible – when you update or upgrade in the future, your customization might be overwritten. So plan carefully, make a back up, and keep records of what/how was changed at DB level.
  • Some changes are only available at this level.
    • insert into DATACONST values (‘REPLACE_TITLE’, ‘Defect;Issue;Defects;Issues’) is how I ‘converted’ root artifact from “defect” type to “issue” type.
• Template Project. You can change ‘root’ project entity – and all linked ‘child’ projects will be auto-updated where applicable and where possible. Since much of customization is done through real-time execution of your custom VBScript, OOP concept of inheritance is in effect.
• Particular Project. You can just customize your own project without affecting other ones. You can customize on top of ‘parent’ Template Project.

Customization Project

As customization involves numerous data changes in multiple levels AND writing / debugging custom VBScript, the customization becomes as project by itself. I foresee that as “iterative implementation”.

Workflow

• Define abstract logic for the state and/or state transition
• Document logic
• (Where applicable) Define / modify roles and permissions
• (Where applicable) Add / modify fields
• Implement VBScript
• Test VBScript
• Apply script to project
• Test the workflow

Issue

• Define and document the field
• Customize issue by adding / modifying the field, including defaults, look ups, and verification rules
• (Where applicable) Implement / modify VBScript
• (Where applicable) Test VBScript
• Apply script to project
• Test the workflow, including use of the field
• (Where applicable) Update and test the reports

Report

• Define report metrics and document the formulas and rules
• Sketch the report
• (Where applicable) Add / modify fields
• (Where applicable) Implement / modify VBScript
• (Where applicable) Define / modify roles and permissions
• Create Report Template
• Prepare data for testing of the report
• Test the report