QMetry: Fetch Test Case Executions

Get execution records for a specific test case by numeric ID, including Test Run UDF values. ALWAYS present results as a unified table: Test Suite Key | Test Suite Name | Release | Cycle | Platform | Executed Version | Execution Status | <UDF Label columns…>. NEVER show a separate type+value UDF breakdown — always combine identification fields and UDF values in one table per execution row.

Toolset: Test Cases

Parameters:

• projectKey (string): Project key - unique identifier for the project (default: "default")

• baseUrl (string): The base URL for the QMetry instance (must be a valid URL)

• tcid (number) required: Test Case numeric ID. CRITICAL: the parameter name is 'tcID' — do NOT use 'testCaseId', 'testCaseID', 'tcId', or other variants. Accepts a string or number. This is the internal numeric identifier, not the entity key like 'MAC-TC-1684'. You can get this ID from test case search results or by using filters.

• tcversion (number): Test Case version number (optional, defaults to 1). This is the internal numeric identifier for the version.

• start (number): Start index for pagination - defaults to 0 (default: 0)

• page (number): Page number to return (starts from 1) (default: 1)

• limit (number): Number of records (default 10). (default: 10)

• scope (string): Scope of the operation - defines the context for data retrieval. Common values: 'project' (default), 'folder', 'release', 'cycle'. Applies to any entity type being fetched or operated upon. (default: "project")

• filter (string): Filter criteria as JSON string (default '[]') (default: "[]")

Output Description: JSON object with executions array. Each execution record ALWAYS contains these mandatory identification fields: 'tsEntityKey' (Test Suite Key, e.g. 'MAC-TS-42'), 'testsuiteName' (Test Suite Name), 'releaseName' (Release), 'cycleName' (Cycle), 'platform' (Platform/environment), 'executedVersion' (Executed Version of the test case), 'executionStatus' (Execution Status label), 'tcRunID' (numeric Test Run ID), and 'testRunUdfs' (array of objects each with name, label, fieldID, fieldType, value — use 'label' for display headers, null if not set). ALL project-defined UDF fields are always included, even those with no value. Top-level 'hasTcRunUdf' flag indicates whether the project has Test Run UDFs configured. When false, a 'testRunUdfNote' field provides a professional explanation instead.

Use Cases: 1. Get execution history for a specific test case 2. Retrieve test case execution results for reporting 3. Filter executions by test suite, platform, or execution status 4. Get execution data for test case analysis 5. Monitor test case execution trends over time 6. Filter executions by release, cycle, or execution date 7. Get execution details for specific test case versions 8. Audit test execution history for compliance 9. Analyze test case execution performance across different environments 10. Track test execution by specific users or teams 11. Fetch Test Run UDF values for a specific test case's execution records 12. Inspect custom metadata captured during test execution via Test Run UDFs 13. Check whether the project has Test Run UDFs configured (hasTcRunUdf flag)

Examples:

1. Get all executions for test case ID 1223922

{
  "tcid": 1223922
}

Expected Output: Present as ONE unified table — never as a separate type+value UDF breakdown. Example: | Test Suite Key | Test Suite Name | Release | Cycle | Platform | Executed Version | Execution Status | Tested By | Environments UDF | Execution Type | | MAC-TS-42 | Regression Suite | R1 | Sprint1| Chrome | v1 | Passed | varis | chrome, edge, safari | Functional | | MAC-TS-42 | Regression Suite | R1 | Sprint1| Firefox | v2 | Failed | john | firefox | Regression | Columns in order: Test Suite Key (tsEntityKey) | Test Suite Name (testsuiteName) | Release (releaseName) | Cycle (cycleName) | Platform (platform) | Executed Version (executedVersion) | Execution Status | then one column per UDF label. Use the UDF 'label' as column header. Show null UDF values as '-'.

2. Get executions for specific test case version

{
  "tcid": 1223922,
  "tcversion": 2
}

Expected Output: Execution records for version 2 of the test case

3. Filter executions by test suite and platform

{
  "tcid": 1223922,
  "filter": "[{\"value\":\"Sample Test Suite\",\"type\":\"string\",\"field\":\"testSuiteName\"},{\"value\":[12345],\"type\":\"list\",\"field\":\"platformID\"}]"
}

Expected Output: Filtered execution records matching test suite and platform criteria

4. Filter executions by execution status

{
  "tcid": 1223922,
  "filter": "[{\"value\":[\"PASS\"],\"type\":\"list\",\"field\":\"executionStatus\"}]"
}

Expected Output: Execution records with PASS status only

5. Filter executions by release and cycle

{
  "tcid": 1223922,
  "filter": "[{\"value\":[55178],\"type\":\"list\",\"field\":\"release\"},{\"value\":[111577],\"type\":\"list\",\"field\":\"cycle\"}]"
}

