QMetry: Create Test Suite

Create a new test suite in QMetry with metadata and release/cycle mapping.

Toolset: Test Suites

Parameters:

• parentFolderId (string): Test Suite parent folder ID - SYSTEM AUTOMATICALLY RESOLVES THIS. Leave empty unless you have a specific folder ID. System will fetch project info using the projectKey and extract rootFolders.TS.id automatically. Manual folder ID only needed if you want to target a specific sub-folder.

• name (string) required

• isAutomatedFlag (boolean)

• description (string)

• testsuiteOwner (number)

• testSuiteState (number)

• associateRelCyc (boolean)

• releaseCycleMapping (array): Release/cycle association for the test suite. CRITICAL SHAPE DIFFERENCE vs Test Case mapping: Test Suite uses: { releaseId: number, buildID: number } Test Case uses: { release: number, cycle: number[], version: number } — DO NOT use TC shape here. Set associateRelCyc=true when providing this array. Example: [{ releaseId: 92112, buildID: 130831 }]

• udfFields (record<string, union>): Flat UDF field values. Keys = UDF field names from 'Fetch UDF Layout'. Values depend on fieldTypeName: STRING/LARGETEXT: string, NUMBER: number, DATETIMEPICKER: date string ('14-08-2026'), LOOKUPLIST: numeric ID, MULTILOOKUPLIST: array of IDs [101, 102], CASCADINGLIST: { parent: 101, child: 102 }. Call 'Fetch UDF Layout' with entityType + pageName='ADD' to discover available fields and list option IDs.

Output Description: JSON object containing the new test suite ID, summary, and creation metadata.

Use Cases: 1. Create a basic test suite with just a name and folder 2. Add detailed metadata like description to a test suite 3. Associate test suite with specific release/cycle for planning 4. Set testsuiteOwner, testSuiteState, and other metadata using valid IDs from project info 5. Create test suites for isAutomatedFlag true or false for automated or manual types, default is false 6. Add test suite to a specific folder using parentFolderId 7. Map test suite to multiple cycles/releases and build ID

Examples:

1. Create a test suite in the root folder (auto-resolved)

{
  "name": "Demo Test Suite"
}

Expected Output: Test suite created in the root test suite folder with ID and summary details

2. Create a simple test suite in folder 102653

{
  "parentFolderId": "102653",
  "name": "Login Test Suite"
}

Expected Output: Test suite created with ID and summary details

3. Create a test suite with some details and metadata

{
  "parentFolderId": "113557",
  "isAutomatedFlag": false,
  "name": "Testsuite Summary",
  "description": "desc",
  "testsuiteOwner": 6963,
  "testSuiteState": 505035,
  "associateRelCyc": true,
  "releaseCycleMapping": [
    {
      "buildID": 18411,
      "releaseId": 10286
    }
  ]
}

Expected Output: Test suite created with details and metadata. Example uses: parentFolderId=113557 (MAC root TS folder from rootFolders.TS.id), testsuiteOwner=6963 (umang.savaliya from customListObjs.owner[index].id), testSuiteState=505035 (New from customListObjs.testSuiteState[index].id), releaseId=10286 (Air release from projects[index].releases[index].releaseID), buildID=18411 (Air Q1-19 cycle from projects[index].releases[index].builds[index].buildID)

