Mainframes and shift-left testing might seem like an unlikely combination. Mainframes evoke images of monolithic, slowly-evolving infrastructure, while shift-left testing is a cornerstone of modern, fast-moving CI/CD pipelines. But the two have more in common than you might expect—and applying shift-left principles to mainframe development can deliver significant, practical benefits.
What Is Shift-Left Testing?
Shift-left testing refers to the practice of moving software testing activities earlier in the development lifecycle. The name comes from the idea of a traditional pipeline visualized as a left-to-right timeline: development on the left, deployment on the right, and testing historically clustered near the right end just before release.
Traditionally, most testing occurred in a dedicated QA phase immediately before deployment. This late-stage testing is valuable for verifying production readiness, but it carries a significant cost: defects discovered at that point are expensive to fix. By the time a bug surfaces in a pre-deployment test suite, the code that caused it may already be deeply intertwined with other modules. Diagnosing the root cause, isolating the affected code, applying a fix, and re-verifying that nothing else broke can consume days or weeks of engineering time.
Shift-left testing addresses this by running tests as soon as individual units of code are written—well before integration, staging, or deployment phases. The earlier a defect is caught, the smaller and cheaper it is to fix, because the developer who wrote the code still has it fresh in mind and the surrounding codebase has not yet grown around it.
This approach is especially important in CI/CD pipelines, where teams aim to release application changes on a near-continuous basis. Late-discovered bugs create bottlenecks that undermine the entire goal of continuous delivery. Shift-left testing keeps the pipeline flowing by surfacing problems while they are still small and localised.
Shift-Left Does Not Replace Late-Stage Testing
A common misconception is that shift-left testing means eliminating pre-deployment testing. It does not. Tests performed earlier in the pipeline complement—rather than replace—integration tests, system tests, and acceptance tests run closer to release. The practical effect is that far fewer serious defects survive long enough to reach those later stages, which makes the end-to-end testing phase faster and less disruptive.
Think of shift-left as adding layers of defence earlier in the pipeline, not as removing layers at the end.
Why Shift-Left Testing Matters Even More on the Mainframe
The general benefits of shift-left testing apply to any platform, but several mainframe-specific factors make its adoption especially valuable in that context.
Legacy Languages and Coding Discipline
Most mainframe business logic is written in COBOL, PL/I, or Assembler—languages designed decades before modern software engineering practices became mainstream. These languages do not enforce the same kind of structural discipline as more recent languages. A language like Python, for example, uses indentation as syntax, encourages modular design, and has a rich ecosystem of linting and static analysis tools that steer developers toward fewer mistakes. COBOL and its peers were designed for correctness of computation rather than for guiding developer behaviour. That does not make them error-prone by nature, but it does mean that early automated testing plays an especially important role in catching mistakes that the language itself will not flag.
Legacy Codebases and Complex Dependencies
Many mainframe applications run on codebases that are decades old, with layers of patches, extensions, and dependencies accumulated over time. In environments like these, a seemingly minor change can have unexpected effects on code written years or even decades earlier by engineers who are no longer available to consult. Shift-left testing—particularly automated unit tests and component tests run on every commit—provides a safety net that catches regressions as soon as they are introduced, before they propagate through the pipeline.
The Skills Gap Between QA Engineers and Mainframe Developers
Many QA engineers working in modern enterprises have limited experience with z/OS, COBOL, or mainframe tooling. When a pre-deployment test fails against a mainframe application, a QA team without mainframe expertise may be able to identify that a problem exists but lack the knowledge to diagnose or triage it effectively. This creates a handoff delay: the issue must be routed back to a mainframe developer, who must then reconstruct the context of what was being tested.
Shift-left testing shortens this feedback loop by returning test results to the mainframe developer who wrote the code, immediately after they write it. The developer still has full context, the code change is small and recent, and the fix can often be applied in minutes rather than days.
How to Implement Shift-Left Testing for Mainframe Applications
Tooling for mainframe shift-left testing exists and has matured considerably. The following options are worth evaluating for teams working on IBM Z platforms.
IBM Z Unit Testing
IBM offers Z Unit, a unit-testing framework for z/OS programs. Z Unit is available as part of IBM Z Open Unit Test and IBM Developer for z Systems. It allows z/OS developers to write and automatically generate unit tests for batch and CICS programs as part of their normal development workflow. Tests can be stored in any standard source control management (SCM) system and executed independently of the runtime environment, making them straightforward to integrate into a CI pipeline.
Testing Mainframe Code on Non-Mainframe Hardware
IBM’s Z Development and Test Environment allows teams to create virtual IBM Z environments on standard x86 hardware. This means developers can write, build, and run unit tests for mainframe applications on commodity servers or developer workstations, without requiring access to dedicated mainframe capacity for every test run. Reducing the dependency on shared mainframe LPAR time for early-stage testing is a meaningful enabler of shift-left practices, since it removes a scheduling bottleneck that would otherwise slow down the feedback loop.
Integrating Mainframe Tests into CI Pipelines
For shift-left testing to deliver its full value, tests need to run automatically on every code change, not just when a developer remembers to run them manually. This means integrating mainframe unit tests into the same CI tooling—Jenkins, Azure DevOps, GitLab CI, or similar—used for the rest of the software delivery pipeline. Modern mainframe DevOps tooling increasingly supports this integration, allowing z/OS builds and tests to be triggered by the same mechanisms as any other pipeline stage.
Key practices to implement alongside the tooling include:
- Writing unit tests alongside new code: Developers should write tests for new COBOL or PL/I components at the same time as the components themselves, not as an afterthought.
- Storing tests in source control: Test cases should live alongside production code in the same SCM repository so they are versioned, reviewed, and maintained together.
- Running tests on every commit: CI jobs should trigger the full unit test suite on every push to the main branch, not only on scheduled builds or release candidates.
- Tracking test coverage: As the test suite grows, monitor which code paths are covered to identify areas of the codebase that remain untested and therefore carry higher risk.
Conclusion
Shift-left testing is not a practice reserved for greenfield cloud-native applications. Whether your mainframe codebase was written last year or has been in production for decades, moving testing earlier in the delivery pipeline reduces the cost and disruption of defects, speeds up the CI/CD feedback loop, and helps bridge the skills gap between QA teams and mainframe developers.
The tooling to support this approach on IBM Z platforms exists today. The barrier to adoption is rarely technical—it is organisational. Teams that invest in building shift-left testing habits into their mainframe development culture will find it considerably easier to achieve the kind of continuous, reliable delivery that modern business demands.
This article was originally based on content published at devops.com.