ALM / Quality Center review: pricing, alternatives and setup

OpenText inherited two related products from Micro Focus. ALM/Quality Center, the older one, is now sold as OpenText Application Quality Management, with Express, Enterprise and ALM editions; its help centre is at version 26.1. ALM Octane, built later as a web application for agile teams, is now documented as OpenText Software Delivery Management, at version 26.3, sold in Premium and Ultimate tiers with a Developer add-on. Both remain available, and the Application Quality Management help points customers who want to modernise towards Octane. The names matter in practice, because help centre addresses, community spaces and older articles still use ALM and Octane.

Application Quality Management is a Java EE application served by its own application server, which runs on Windows or Linux. Data sits in Oracle or Microsoft SQL Server: one site administration schema for users, domains and settings, plus a separate schema for every project, with attachments and other files in a project repository on disk. When users open the classic client, components are downloaded to their machine and talk to each other through .NET and COM, which is why that client is Windows-bound; a browser-based Web Client is also available, and the 26.1 release notes list a run of enhancements for it. Per-project schemas explain both its strength, isolated projects, and its weakness, cross-project work that needs extra tooling.

Application Quality Management organises work as a fixed lifecycle. You define releases and cycles, then requirements describing what must be achieved, then tests in the Test Plan module, linked to requirements through coverage. In the Test Lab module you group tests into test sets and run them, manually or through automation tools such as UFT One. Failures become defects in the Defects module, linked back to the run, test and requirement. Reports and graphs read across all of it. The structure is the product: it makes coverage and traceability questions easy to answer, and it makes lightweight, exploratory or code-first working feel heavy.

Software Delivery Management is a web application organised into shared spaces, which hold users and shared settings, and workspaces, which hold a team’s or product’s backlog, tests, pipelines and defects. Automated testing connects through CI integrations and a test-results REST resource. A CI job posts an XML payload of test runs; the server validates it against an XSD, processes it asynchronously, and creates or updates automated tests and runs. A test is identified by its component, package, class and name, so the same identity on the next build updates the existing test’s run history instead of creating a new test.

Because Software Delivery Management identifies an automated test by component, package, class and name, those four values are the contract between your code and its test inventory. Map them deliberately: the module or service to component, the namespace to package, the test class to class and the method to name. Renaming any of them creates a new test and leaves the old one without new runs, which breaks history and coverage. If the same test runs on several browsers or environments, use environment labels or test characteristics rather than changing names, and reserve external_run_id for runs that are distinct for some other reason. Note that posting an identical payload twice returns the earlier task rather than processing it again.

OpenText supplies a GitHub Actions integration that reports workflows, pipelines and JUnit results to Software Delivery Management, and that is the better long-term route because it links pipeline runs and commits. Where you only need results, a short REST step works with any CI and is easy to reason about: sign in with keys held as secrets, convert or generate the XML payload, post it, and check the task status so a rejected payload fails the job instead of passing silently. Run the step even when tests fail. Post in batches rather than one request per test, since processing is asynchronous and every payload becomes a task.

Traceability is only as good as the links people create. Keep the requirement tree close to how auditors and product owners talk about scope, and make test coverage of requirements part of the definition of done for test design. In Test Lab, build test sets per cycle and purpose, such as regression, smoke or release acceptance, rather than one ever-growing set, so execution reports mean something. Link defects from the failed run rather than creating them separately, which keeps the chain from requirement to defect intact. Since 26.1, site administrators can stop users adding new test coverage to requirements through a site parameter, which helps lock down validated releases.

For teams moving from Application Quality Management or Jira to Software Delivery Management, OpenText’s getting-started guide points to Shift, a migration tool on the OpenText Marketplace that migrates Application Quality Management, Silk Central and Jira projects. For synchronising with other tools, Integration Hub is now the designated solution, and the older ALM Octane Synchronizer is no longer supported, so any integration still built on Synchronizer needs replacing. On upgrades to 26.3, note the new display limit of 100,000 items in backlog, feature and defect grids and boards, and that some string filter operators were relabelled, both of which can change saved views.