DevOps has advanced significantly on the mainframe in recent years. Pipelines have become more automated, modern tools have been integrated into the z/OS development lifecycle, and practices once associated primarily with distributed environments have become part of the routine of mission-critical applications.
Even so, there is one point where that speed often encounters resistance: preparing the infrastructure required to test a change.
This bottleneck becomes even more relevant as Platform Engineering establishes itself as an evolution of DevOps itself. According to DORA, in 2025, 90% of surveyed organizations were already using some form of internal development platform, and 76% had dedicated platform teams.
The idea is to reduce the operational burden on teams by transforming complex infrastructure processes into standardized, automated capabilities available through self-service.
For the mainframe, this leads to a straightforward question: if build, integration, and deployment are moving toward increasingly automated models, why should testability still depend on requests, queues, and manual environment preparation?
Automating tests does not eliminate the wait to test
An organization can have hundreds of automated test cases and still maintain a slow delivery cycle. This happens when the tests are ready to run, but the team still has to wait for components to be configured, an environment to become available, or another project using the same resources to finish.
In this scenario, test execution has been automated, but the ability to test remains constrained by infrastructure.
This distinction is particularly important on the mainframe, where a single change may involve programs, Db2 tables, VSAM files, JCLs, MQ queues, and batch or online processing in CICS and IMS.
When different projects rely on those same components, the shared environment ultimately determines how many changes can be validated simultaneously.
The result tends to appear in very familiar forms: test queues, version conflicts, dependency on specialists, and teams waiting for infrastructure to become available. The speed gained during development then encounters a bottleneck precisely when the work needs to be validated.
This is where the idea of testability as a platform starts to make sense. Instead of treating each environment as a specific, temporary setup, the organization begins to structure the ability to test as a permanent engineering capability.
Data from BMC helps show that this shift is already underway. In its 2025 mainframe survey, 67% of respondents said they were using DevOps on the platform, up from 63% the previous year.
At the same time, 47% of organizations already had Platform Engineers, while another 31% planned to add them. For SRE roles, the figures were 43% and 35%, respectively.
This evolution goes beyond the adoption of new job titles. Platform Engineering is fundamentally about turning complex infrastructure into internal services that are easier to consume.
DORA associates the discipline with automation, self-service, repeatability, and golden paths: predefined paths that allow developers to perform recurring tasks without rebuilding the process every time.
In testing environments, that means reducing the amount of work required between “the code is ready” and “the code can be validated.”
A testability platform should make it easier to provide project isolation, repeat scenarios, ensure the availability of required components, and integrate testing into the development workflow.
Governance remains in place, but it no longer needs to depend on a sequence of manual interventions for every new execution.
The problem lies in the shared-environment model
Historically, one response to testing conflicts has been to create more environments. The problem is that replicating mainframe infrastructure for every need can introduce cost, maintenance overhead, and synchronization challenges across different versions of applications and data.
Another approach is to work with more granular isolation: separating what needs to be different for a specific test without necessarily replicating the entire infrastructure.
This is where Eccox Application for Parallel Testing (APT) operates.
The solution automates test infrastructure preparation processes on IBM z/OS and enables isolated test lanes for different projects. Components such as load modules, Db2 tables, files, and JCLs can be cloned according to the needs of each scenario, while CICS, IMS, and Db2 remain real resources within the mainframe environment.
The distinction matters: APT does not emulate mainframe behavior outside the platform. The application continues to access real processes, data, and systems; specific components are isolated whenever a test lane requires a particular version.
As a result, different teams can validate changes in parallel without a program version, table, or file required by one project directly interfering with another project’s scenario.
The environment stops being simply a shared place and becomes infrastructure capable of providing different conditions for different projects.
The idea of self-service may seem incompatible with a mission-critical environment, but it does not mean eliminating controls. It means embedding those controls into the process itself so that recurring activities do not always depend on manual intervention from a specialist.
With APT, the components required for each test lane are defined, isolated, and routed to that specific scenario.
Test plans and test cases can also remain stored for future reference and reuse, allowing an existing configuration to be updated and used again for application maintenance, regression testing, or evolution.
This reuse matters because one of the less visible costs of testing lies precisely in rebuilding conditions the organization has already created before.
When configuration details, components, and criteria are scattered across manual procedures, tickets, or individual knowledge, reproducing an old scenario may require almost as much effort as building it for the first time.
By turning that knowledge into a reusable structure, testability begins to take on the characteristics of a platform: standardization, repeatability, and less dependence on operational knowledge for every new execution.
Parallel testing primarily changes waiting time
Parallelism is often associated simply with the ability to run more tests at the same time. Its operational impact, however, goes further.
When one project does not need to wait for another to finish using a particular configuration, a dependency disappears. When a test lane can be reused, the effort required to rebuild the scenario decreases. When part of the preparation no longer requires intervention from support teams, another step is removed from the flow.
That is why testing maturity should not be measured only by the number of automated test cases. It is also important to understand how much time passes between a change being ready and the first test actually being able to start.
A few questions can help expose this bottleneck:
- How long does a team wait for the conditions required to test?
- How many projects can validate changes simultaneously?
- How much manual work is required to recreate a previous scenario?
- How dependent is each new cycle on specialists or support teams?
These indicators reveal a portion of lead time that often disappears when organizations measure only pipeline duration or test-suite execution time.
Treating testability as a platform does not mean trying to turn z/OS into Kubernetes or literally replicate the experience of a distributed architecture. Platform Engineering is an operating model, not a specific technology. Its principles can be adapted to different contexts and architectures.
Mainframe characteristics are different, and the mechanisms used to enable automation and self-service need to reflect those differences.
APT works with the z/OS infrastructure itself, creating logical isolation for the components required by each scenario and enabling real testing within the mainframe environment. The product supports multiple parallel projects without conflict and integrates continuous testing into the DevOps context.
The goal, therefore, is not to make the mainframe behave like another platform. It is to give teams something modern development has come to expect: greater autonomy, repeatability, and the ability to work in parallel without compromising the integrity of the critical environment.
When testability becomes part of DevOps
The growing adoption of Platform Engineering and SRE shows that DevOps is expanding its focus. After automating code, build, integration, and deployment, organizations have begun looking more closely at the infrastructure and developer experience required to sustain that flow.
On the mainframe, testing is part of this next stage.
If code can move automatically through the pipeline but then has to stop until someone provides the conditions required for testing, there is a break in continuous integration.
And if multiple teams develop simultaneously but validate sequentially because they are competing for the same infrastructure, some of the agility gained earlier in the lifecycle disappears near the end of the process.
Eccox APT addresses this point by automating test infrastructure preparation, providing isolation between real z/OS scenarios, and allowing different projects to run in parallel.
The result is a shift in perspective. Testing stops being an activity that begins once the environment finally becomes available and becomes a capability that is already built into the delivery architecture.
For organizations that have already advanced their DevOps practices, this may be the next bottleneck to address: not simply automating tests, but ensuring that the infrastructure required to run them can keep pace with the speed at which changes are being produced.