RQM - Categories and Attributes
IBM.com Jazz.net Documentation Downloads developerWorks CLM Artifacts


Categories and Attributes are tags for test ware. This gives the ability to query, search and group on.
  1. Categories
  2. Attributes


Organizing artifacts with Categories in RQM


Categories are pre-defined tags for test ware. This gives the ability to query, search and group on.

Categories are applicable for:

  1. Test Plans
  2. Test Cases
  3. Test Cases Execution Record
  4. Test Scripts
  5. Test Scripts Execution Record
  6. Test Suites
  7. Keywords

Some of the proposed categories in line with TMAP test process.

Tip! Do NOT store 'time-related-categories' like "Phase November" in a category.

An iteration might be more applicable or a attribute

Some characteristics of a category:

As stated "Phase November" is not a good one. Make note that finding test cases can also be done using the related test plan ("Human Safety - Machine B3A"). Furthermore, don't confuse categories with the customizable workflow of each artifact!

Test Plan

Some examples of Categories are:


  • Classics Web Client
  • Classics Fat Client
  • Classics Server
  • Classics DB
  • Billing
  • Machine Type A9B


  • Beta 1
  • Beta 2
  • Beta 3
  • R1.0
  • R1.1
  • R1.2
  • R1.3
  • R2.0
  • R2.1
  • R2.2
  • R2.3

A test plan is coupled to 1 release (these tags). A test case could be reused in various test plans, so the "Release" tag should be a multiselect there when applied.

Life Cycle

  • Planning
  • Preparation
  • Specification
  • Execution
  • Completion
  • Control
  • Infrastructure

The value of this TMAP related category is limited while all fases are executed in parallel. So a test plan can be partially in Preparation, Specification and Execution!

Test Level

  • Unit Test
  • Unit Integration Test
  • System Test
  • System Integration Test
  • Performance Test
  • Security Test
  • Functional Acceptance Test
  • Users Acceptance Test
  • Production Acceptance Test

This can be used if a test plan is targetting a specific test level.

Test Cases


  • Classics Web Client
  • Classics Fat Client
  • Classics Server
  • Classics DB
  • Billing
  • Machine Type A9B

The product/release tags can be re-used here. Take care if test are re-used in various test plans, if the tagging is still strong.


  • Paths
  • Decision Points
  • Equivalence Classes
  • Pairwise Testing
  • Orthogonal Arrays
  • Boundary Value Analysis
  • CRUD
  • Operational Profiles
  • Load Profiles
  • Right Paths/Fault Paths
  • Checklist

A test case covers a certain test goal. This goal might be implemented using different techniques. Still this is a very solid tag for test cases.


  • Functionality
  • Usability
  • Reliability
  • Performance
  • Serviceblity
  • Security

Many other artifacts can have categories. Creation of categories can be limited to certain Test roles (e.g. Test Mgr, or Test Lead).

Filtering, query, finding and search

When categories are defined and used you can filter and query on them on various locations in the GUI.

  1. From the menu (save the query)
  2. In the listings

Figure: Opening the filtering option to query on categories.

Figure: Definition of a query. You can run it or save it (and add it to the Menu).

To manage Categories do:

Creating Categories

The definition on categories is easy, when you know it.


A category can be a simple key/value pair. This can be used to filter easily to the right level.

Figure: Definition of simple category "Color of Light" and several values.

Figure: How a user can set the category "Color of Light" in the web-gui.

An alternative way is to create the categories using the Excel importer or copy the structure of a project.

Multi Level

Use vertical and horizontal scrollbars! While defining the categories you will make use of the sub-menu of a category. The icon is at the far right end of the highlight bar. This might be visible, but maybe hidden. Use the horizontal scroll bar to reveal.
On my laptop, due to the screen size, the horizontal bar is not visible when I'm at the top of the configuration page.
  1. Use vertical scroll bar to move down to bottom of configuration page
  2. Use horizontal scroll bar to reveal the icon

Figure: To see the icon for the sub-menu use both scroll bars.

An example of hierarchy:

  1. Application = WebGUI
  2. Application = ServerApplication

Figure: Top level Application category.

Now let's add the next level of category being test type in the same manner.

  1. Test Type = Functional
  2. Test Type = Performance
  3. Test Type = Security
  4. Test Type = Usability

