QTM4J: Upload Automation Result

Upload an automation result file to QTM4J and map the results to a test cycle. Supports JUnit XML, TestNG XML, Cucumber JSON, QAF, HP UFT, and SpecFlow formats.

Toolset: Test Automation

Parameters:

• filePath (string) required: Path to the automation result file on disk. Filesystem contents can change between turns — always resolve this from a fresh scan, never from a previously seen path. Supported extensions: .xml, .json, .zip

• format (enum) required: Format of the result file. Supported values: cucumber, testng, junit, qaf, hpuft, specflow

• testCycleToReuse (string): Work key of an existing test cycle to reuse (e.g. 'TR-PRJ-1'). If omitted, a new test cycle is created.

• environment (string): Name of the environment on which the test cycle was executed (e.g. 'Chrome', 'Staging'). Defaults to 'No Environment'.

• build (string): Build name or version for the test cycle execution (e.g. '1.0.0-beta'). Defaults to blank.

• isZip (boolean): Set to true when uploading a ZIP archive containing result files. Required for QAF format. (default: false)

• attachFile (boolean): Set to true to upload attachments referenced in execution results. (default: false)

• matchTestSteps (boolean): true — match test cases by summary AND test steps. false — match by summary or key only. (default: true)

• appendTestName (boolean): Applicable to JUnit/TestNG only. Appends suite/test name to method name in test case summary.

• fields (object): Additional fields to set on the test cycle, test case, and/or test case execution created during import.

Output Description: trackingId to poll import status, a message from the API, the filePath uploaded, and the format used.

Use Cases: 1. Upload automation results to QTM4J 2. Import test results from a CI/CD pipeline run 3. Link test results to an existing test cycle 4. Create a new test cycle from automation results 5. Upload JUnit, TestNG, Cucumber, QAF, HP UFT, or SpecFlow result files

Examples:

1. User says 'upload my test results to QTM4J' — scan workspace, find single result file, confirm and upload

{
  "filePath": "./target/surefire-reports/TEST-results.xml",
  "format": "junit"
}

Expected Output: trackingId returned; import processing started in QTM4J

2. User wants results linked to an existing test cycle

{
  "filePath": "./reports/cucumber.json",
  "format": "cucumber",
  "testCycleToReuse": "TR-PRJ-5",
  "environment": "Chrome",
  "build": "2.1.0"
}

Expected Output: Results mapped to test cycle TR-PRJ-5

3. Upload QAF ZIP and set test cycle metadata

{
  "filePath": "./results/qaf-results.zip",
  "format": "qaf",
  "isZip": true,
  "fields": {
    "testCycle": {
      "summary": "Regression Run 2024-Q1",
      "labels": [
        "regression"
      ],
      "priority": "High"
    }
  }
}

Expected Output: ZIP uploaded; test cycle created with summary, labels, and priority

4. User provides an unrecognised priority value — do NOT silently map to a similar word; ask the user first

{
  "filePath": "./reports/cucumber.json",
  "format": "cucumber",
  "fields": {
    "testCycle": {
      "priority": "critical"
    }
  }
}

Expected Output: Tool is NOT called yet. Inform the user that 'critical' was not recognised as a valid priority and ask them to confirm the correct value (e.g. from the available options). Do not map 'critical' to 'Blocker' or any other value without explicit user confirmation.

Hints: 1. NO PROJECT CONTEXT REQUIRED: Do NOT call set_project_context and do NOT ask the user for a project key, project ID, or any other project details. This tool works independently — never prompt the user for project information. 2. FILE DISCOVERY: Always do a fresh scan — never reuse a path from a previous turn. If no path is provided, search in order: target/surefire-reports, target/failsafe-reports, build/reports/tests, build/test-results, test-results, reports, cucumber-reports. If exactly one file is found, show the path and inferred format to the user and confirm before uploading. If multiple files are found, list them all and wait for the user to pick one. If nothing is found, ask for the path. Never pick or upload silently. 3. FORMAT INFERENCE: .json → cucumber (unambiguous). For .xml, infer from the file name — 'junit'/'surefire' → junit, 'testng' → testng, 'specflow' → specflow, 'hpuft'/'uft' → hpuft. For .zip, ALWAYS set isZip: true, but do NOT assume qaf — the zip could contain junit, testng, or cucumber results; if the format cannot be determined from the file name, ask the user. If the file name gives no clear signal for .xml either, ask the user to confirm the format. 4. TEST CYCLE: Only ask for testCycleToReuse if the user explicitly wants to link to an existing cycle. If not mentioned, omit it — QTM4J creates a new test cycle automatically. 5. DATE FORMAT: plannedStartDate and plannedEndDate in fields.testCycle MUST be formatted as 'dd/MMM/yyyy HH:mm' (e.g. '14/May/2026 10:30'). Convert any user-provided date (ISO, natural language, relative) to this exact format before sending. 6. FOLDER ID: folderId is a numeric ID. Apply it ONLY to the level the user specifies; if unspecified, default to fields.testCycle only — never copy it to both levels. Get the ID from the user directly (right-click folder in QTM4J → 'Copy Folder Id'). 7. ASSIGNEE / REPORTER: assignee and reporter in fields.testCycle and fields.testCase require a Jira Account ID (not a display name or email). Ask the user to provide their Account ID directly. 8. FIELD MAPPING CONFIRMATION: Apply formatting transformations (case correction, date/time conversion) automatically. Only ask for user confirmation when you cannot find a recognised match and need to substitute an unrecognised value with a guessed alternative — never silently substitute in that case. 9. TRACKING: Import processing is asynchronous. To check status, call get_automation_history and find the record whose trackingId matches the one returned from this tool.