How to Automatically Upload Jenkins Test Results to HP ALM / OpenText ALM

Every sprint, QA teams waste hours manually uploading test results from Jenkins to HP ALM (now OpenText ALM / Micro Focus ALM / Quality Center). Someone downloads the JUnit XML, opens ALM, navigates to the right test set, and enters results one by one. If there are failures, they manually create defects. If a test passes that previously failed, they manually close the defect.

This is a solved problem. You just need the right tool.

The manual upload tax

If your team uploads Jenkins results to ALM manually, you're paying a hidden tax on every build:

• Time — 15-30 minutes per upload, multiple times per sprint, across multiple jobs
• Accuracy — manual entry means mismatched statuses, missed failures, and stale defects
• Lag — results arrive in ALM hours or days after the build, not in real time
• Morale — nobody wants to be the person copy-pasting test results

Multiply this across 10 jobs, 5 team members, and 26 sprints a year. That's hundreds of hours of busywork.

The script trap

The natural next step is writing a script. Parse JUnit XML, call the ALM REST API, map test names to Test Plan entities, create test sets in Test Lab, handle defects. Teams have done this for years.

The problem: these scripts are fragile. They break when ALM upgrades. They break when test names change. They break when someone renames a Test Plan folder. And nobody wants to maintain them — they're not the product, they're glue code.

A better approach

BuildButler connects to your Jenkins instance and exports test results to ALM automatically on every build. No scripts to maintain. No manual uploads. No lag.

Here's what happens after each Jenkins build:

1. BuildButler collects test results (JUnit, TestNG, TRX, Allure, Cucumber, or Robot format)
2. Pattern-matching rules map the job to an ALM project, domain, and Test Plan directory
3. Test cases are looked up in Test Plan (or created if using create-minimal mode)
4. A test set is created in Test Lab with a dynamic name (e.g. backend-api #142)
5. Test instances and runs are populated with pass/fail results
6. Defects are created, reopened, or closed based on your policies

All of this happens in seconds, not minutes.

Configuration

You define mapping rules as JSON. Each rule matches Jenkins jobs by glob pattern and routes results to an ALM project:

[
  {
    "jobPattern": "backend/*",
    "domain": "DEFAULT",
    "project": "BackendSuite",
    "testPlanDirectory": "Subject\\Automated\\Backend",
    "testLabDirectory": "Root\\Automated\\{jobName}",
    "testSet": "{jobName} #{buildNumber}"
  }
]

Template variables like {jobName}, {buildNumber}, and {branch} let you name test sets dynamically. Custom properties map to ALM fields via an XML configuration that's compatible with the Bumblebee format — so if you're migrating from Bumblebee, your existing field mappings work as-is.

Automatic defect management

This is where the real time savings come from. BuildButler can:

• Create a defect for every failing test, with configurable severity and status
• Reopen a defect when a previously-passing test fails again
• Close a defect when the corresponding test starts passing

No more stale defects sitting open in ALM for weeks because nobody remembered to close them.

What about the OpenText Application Automation Tools plugin?

OpenText provides an official Jenkins plugin that can upload test results to ALM using YAML-based field mapping. It works, but it's Jenkins-only and the YAML configuration is more complex than BuildButler's JSON rules. If you also use GitHub Actions or GitLab CI, you'll need separate solutions for those — or use BuildButler, which handles all CI systems with the same config.

Not using Jenkins?

This guide focuses on Jenkins, but BuildButler's ALM integration works with any CI system:

• Export GitHub Actions test results to ALM
• Export GitLab CI test results to ALM

Getting started

1. Sign up for BuildButler — the free tier includes ALM integration
2. Install the Jenkins plugin or connect via the API
3. Enter your HP ALM / OpenText ALM credentials in System Settings
4. Define your job mapping rules
5. Run a build and watch results appear in ALM

See the full ALM integration guide for configuration details, or read the complete field reference.