Figure: The various types.

Not all types are applicable for all applications!

  1. Application = WebGUI
    1. Test Type = Functional
    2. Test Type = Performance
    3. Test Type = Security
    4. Test Type = Usability
  2. Application = ServerApplication
    1. Test Type = Functional
    2. Test Type = Performance
    3. Test Type = Security
      Usability is not applicable for this application.

So we define Test Type as a Sub-Category of Application. The Test Type is use for the WebGUI and re-used for the ServerApplication.

Figure: Add the Test Type as sub-cat of Application. Make note of the red-warning above!

Now specify which sub-category value is applicable for that specific application!

Figure: Edit the subcategory!

Make note that the Usability is only applicable for the WebGUI application

Figure: Resulting hierarchy list

When adding these categories to a Test Case, and set the application to ServerApplication we do not see the Usability option for a test type.

Figure: Selecting Server Application will filter all applicable test cases for the Server Application

Figure: Selecting sub category Functional will filter all applicable test cases for the Functional Test cases for the Server Application.

Folder Structure / Tree Structure

Think of this! The hierarchy of categories is more flexible than a rigid tree structure. By 'simulate' a tree on put restrictive measures to the categories and maybe reduce productivity.

Suppose we have a large number of tests concerning Automotive Lighting. The tests are stored in a folder structure as defined in the Wikipedia (See full structure). For clarity we make a selection.

Important is that we do not have 're-use' across the structure. A test is located at 1 spot.

  1. Forward Illumination
    1. HeadLamps
      1. Dipped Beam
      2. Main Beam
    2. Auxiliary Lamps
      1. Driving Lamps
      2. Front Fog Lamps
      3. Cornering Lamps
      4. Spot Lights
  2. Conspicuity, signal and identification lights
    1. Front
    2. Lateral
    3. Rear

Again the headlamps are only part of the forward illumination, so the structure is more restrictive compared to the WebGUI/ServerApplication in previous chapter. The structure shows only the values, not the categories. So we have to define the categories.

  1. Maingroup = Forward Illumination
    1. Forwardgroup = HeadLamps
      1. Headgroup = Dipped Beam
      2. Headgroup = Main Beam
    2. Forwardgroup = Auxiliary Lamps
      1. Auxgroup = Driving Lamps
      2. Auxgroup = Front Fog Lamps
      3. Auxgroup = Cornering Lamps
      4. Auxgroup = Spot Lights
  2. Maingroup = Conspicuity, signal and identification lights
    1. Conspicuitygroup = Front
    2. Conspicuitygroup = Lateral
    3. Conspicuitygroup = Rear

We define the Categories/Values combinations. To identify the Category the 'group' was added to the name.

Figure: All categories are defined with appropriate values. Make note of the 2 scroll bars!! - see alert above.

Now we add the hierarchy using the sub-categories.

Figure: All categories are now visible indefined with appropriate values.

Next we have to define which values are applicable to which level. Use the horizontal scroll bar!

Figure: All values of the Conspicuitygroup are applicable, no value of the Forwardgroup..

Figure: In the Test Case webgui, this gives me the option to set the Maingroup and than the Conspicuitygroup. Others, like Forwardgroup can not be set.

Figure: Sample tree structure. Make note that under the "Dipped Beam" value, both "Dipped beam" and "Main beam" sub-groups are visible (applied to Headgroup). Only the values for "Dipped beam" are active. Values from "Main beam" are deselected.

Figure: When having the categories set at the test case, we can easily navigate and select in the tree on the left site of the screen. Futher down the tree narrows the search, where "Dipped Beam" might result in 10 TC, the "Meeting Beam" might list only 1 TC.

Matrix Structure

What about a matrix structure? On one axis the type of car being "consumer" and "race version" and the other axis "forward" and "conspicuity"? How if tests are applicable for both?


This is a combination of 2 independent categories!


The LightType could be defined as a sub-category of Cartype. Tests with a category "Undefined" are reused! We can define a n-vector matrix!

(Custom) Attributes


Attributes are free tags for test ware. This gives the ability to query, search and group on.

The various Test Ware artifacts can have Attributes. These are free fields. One can also query on these fields when browsing for them. Available types are

Make note that due to the flexibility it's harder to query (is a machine M52, M-52, M 52, m52 etc).

To manage Attributes do: