DevOps ha avanzado en el mainframe durante los últimos años. Los pipelines se han vuelto más automatizados, las herramientas modernas han pasado a integrarse al ciclo de desarrollo en z/OS y prácticas antes asociadas al universo distribuido comenzaron a formar parte de la rutina de las aplicaciones críticas.
Aun así, existe un punto en el que esa velocidad suele encontrar resistencia: la preparación de la infraestructura necesaria para probar un cambio.
Este cuello de botella cobra relevancia a medida que Platform Engineering se consolida como una evolución del propio DevOps. Según DORA, en 2025, el 90% de las organizaciones encuestadas ya utilizaba algún tipo de plataforma interna de desarrollo y el 76% contaba con equipos dedicados a ellas.
La lógica consiste en reducir la carga operativa de los equipos transformando procesos complejos de infraestructura en capacidades estandarizadas, automatizadas y disponibles en modalidad de autoservicio.
Para el mainframe, esta discusión conduce a una pregunta directa: si el build, la integración y el deployment avanzan hacia modelos cada vez más automatizados, ¿por qué la testabilidad todavía debería depender de solicitudes, colas y preparación manual de entornos?
Automatizar las pruebas no resuelve la espera para poder probar
Una organización puede tener cientos de casos de prueba automatizados y, aun así, mantener un ciclo lento. Esto ocurre cuando las pruebas están listas para ejecutarse, pero el equipo debe esperar la configuración de componentes, la liberación de un entorno o la finalización del trabajo de otro proyecto que utiliza los mismos recursos.
En este escenario, la ejecución fue automatizada, pero la capacidad de realizar pruebas continúa condicionada por la infraestructura.
La diferencia es especialmente importante en el mainframe, donde un único cambio puede involucrar programas, tablas Db2, archivos VSAM, JCL, colas MQ y procesamiento batch u online en CICS e IMS.
Cuando distintos proyectos utilizan esos mismos componentes, el entorno compartido termina determinando cuántos cambios pueden validarse simultáneamente.
El resultado suele manifestarse de formas muy conocidas: colas de pruebas, conflictos entre versiones, dependencia de especialistas y equipos esperando a que la infraestructura esté disponible. La velocidad conquistada durante el desarrollo encuentra entonces un cuello de botella precisamente en el momento de validar lo que fue producido.
Es en este punto donde la idea de testabilidad como plataforma comienza a cobrar sentido. En lugar de tratar cada entorno como una preparación específica y temporal, la organización pasa a estructurar la capacidad de realizar pruebas como una parte permanente de la ingeniería.
Los datos de BMC ayudan a mostrar que este cambio ya está ocurriendo. En su encuesta de mainframe de 2025, el 67% de los encuestados afirmó utilizar DevOps en la plataforma, frente al 63% del año anterior.
Esta evolución va más allá de la adopción de nuevos roles. Platform Engineering trabaja precisamente en la transformación de infraestructura compleja en servicios internos más sencillos de consumir.
DORA asocia esta disciplina con automatización, autoservicio, repetibilidad y golden paths: caminos previamente estructurados para que los desarrolladores puedan realizar tareas recurrentes sin tener que reconstruir el proceso cada vez.
En los entornos de prueba, esto significa reducir la cantidad de trabajo que debe realizarse entre “el código está listo” y “el código puede ser validado”.
Una plataforma de testabilidad debe facilitar, por ejemplo, el aislamiento entre proyectos, la repetición de escenarios, la disponibilidad de los componentes necesarios y la integración con el flujo de desarrollo.
La gobernanza sigue existiendo, pero deja de depender de una secuencia de intervenciones manuales para cada nueva ejecución.
El problema está en la lógica del entorno compartido
Históricamente, una de las respuestas a los conflictos durante las pruebas ha sido crear más entornos. El problema es que replicar infraestructura mainframe para cada necesidad puede generar costos, trabajo de mantenimiento y dificultades de sincronización entre distintas versiones de aplicaciones y datos.
Otra posibilidad consiste en trabajar con un aislamiento más granular: separar aquello que necesita ser diferente en una determinada prueba, sin necesidad de reproducir toda la infraestructura.
Es precisamente en este ámbito donde actúa Eccox Application for Parallel Testing (APT).
La solución automatiza los procesos de preparación de infraestructura para pruebas en IBM z/OS y permite crear pistas aisladas para distintos proyectos. Componentes como load modules, tablas Db2, archivos y JCL pueden clonarse según las necesidades de cada escenario, mientras que CICS, IMS y Db2 continúan siendo recursos reales del entorno mainframe.
La diferencia es importante: APT no emula el comportamiento del mainframe fuera de la plataforma. La aplicación continúa accediendo a procesos, datos y sistemas reales; determinados componentes se aíslan cuando esa pista de pruebas requiere una versión específica.
De este modo, diferentes equipos pueden validar cambios en paralelo sin que una versión de un programa, una tabla o un archivo necesario para un proyecto interfiera directamente en el escenario de otro.
El entorno deja de ser simplemente un espacio compartido y pasa a convertirse en una infraestructura capaz de ofrecer condiciones diferentes para proyectos diferentes.
La idea de autoservicio puede parecer incompatible con un entorno de misión crítica, pero no significa eliminar controles. Significa incorporar esos controles al propio proceso para que las actividades recurrentes no dependan siempre de la intervención manual de un especialista.
En APT, los componentes necesarios para cada pista se definen, aíslan y direccionan hacia ese escenario.
Los planes y casos de prueba también pueden permanecer almacenados para su consulta y reutilización posterior, lo que permite que una configuración ya creada pueda actualizarse y utilizarse nuevamente para mantenimiento, regresión o evolución de una aplicación.
Esta reutilización es relevante porque uno de los costos menos visibles de las pruebas está precisamente en reconstruir condiciones que la organización ya había creado anteriormente.
Cuando la información sobre configuración, componentes y criterios queda dispersa entre procedimientos manuales, tickets o conocimiento individual, reproducir un escenario antiguo puede requerir casi tanto esfuerzo como construirlo por primera vez.
Al transformar ese conocimiento en una estructura reutilizable, la testabilidad comienza a adoptar características propias de una plataforma: estandarización, repetibilidad y una menor dependencia del conocimiento operativo en cada nueva ejecución.
Las pruebas en paralelo afectan principalmente el tiempo de espera
Es común asociar el paralelismo únicamente con la posibilidad de ejecutar más pruebas al mismo tiempo. Sin embargo, su impacto operativo es mayor.
Cuando un proyecto no necesita esperar a que otro termine para utilizar una determinada configuración, desaparece una dependencia. Cuando una pista puede reutilizarse, disminuye el esfuerzo necesario para reconstruir el escenario. Cuando parte de la preparación deja de requerir la intervención del equipo de soporte, se elimina otra etapa del flujo.
Por eso, la madurez del proceso de pruebas no debería medirse solamente por la cantidad de casos automatizados. También es importante observar cuánto tiempo transcurre entre el momento en que el cambio está listo y el momento en que puede comenzar la primera prueba.
Algunas preguntas ayudan a exponer este cuello de botella:
- ¿Cuánto tiempo espera un equipo hasta contar con las condiciones necesarias para realizar una prueba?
- ¿Cuántos proyectos pueden validar cambios simultáneamente?
- ¿Cuánto trabajo manual es necesario para recrear un escenario anterior?
- ¿Cuál es el nivel de dependencia de especialistas o equipos de soporte en cada nuevo ciclo?
Estos indicadores revelan una parte del lead time que con frecuencia desaparece cuando la organización mide únicamente la duración del pipeline o el tiempo de ejecución de la suite de pruebas.
Tratar la testabilidad como plataforma no significa intentar transformar z/OS en Kubernetes ni copiar literalmente la experiencia de una arquitectura distribuida. Platform Engineering es un modelo operativo, no una tecnología específica. Sus principios pueden adaptarse a diferentes contextos y arquitecturas.
Las características del mainframe son diferentes y los mecanismos utilizados para promover la automatización y el autoservicio también deben serlo.
En el caso de APT, la solución trabaja con la propia infraestructura z/OS, creando aislamiento lógico de los componentes necesarios para cada escenario y permitiendo realizar pruebas reales en el entorno mainframe. El producto admite múltiples proyectos en paralelo sin conflictos e integra las pruebas continuas al contexto DevOps.
El objetivo, por lo tanto, no es hacer que el mainframe se comporte como otra plataforma. Es ofrecer a los equipos algo que el desarrollo moderno ha pasado a esperar: más autonomía, repetibilidad y capacidad para trabajar en paralelo sin comprometer la integridad del entorno crítico.
Cuando la testabilidad pasa a formar parte de DevOps
La creciente adopción de Platform Engineering y SRE demuestra que DevOps está ampliando su enfoque. Después de automatizar el código, el build, la integración y el deployment, las organizaciones comenzaron a mirar hacia la infraestructura y hacia la experiencia necesaria para sostener ese flujo.
En el mainframe, las pruebas forman parte de esta próxima etapa.
Si el código puede avanzar automáticamente por el pipeline, pero debe detenerse hasta que alguien prepare las condiciones necesarias para probarlo, existe una ruptura en la integración continua.
Y si varios equipos desarrollan simultáneamente, pero validan de forma secuencial porque compiten por la misma infraestructura, parte de la agilidad conquistada anteriormente desaparece al final del ciclo.
Eccox APT actúa precisamente en este punto: automatizando la preparación de infraestructura para pruebas, ofreciendo aislamiento entre escenarios reales en z/OS y permitiendo que distintos proyectos se ejecuten en paralelo.
La consecuencia es un cambio de perspectiva. Las pruebas dejan de ser una actividad que comienza cuando el entorno finalmente está disponible y pasan a convertirse en una capacidad que ya forma parte de la arquitectura de entrega.
Para las organizaciones que han avanzado en DevOps, este puede ser el próximo cuello de botella que deben enfrentar: no solo automatizar las pruebas, sino garantizar que la infraestructura necesaria para ejecutarlas pueda acompañar la velocidad con la que se producen los cambios.
About Post Author
