O DevOps avançou no mainframe nos últimos anos. Pipelines ficaram mais automatizadas, ferramentas modernas passaram a integrar o ciclo de desenvolvimento em z/OS e práticas antes associadas ao universo distribuído começaram a fazer parte da rotina de aplicações críticas.
Ainda assim, existe um ponto em que essa velocidade frequentemente encontra resistência: a preparação da infraestrutura necessária para testar uma mudança.
Esse gargalo ganha relevância quando Platform Engineering se consolida como uma evolução do próprio DevOps. Segundo o DORA, em 2025, 90% das organizações pesquisadas já utilizavam alguma plataforma interna de desenvolvimento e 76% contavam com times dedicados a elas.
A lógica é reduzir a carga operacional sobre as equipes ao transformar processos complexos de infraestrutura em capacidades padronizadas, automatizadas e disponíveis em self-service.
Para o mainframe, essa discussão leva a uma pergunta direta: se build, integração e deployment caminham para modelos cada vez mais automatizados, por que a testabilidade ainda deveria depender de solicitações, filas e preparação manual de ambientes?
Automatizar o teste não resolve a espera pelo teste
Uma organização pode ter centenas de casos automatizados e, ainda assim, manter um ciclo lento. Isso acontece quando os testes estão prontos para execução, mas a equipe precisa esperar pela configuração de componentes, pela liberação de um ambiente ou pelo término do trabalho de outro projeto que utiliza os mesmos recursos.
Nesse cenário, a execução foi automatizada, mas a capacidade de testar continua condicionada à infraestrutura.
A diferença é especialmente importante no mainframe, onde uma única alteração pode envolver programas, tabelas Db2, arquivos VSAM, JCLs, filas MQ e processamento batch ou online em CICS e IMS.
Quando diferentes projetos utilizam esses mesmos componentes, o ambiente compartilhado acaba determinando quantas mudanças podem ser validadas simultaneamente.
O resultado costuma aparecer em formas bastante conhecidas: filas de teste, conflitos entre versões, dependência de especialistas e equipes esperando a infraestrutura ficar disponível. A velocidade conquistada no desenvolvimento encontra, então, um gargalo justamente no momento de validar aquilo que foi produzido.
É nesse ponto que a ideia de testabilidade como plataforma começa a fazer sentido. Em vez de tratar cada ambiente como uma preparação específica e temporária, a organização passa a estruturar a capacidade de testar como parte permanente da engenharia.
Os números da BMC ajudam a mostrar que essa mudança já está acontecendo. Na pesquisa de mainframe de 2025, 67% dos respondentes disseram utilizar DevOps na plataforma, contra 63% no ano anterior.
Essa evolução vai além da adoção de novas funções. Platform Engineering trabalha justamente com a transformação de infraestrutura complexa em serviços internos mais simples de consumir.
O DORA associa essa disciplina a automação, self-service, repetibilidade e golden paths: caminhos previamente estruturados para que desenvolvedores realizem tarefas recorrentes sem reconstruir o processo toda vez.
No ambiente de testes, isso significa reduzir a quantidade de trabalho que precisa acontecer entre “o código está pronto” e “o código pode ser validado”.
Uma plataforma de testabilidade precisa facilitar, por exemplo, isolamento entre projetos, repetição de cenários, disponibilidade dos componentes necessários e integração com o fluxo de desenvolvimento.
A governança continua existindo, mas deixa de depender de uma sequência de intervenções manuais para cada nova execução.
O problema está na lógica do ambiente compartilhado
Historicamente, uma das respostas aos conflitos de teste foi criar mais ambientes. O problema é que replicar infraestrutura mainframe para cada necessidade pode trazer custos, trabalho de manutenção e sincronização entre diferentes versões de aplicações e dados.
Outra possibilidade é trabalhar com isolamento mais granular: separar aquilo que precisa ser diferente naquele teste, sem necessariamente reproduzir toda a infraestrutura.
É nesse território que atua o Eccox Application for Parallel Testing (APT).
A solução automatiza processos de preparação da infraestrutura de testes em IBM z/OS e permite criar pistas isoladas para diferentes projetos. Componentes como load modules, tabelas Db2, arquivos e JCLs podem ser clonados de acordo com a necessidade do cenário, enquanto CICS, IMS e Db2 continuam sendo recursos reais do ambiente mainframe.
A diferença é importante: o APT não emula o comportamento do mainframe fora da plataforma. A aplicação continua acessando processos, dados e sistemas reais; determinados componentes são isolados quando aquela pista de teste exige uma versão específica.
Com isso, diferentes equipes podem validar alterações paralelamente sem que uma versão de programa, uma tabela ou um arquivo necessário para determinado projeto interfira diretamente no cenário de outro.
O ambiente deixa de ser apenas um lugar compartilhado e passa a ser uma infraestrutura capaz de oferecer condições diferentes para projetos diferentes.
A ideia de self-service pode parecer incompatível com um ambiente de missão crítica, mas não significa eliminar controles. Significa incorporar esses controles ao próprio processo para que atividades recorrentes não dependam sempre da intervenção manual de um especialista.
No APT, os componentes necessários à pista são definidos, isolados e direcionados para aquele cenário.
Os planos e casos de teste também podem permanecer armazenados para consulta e reutilização posterior, permitindo que uma configuração já construída seja atualizada e utilizada novamente em manutenção, regressão ou evolução de uma aplicação.
Essa reutilização é relevante porque um dos custos menos visíveis dos testes está justamente em reconstruir condições que a organização já havia criado antes.
Quando informações sobre configuração, componentes e critérios ficam dispersas em procedimentos manuais, chamados ou conhecimento de indivíduos, reproduzir um cenário antigo pode exigir quase tanto esforço quanto montá-lo pela primeira vez.
Ao transformar esse conhecimento em uma estrutura reutilizável, a testabilidade começa a assumir características de plataforma: padronização, repetibilidade e menor dependência de conhecimento operacional para cada nova execução.
Testes paralelos mexem principalmente com o tempo de espera
É comum associar paralelismo apenas à possibilidade de executar mais testes ao mesmo tempo. O efeito operacional, porém, é maior.
Quando um projeto não precisa esperar outro terminar para utilizar determinada configuração, desaparece uma dependência. Quando uma pista pode ser reutilizada, diminui o esforço para reconstruir o cenário. Quando parte da preparação deixa de exigir intervenção de sustentação, reduz-se mais uma etapa do fluxo.
Por isso, a maturidade do processo de testes não deveria ser medida apenas pela quantidade de casos automatizados. Também importa observar quanto tempo existe entre a mudança ficar pronta e o primeiro teste conseguir começar.
Algumas perguntas ajudam a expor esse gargalo:
- Quanto tempo uma equipe espera pela condição necessária para testar?
- Quantos projetos conseguem validar mudanças simultaneamente?
- Quanto trabalho manual é necessário para recriar um cenário anterior?
- Qual é a dependência de especialistas ou equipes de suporte para cada novo ciclo?
Esses indicadores revelam uma parte do lead time que frequentemente desaparece quando a organização mede apenas duração da pipeline ou tempo de execução da suíte.
Tratar testabilidade como plataforma não significa tentar transformar z/OS em Kubernetes ou copiar literalmente a experiência de uma arquitetura distribuída. Platform Engineering é um modelo operacional, não uma tecnologia específica. Seus princípios podem ser adaptados a diferentes contextos e arquiteturas.
As características do mainframe são diferentes e os mecanismos utilizados para promover automação e self-service também precisam ser.
No caso do APT, a solução trabalha com a própria infraestrutura z/OS, criando isolamento lógico dos componentes necessários ao cenário e permitindo testes reais no ambiente mainframe. O produto suporta múltiplos projetos paralelos sem conflito e integra testes contínuos ao contexto DevOps.
O objetivo, portanto, não é fazer o mainframe se comportar como outra plataforma. É oferecer às equipes algo que o desenvolvimento moderno passou a esperar: mais autonomia, repetibilidade e capacidade de trabalhar em paralelo sem comprometer a integridade do ambiente crítico.
Quando testabilidade passa a fazer parte do DevOps
A adoção crescente de Platform Engineering e SRE mostra que o DevOps está expandindo seu foco. Depois de automatizar código, build, integração e deployment, as organizações começaram a olhar para a infraestrutura e para a experiência necessária para sustentar esse fluxo.
No mainframe, os testes fazem parte dessa próxima etapa.
Se o código consegue avançar automaticamente pela esteira, mas precisa parar até que alguém disponibilize sua condição de teste, existe uma ruptura na integração contínua.
E, se várias equipes desenvolvem simultaneamente mas validam sequencialmente porque disputam a mesma infraestrutura, parte da agilidade conquistada anteriormente desaparece no final do ciclo.
O Eccox APT atua nesse ponto: automatizando a preparação de infraestrutura para testes, oferecendo isolamento entre cenários reais em z/OS e permitindo que diferentes projetos sejam executados em paralelo.
A consequência é uma mudança de perspectiva. Testar deixa de ser uma atividade que começa quando o ambiente finalmente fica disponível e passa a ser uma capacidade que já faz parte da arquitetura de entrega.
Para organizações que avançaram em DevOps, esse pode ser o próximo gargalo a enfrentar: não apenas automatizar o teste, mas garantir que a infraestrutura necessária para executá-lo consiga acompanhar a velocidade com que as mudanças são produzidas.
About Post Author