Expected Output: Execution records filtered by specific release and cycle

6. Filter executions by date range

{
  "tcid": 1223922,
  "filter": "[{\"value\":\"2024-01-01\",\"type\":\"date\",\"field\":\"executedDate\",\"comparison\":\"gt\"},{\"value\":\"2024-12-31\",\"type\":\"date\",\"field\":\"executedDate\",\"comparison\":\"lt\"}]"
}

Expected Output: Execution records within the specified date range

7. Filter executions by user

{
  "tcid": 1223922,
  "filter": "[{\"value\":[\"john.doe\"],\"type\":\"list\",\"field\":\"executedBy\"}]"
}

Expected Output: Execution records executed by specific user

8. Fetch Test Run UDF values for all executions of test case ID 41571999

{
  "tcid": 41571999
}

Expected Output: Present as ONE unified table combining identification fields and UDF values — never a separate type+value breakdown. Example: | Test Suite Key | Test Suite Name | Release | Cycle | Platform | Executed Version | Execution Status | Tested By | Environments UDF | Execution Type | Country | | MAC-TS-42 | Login Suite | R1 | Sprint1 | Chrome | v1 | Passed | varis | chrome, edge, safari | Functional | India > i3 | UDF column headers use the UDF 'label' (not raw field key). Null values shown as '-'.

9. Check if project has Test Run UDFs — response includes hasTcRunUdf flag

{
  "tcid": 1223922
}

Expected Output: Response contains hasTcRunUdf: true (UDFs present, testRunUdfs populated) or hasTcRunUdf: false (no UDFs configured, testRunUdfNote explains this)