Hints: 1. ╔══════════════════════════════════════════════════════════════════╗ 2. ║ STEP 0 — NON-NEGOTIABLE: Call 'Fetch UDF Layout' BEFORE create ║ 3. ╚══════════════════════════════════════════════════════════════════╝ 4. NEVER call 'Create Test Suite' without first calling 'Fetch UDF Layout' with entityType='TS', pageName='ADD'. 5. Skipping this step WILL cause 400 errors (CO.MANDATORY_FIELDS_MISSING) because mandatory fields and defaults are unknown. 6. This rule has NO exceptions — not even when the user only provided a name and nothing else. 7. 8. === MANDATORY PRE-CREATE CHECK (ALWAYS DO THIS FIRST) === 9. Before creating any test suite, call 'Fetch UDF Layout' with entityType='TS', pageName='ADD'. 10. Response keys use 'TS' — same structure as TC but scoped to test suite module. 11. 12. SYSTEM FIELDS mandatory check — use 'systemFields' array (from qmSDF.TS in newlayout): 13. Each entry: { name, label, fieldTypeName, isMandatory } 14. isMandatory=true (allowBlank=false) means field MUST have a value before creating. 15. 16. UDF FIELDS mandatory check — use 'fields' array (from qmUDF.TS in newlayout): 17. Each entry: { name, label, fieldTypeName, isMandatory, listName? } 18. isMandatory=true means field MUST have a value. 19. 20. DEFAULT VALUES — use 'defaultValues' object (from qmDefaultValue.TS in newlayout): 21. Shape: { fieldName: defaultValueId } e.g. { 'priority': 5232497, 'estimatedTime': 18305 } 22. RULE: isMandatory=true AND defaultValues[field.name] exists → auto-use default, do NOT ask user. 23. RULE: isMandatory=true AND no defaultValues entry → MUST ask user before creating. 24. RULE: isMandatory=false AND defaultValues entry exists → auto-apply if user didn't specify. 25. 26. ╔══════════════════════════════════════════════════════════════════════════╗ 27. ║ PRE-FLIGHT DEFAULT SWEEP — MANDATORY STEP BEFORE EVERY CREATE CALL ║ 28. ╚══════════════════════════════════════════════════════════════════════════╝ 29. After resolving mandatory fields, sweep ALL defaultValues entries: 30. For EACH key in defaultValues: 31. IF the user did not explicitly provide that field → add it to the payload using the default value. 32. This applies regardless of isMandatory — non-mandatory defaults MUST also be auto-applied. 33. Example: defaultValues = { priority: 5232497, estimatedTime: 18305 } 34. → user only said 'create a test suite named X' 35. → payload MUST include: priority=5232497, estimatedTime=18305 36. → WRONG to omit priority/estimatedTime just because they are not mandatory — they have defaults. 37. Skipping this sweep = missing fields in the created record = user-visible data loss. 38. ╚══════════════════════════════════════════════════════════════════════════╝ 39. 40. DECISION MATRIX: 41. | isMandatory | Has default | Action | 42. |-------------|-------------|-------------------------------------| 43. | true | YES | Auto-fill with default, no ask | 44. | true | NO | Ask user before creating | 45. | false | YES | Auto-fill with default — REQUIRED | 46. | false | NO | Skip if user didn't provide | 47. Only after ALL mandatory fields resolved AND default sweep complete → proceed with create. 48. === END MANDATORY PRE-CREATE CHECK === 49. 50. === ERROR RECOVERY: CO.MANDATORY_FIELDS_MISSING === 51. If create fails with error code 'CO.MANDATORY_FIELDS_MISSING', DO NOT give up. Auto-recover: 52. 1. Parse the 'MISSING_FIELDS' list from the error response (comma-separated field labels). 53. 2. Match each label against 'fields[].label' and 'systemFields[].label' from the Fetch UDF Layout response. 54. 3. For matched UDF fields: check 'listOptions[field.listName]' for valid option IDs. 55. 4. For matched system fields (e.g. 'Status'): check 'customListObjs.testSuiteState' from project info. 56. 5. If the field has a 'defaultValues' entry: auto-fill it silently. 57. 6. If no default exists: ask the user ONLY for the missing fields by label. 58. 7. Retry create with the resolved values added to the payload. 59. NEVER ask user to 'try again' manually — resolve and retry automatically. 60. === END ERROR RECOVERY === 61. 62. === DATE FORMAT CHECK (MANDATORY — EVERY CREATE REQUEST) === 63. ALWAYS call 'Fetch QMetry Project Info' before every create request — not only when the user explicitly mentions a date. 64. Any UDF field could be a DATETIMEPICKER. Wrong format causes QMetry to silently discard the field value (API returns success but value is NOT stored — no error). 65. STEP 1: From project info, read dateTimeFormatID (e.g. 3). 66. STEP 2: Find entry in dateTimeFormatNew where id === dateTimeFormatID → read its unique_value (e.g. 'yyyy-MM-dd'). 67. STEP 3: unique_value pattern: yyyy=4-digit year, MM=2-digit month (01-12), dd=2-digit day, MMM=3-letter month (Jan/Feb/...). 68. Example: id=1 → MM-dd-yyyy → '10-25-2000' | id=2 → dd-MM-yyyy → '25-10-2000' | id=3 → yyyy-MM-dd → '2000-10-25' | id=4 → dd-MMM-yyyy → '25-Oct-2000' 69. STEP 4: For EVERY DATETIMEPICKER field in the payload: parse any user-provided date and re-format it using the active unique_value pattern before sending. 70. NEVER assume a date format — always derive it from dateTimeFormatID. Wrong format = silent data loss. 71. === END DATE FORMAT CHECK === 72. 73. If parentFolderId is not provided, it will be auto-resolved to the root test suite folder using project info (rootFolders.TS.id). 74. To get valid values for testsuiteOwner, testSuiteState, etc., call the 'Admin/Get info Service' API (FETCH_PROJECT_INFO tool) and use the returned customListObjs IDs. 75. CRITICAL: For testsuiteOwner mapping - Call API 'Admin/Get info Service', from the response get value from customListObjs.owner[].id. Match the user by customListObjs.owner[].name. 76. If the user provides an owner name (testsuiteOwner), fetch project info, find the matching owner in customListObjs.owner[index].name or customListObjs.owner[index].uniqueLabel, and use its ID in the payload as testsuiteOwner. If the name is not found, skip the testsuiteOwner field (it is not required) and show a user-friendly message: 'Test suite created without owner, as given owner is not available in the current project.' 77. CRITICAL: For testSuiteState mapping - Call API 'Admin/Get info Service', from the response get value from customListObjs.testSuiteState[].id. Match the state by customListObjs.testSuiteState[].name. 78. If the user provides a test suite state name(testSuiteState), fetch project info, find the matching state in customListObjs.testSuiteState[index].name, and use its ID in the payload as testSuiteState. If the name is not found, skip the testSuiteState field (it is not required) and show a user-friendly message: 'Test suite created without test suite state, as given state is not available in the current project.' 79. parentFolderId is required; use the root folder ID from project info (rootFolders.TS.id) or a specific folder. 80. Release/cycle mapping is optional but useful for planning. 81. If the user wants to link or associate a release and cycle to the test suite, set associateRelCyc: true in the payload. 82. CRITICAL: For releaseCycleMapping.releaseId - Call API 'Release/List' (or use project info projects[].releases[].releaseID), from the response get value from data[].releaseID or projects[].releases[].releaseID. Match the release by name. 83. CRITICAL: For releaseCycleMapping.buildID - Call API 'Cycle/List' (or use project info projects[].releases[].builds[].buildID), from the response get value from data[].buildID or projects[].releases[].builds[].buildID. Match the build/cycle by name. 84. If the user provides a release name, map it to its ID from projects[].releases[].releaseID in the project info response, and use that ID as releaseId in releaseCycleMapping. 85. If the user provides a build/cycle name, map it to its ID from projects[].releases[].builds[].buildID in the project info response, and use that ID as buildID in releaseCycleMapping. 86. Example payload: releaseCycleMapping: [ { releaseId: , buildID: } ] 87. Example: For 'Air' release and 'Air Q1-19' cycle in MAC project, use releaseId: 10286 and buildID: 18411 88. LLM should ensure that provided release/cycle names or IDs exist in the current project before using them in the payload. If not found, skip and show a user-friendly message: 'Test suite created without release/cycle association, as given release/cycle is not available in the current project.' 89. All IDs (testSuiteState from customListObjs.testSuiteState[index].id, testsuiteOwner from customListObjs.owner[index].id, releaseId from projects.releases[index].releaseID, buildID from projects.releases.builds[index].buildID) must be valid for your QMetry instance. 90. If a custom field is mandatory, include it in the UDF object. 91. 92. UDF (User Defined Fields) WORKFLOW FOR CREATE: 93. 1. Call 'Fetch UDF Layout' with entityType='TS', pageName='ADD' to discover field names, types, and list option IDs. 94. IF listOptions[field.listName] is empty after Fetch UDF Layout, the tool already tried a metadata fallback. If STILL empty, ask the user to provide the option ID from the QMetry UI — do NOT guess numeric IDs. 95. 2. For LOOKUPLIST fields: pick one ID from listOptions[field.listName][].id. 96. 3. For MULTILOOKUPLIST fields: pick an array of IDs. 97. 4. For CASCADINGLIST fields: pick parent ID, then call 'Fetch Cascade Child Values' for child ID. Pass { parent: parentId, child: childId }. 98. 5. Pass all UDF values via 'udfFields' param: { fieldName: value }. 99. 6. Mandatory UDF fields (isMandatory=true) MUST be included or create will fail. 100. 101. ╔══════════════════════════════════════════════════════════════════╗ 102. ║ POST-CREATE MANDATORY: Link Platform to Test Suite ║ 103. ╚══════════════════════════════════════════════════════════════════╝ 104. AFTER every successful test suite creation, ALWAYS call 'Link Platforms to Test Suite'. 105. Reason: QMetry UI enforces platform association — test suites without a linked platform 106. are invalid for execution and will show validation errors in the UI. 107. STEP 1: Call 'Fetch Platforms' to get available platforms for the project. 108. STEP 2: If the user specified a platform, match by name and use its platformID. 109. If no platform was specified, use the first available non-archived platform. 110. STEP 3: Call 'Link Platforms to Test Suite' with qmTsId= and qmPlatformId=. 111. NEVER report the test suite as successfully created without completing this platform link step. 112. ╚══════════════════════════════════════════════════════════════════╝