Can we create reports with RRDI that show execution results in RQM based on an Environment Type?
We have a customer who's using RQM and wants to be able to view TER results by Test Case and also view TER results by Components. Each Test Case is made up of several different Components that make up the entire test. So for example, Test Case 1 would include Components A, B, and C and Test Case 2 includes Components B, C, D, and E.
I implemented this in RQM by creating a new Environment Type called 'Component' and listing all their components under it. So when they create a Test Case and create their TERs, the Component would be one of the Environments they select and there would be a TER for each Component they test in the Test Case. The report would then be similar to TER status by Weight for a specific iteration but would instead show the TER status for a Component in a specific iteration and would therefore contain specific ERs for each Test Case. So my main question is: Can we report based on a specific Environment Type in TERs using RRDI? The customer would select as a Parameter which Environment Types to include in the report. Thanks, |
2 answers
Hi, Michael,
You are able to show TERs and filtered by Test Environment in reports using RRDI. Please refer to RQM OOTB Cognos based reports in the folder of Public Folders > Sample Report Definitions > QM > Data Warehouse Reports > Execution on RRDI. I don't know how many environment types you set to generate the test environment of TER. If you only set one environment type "Component" to the test environment of each TER, that is easy, you can use or do minor changes based on OOTB reports to meet your requirements. In many of OOTB execution reports, they have Test Environment parameter to filter TERs. However, if you set values of other environment type besides "Component" as the test environment of TERs and you ONLY want to filter TERs by "Component" values in reports, OOTB reports would not satisfy you. The reason is that you would see the test environment is a plain text and conjoin the values of each environment type with '_' by default when you set to generate TERs. For example, there is another environment type "Product" (P1, P2, etc. ) besides "Component", the test environment would be "P1_A" if you set P1 for Product and A for Component to generate TER. So in OOTB reports, you can just see "P1_A" in the Test Environment parameter and reports can't filter TERs by one value of environment type in the test environment text. They only filter TERs by the plain text of test environment. You may have to manually select the values including "A" in Test Environment parameter to get those TERs whose test environment includes Component "A" if you only want to see all TERs in Component "A". Maybe my assumption is not suitable for you, but I just want you know the limitation. If you have a chance to use RQM 4.0 and only want to see TERs whose test environment includes one or more values of "Component" in report. I suggest you consider to define the Component to category (test case category or TER category) rather than environment type. I think it is better for you to define "Component" to Test Case Execution Record Category for your case. The ability to define Test Case Execution Record Category on RQM server is added since RQM 3.0.1, but the TER category supporting on reporting side was added since RQM 4.0. Before RQM 4.0, reporting only supports categories of test plan, test case and test suite. Although RQM 4.0 OOTB Cognos reports have not designed TER categories as parameter yet, it is not difficult for you to customize report to add it (referring to test case categories). In additional, you can see some 4.0 OOTB BIRT reports have added TER categories as parameters, e.g. "Execution Status by Owner using TCER Count (Live)" report. Hope it is helpful for you. |
|
Hi, Michael,
I replied your comment#2 of post#1 in there because of characters restriction. Before 4.0, the main problem is that you can't list the values of only one environment type in Test Environment parameter. If you have a fixed count of values of "Component", you can add the hard-code values of Components to a new parameter called "Component" in the report, then add the filter into the query of TER as that "[Test Environment] contains ?Component?" to filter TERs whose test environment including the key word of Component parameter values. The disadvantage is that when you add a new value into the Component definition, you have to customize your report again to add the new hard code value into Component parameter. When you define a new category, it will not update existing TERs. The customer is using 3.0.1.3, so he is able to define Test Case Execution Record Category now. I think the customer can set TCER categories for his TERs from now on. When upgrading to 4.0, reporting is supporting that. The customer could easily customize reports to see TCER categories and use the values to filter out TERs in reports then. |
Your answer
Dashboards and work items are no longer publicly available, so some links may be invalid. We now provide similar information through other means. Learn more here.
Comments
Thank you for the detailed answer..very helpful.
Jun,
A couple clarifying questions. Our customer probably won't be moving to 4.0 for another 6 months. In the meantime with 3.0.1.3 if we use the Environment Type to track their components and there's multiple environment types will we be able to parse the string to pull out those TERs that have the specific component in the string and report on those?
When they move to 4.0 and implement a Category for the components will there be a way to include existing TERs with the same component in that Category? Something like a mass update where existing TERs contain string 'x'?