Hints: 1. === MANDATORY RESPONSE FORMAT — READ THIS BEFORE RENDERING ANY OUTPUT === 2. 3. PIVOT RULE — CRITICAL: 4. The 'testRunUdfs' field on each execution is an array of { name, label, fieldID, fieldType, value }. 5. You MUST pivot this array into TABLE COLUMNS — do NOT render it as rows. 6. → Each testRunUdfs[i].label = a column header in the unified table 7. → Each testRunUdfs[i].value = the cell value for that execution's row 8. → testRunUdfs[i].fieldType = INTERNAL METADATA — NEVER show this as a column 9. → testRunUdfs[i].fieldID = INTERNAL METADATA — NEVER show this as a column 10. 11. FORBIDDEN PATTERNS — NEVER do any of these: 12. ❌ Do NOT render a separate sub-table (UDF Label | Type | Value) per execution 13. ❌ Do NOT show 'Type' or 'fieldType' as a visible column 14. ❌ Do NOT group output by tcRunID with individual breakdowns beneath each 15. ❌ Do NOT show raw UDF field keys (e.g. 'TRString', '8260LUP') as headers — use 'label' 16. 17. REQUIRED OUTPUT — ONE unified table, all executions as rows: 18. | Test Suite Key | Test Suite Name | Release | Cycle | Platform | Executed Version | Execution Status | <UDF Label 1> | <UDF Label 2> | ... | 19. |----------------|-----------------|---------|-------|----------|------------------|------------------|---------------|---------------|-----| 20. | MAC-TS-42 | Login Suite | R1 | S1 | Chrome | v1 | Passed | varis | chrome, edge | ... | 21. 22. MANDATORY COLUMNS (always first, in this order): 23. 1. Test Suite Key → tsEntityKey (e.g. 'MAC-TS-42') 24. 2. Test Suite Name → testsuiteName (test suite display name) 25. 3. Release → releaseName 26. 4. Cycle → cycleName 27. 5. Platform → platform 28. 6. Executed Version → executedVersion 29. 7. Execution Status → executionStatus 30. 8. Tested By → testedBy/executedBy when present 31. 9+. One column per UDF field — use testRunUdfs[i].label as header, testRunUdfs[i].value as cell. 32. 33. Null UDF values → show as '-'. If hasTcRunUdf is false, show columns 1-8 only. 34. UDF DATA SOURCE — THIS TOOL IS SELF-CONTAINED: 35. This tool automatically calls Test Run UDF metadata once (project-wide) and parses the udfjson field from each execution row. 36. The 'testRunUdfs' array in every execution record already contains ALL configured UDF fields — including fields with no value (null). 37. DO NOT call 'Fetch Test Run UDF Values' after this tool for test case executions — that tool uses GET_TESTCASE_RUNS_BY_TESTSUITE_RUN which is for test suite runs, not test case executions. 38. NEVER chain 'Fetch Test Run UDF Values' when the user asks for UDF values of test case executions — use testRunUdfs from THIS response directly. 39. === END MANDATORY RESPONSE FORMAT === 40. 41. This API requires a numeric tcid parameter, not entity key 42. If user provides entityKey (e.g., MAC-TC-1684), first call FETCH_TEST_CASES with filter on entityKeyId to resolve the tcid 43. After resolving entityKey → tcid, call this tool with the resolved numeric tcid 44. tcversion parameter is optional - omit to get executions for all versions 45. 46. CRITICAL WORKFLOW FOR LINKED ISSUES: When user asks 'fetch linked issues of test case [ID]' or 'linked issues of execution': 47. YOU MUST FIRST get the execution data using this tool to extract tcRunID before fetching issues! 48. 49. COMPLETE WORKFLOW FOR TEST CASE → LINKED ISSUES: 50. STEP 1: Resolve Test Case ID (if needed) - Use FETCH_TEST_CASES if user provides entity key 51. STEP 2: Fetch Test Case Executions (THIS TOOL) - Input: tcid, Extract: data[].tcRunID values 52. STEP 3: Fetch Linked Issues - Tool: FETCH_LINKED_ISSUES_BY_TESTCASE_RUN, Input: entityId = tcRunID 53. 54. ID MAPPING CRITICAL UNDERSTANDING: 55. - tcid/tcID = Test Case ID (for getting execution data with this tool) 56. - tcRunID = Test Case Run/Execution ID (THIS is entityId for linked issues API) 57. - entityId = tcRunID (what the linked issues API actually needs) 58. 59. NEVER USE tcid DIRECTLY as entityId for linked issues! 60. ALWAYS get tcRunID from executions and use THAT as entityId! 61. 62. EXAMPLE RESPONSE STRUCTURE FROM THIS TOOL: 63. { "data": [{ "tcRunID": 58312120, "testSuiteName": "Suite 1", "executionStatus": "PASS", "testRunUdfs": [...] }] } 64. → Use tcRunID (58312120) as entityId for linked issues API 65. 66. FILTER CAPABILITIES: Support extensive filtering by test suite, platform, status, user, release, cycle, dates, and archive status 67. FILTER FIELDS: testSuiteName (string), platformID (list), executionStatus (list), executedBy (list), project (list), release (list), cycle (list), executedDate (date with comparison), isPlatformArchived (list), isTestSuiteArchived (list), executedVersion (numeric) 68. DATE FILTERING: Use 'gt' (greater than) and 'lt' (less than) comparisons for executedDate field 69. EXECUTION STATUS: Common values include 'PASS', 'FAIL', 'BLOCKED', 'NOT_EXECUTED', 'WIP' (verify with your QMetry instance) 70. PLATFORM/SUITE ARCHIVE: Use [1,0] for both archived and non-archived, [1] for archived only, [0] for active only 71. Multiple filter conditions are combined with AND logic 72. Use pagination for large execution result sets (start, page, limit parameters) 73. Get platform IDs from FETCH_PLATFORMS tool and release/cycle IDs from FETCH_RELEASES_AND_CYCLES tool 74. This tool is essential for test execution reporting, trend analysis, and compliance auditing 75. Execution data includes timestamps, user information, environment details, and test results 76. Use scope parameter to define retrieval context (project, folder, release, cycle) 77. 78. TEST RUN UDF SUPPORT: 79. This tool automatically fetches UDF metadata (project-wide, one call for all executions) and enriches each execution record. 80. ALL project-defined Test Run UDF fields are returned for every execution — including fields with no value (value: null). 81. HTML is stripped from rich text (LARGETEXT) UDF field values for clean output. 82. Each execution's 'testRunUdfs' is an array of objects: 83. testRunUdfs: [ 84. { "name": "8260LUP", "label": "Lookup Field", "fieldID": 228563, "fieldType": "LOOKUPLIST", "value": "l1" }, 85. { "name": "TRString", "label": "TR String", "fieldID": 229241, "fieldType": "STRING", "value": "dsf" }, 86. { "name": "notes_run", "label": "Notes Run", "fieldID": 229242, "fieldType": "LARGETEXT", "value": null }, 87. { "name": "cascade_vK", "label": "Cascade VK", "fieldID": 229426, "fieldType": "CASCADINGLIST", "value": { "child": "qq", "parent": "vkc" } } 88. ] 89. Use 'fieldID' from testRunUdfs entries when calling 'Bulk Update Test Run UDFs'. 90. 91. hasTcRunUdf FLAG — IMPORTANT: 92. The response contains a 'hasTcRunUdf' boolean flag at the top level. 93. hasTcRunUdf: true → Project has Test Run UDFs configured; each execution record includes 'testRunUdfs' array with all fields. 94. hasTcRunUdf: false → Project has NO Test Run UDFs configured. 95. When hasTcRunUdf is false, the response includes a 'testRunUdfNote' field with a professional explanation. 96. Inform the user: 'No Test Run UDFs are configured for this project. Contact a project administrator to set up Test Run UDF fields.' 97. NEVER attempt to read testRunUdfs from records when hasTcRunUdf is false — the field will not be present.