- CT-QDO (Certified Tester Quality in DevOps) es la certificación de ISTQB sobre cómo asegurar la calidad y probar en equipos que trabajan con DevOps.
- Es un módulo Specialist nuevo: la versión 1.0 del syllabus se liberó en abril de 2026.
- Requisito: certificación ISTQB Foundation Level (CTFL); se recomienda al menos algo de experiencia en desarrollo o pruebas.
- Tiene 4 capítulos y exige un mínimo de 20.2 horas de formación acreditada en al menos tres días; el capítulo más largo es el de tareas automatizadas y manuales en DevOps.
- El examen tiene 40 preguntas de opción múltiple, dura 60 minutos (75 si no es tu lengua materna) y se aprueba con alrededor del 65% de los puntos.
- Cubre métricas DORA, CALMS, las tres vías de DevOps, SRE, pruebas continuas, pull requests, CI/CD, API y contract testing, crowd testing, quality hunting, feature toggles, chaos engineering, observabilidad, SBOM y contenedores.
- Es para testers, pero también para desarrolladores, ingenieros DevOps y SRE, scrum masters y product owners.
En muchos equipos el tester sigue sintiendo que DevOps "le pasó por encima": el pipeline despliega varias veces al día, las pruebas manuales ya no caben en el ciclo y nadie tiene claro dónde encaja QA. La certificación ISTQB CT-QDO responde exactamente eso: cómo se construye la calidad en cada etapa del flujo de valor de DevOps y qué papel juegan las pruebas, automatizadas y manuales.
En esta guía te explico qué es CT-QDO, para quién es, qué objetivos de negocio persigue, qué dice el syllabus capítulo por capítulo, cómo es el examen y cómo prepararte.
Qué es CT-QDO y dónde está en el portafolio ISTQB
CT-QDO es un módulo Specialist de ISTQB. La versión vigente es la v1.0, con liberación general el 17 de abril de 2026. Según el propio syllabus, nace porque DevOps se volvió la forma dominante de desarrollar software en muchos dominios y ISTQB quería ofrecer una certificación internacional específica para la calidad en ese contexto.
El syllabus parte de Foundation (CTFL 4.0) y se apoya en los programas ágiles y de automatización de ISTQB. Como él mismo explica, los syllabus ágiles enseñan cómo se prueba en un equipo ágil y los de automatización enseñan cómo se construye y usa la automatización; CT-QDO extiende eso hacia la cultura DevOps. Puedes ver el mapa completo y los costos en tu moneda en nuestra guía de la certificación ISTQB.
Para quién es y requisitos previos
El syllabus está pensado para profesionales de calidad y pruebas en un entorno DevOps, y ISTQB lo abre también a desarrolladores, ingenieros DevOps y SRE, scrum masters y product owners, porque en DevOps la calidad es responsabilidad de todos.
- Requisito formal: certificación ISTQB Foundation Level (CTFL v4.0 o anterior) e interés en pruebas y DevOps. Si te falta Foundation, empieza con nuestro curso ISTQB Fundamentos 4.0.
- Muy recomendado: al menos una experiencia mínima en desarrollo o pruebas, por ejemplo seis meses como tester de sistema o de aceptación, o como desarrollador, y tomar un curso acreditado.
- Útil, aunque no obligatorio: conocer los syllabus ágiles (Agile Tester) y de automatización (TAE o TAS), y haber visto un pipeline de CI/CD funcionando.
Qué serás capaz de hacer: objetivos de negocio
El syllabus define nueve objetivos de negocio. Una persona certificada en CT-QDO puede:
| Código | Objetivo de negocio |
|---|---|
| QDO-BO1 | Explicar cómo el aseguramiento de la calidad apoya y contribuye a los conceptos de DevOps |
| QDO-BO2 | Entender los conceptos para implementar DevOps en una organización |
| QDO-BO3 | Contribuir en todas las etapas del flujo de valor para apoyar la ingeniería de calidad |
| QDO-BO4 | Contribuir a la implementación del ciclo DevOps |
| QDO-BO5 | Describir cómo la automatización apoya el aseguramiento de la calidad en DevOps |
| QDO-BO6 | Implementar automatización de pruebas en equipos DevOps |
| QDO-BO7 | Implementar pruebas manuales en equipos DevOps |
| QDO-BO8 | Seleccionar herramientas que apoyen DevOps en la organización |
| QDO-BO9 | Entender tecnologías y prácticas que apoyan la calidad en DevOps |
Los objetivos de aprendizaje van de K1 a K3. Los keywords de cada capítulo se evalúan a nivel K2 (debes entenderlos, no solo recordarlos). Hay objetivos prácticos de H0 a H2; casi todos son H2, ejercicios con pistas sobre un caso realista.
Contenido del syllabus capítulo por capítulo
| Capítulo | Tiempo mínimo | Temas clave |
|---|---|---|
| 1. Fundamentos de DevOps | 140 min | Conceptos clave, muro de la confusión, métricas DORA, CALMS, las tres vías, beneficios y riesgos, roles, SRE, topologías y antipatrones |
| 2. Aseguramiento de la calidad y pruebas en DevOps | 360 min | QA en el flujo de valor, objetivos de prueba por modelo de ciclo de vida, pruebas continuas, pull requests, QA en discovery, CI, entrega y despliegue continuos, release on demand, implementación de un pipeline |
| 3. Tareas automatizadas y manuales en DevOps | 510 min | Fuente única de verdad del testware, trazabilidad, reportes de calidad, datos y entornos de prueba, regresión en el pipeline, pruebas de API y de contrato, exploratorias, crowd testing, quality hunting |
| 4. Herramientas y prácticas en DevOps | 200 min | Capacidades de las herramientas, actividades no de prueba en el pipeline, estrategias de liberación, infraestructura como código, feature toggles, branching, chaos engineering, telemetría y observabilidad, SBOM, contenedores |
Capítulo 1. Fundamentos de DevOps
El capítulo arranca con los conceptos clave de DevOps y con una metáfora que todo tester ha vivido: el muro de la confusión. Del lado de desarrollo se quiere cambiar rápido; del lado de operaciones se quiere estabilidad. El resultado son silos, procesos manuales y entornos inconsistentes. DevOps derriba ese muro, y el syllabus subraya que QA y las pruebas son un factor clave para hacerlo porque cruzan ambos lados.
Luego explica las métricas DORA, con las que se mide el desempeño de entrega:
- Throughput: tiempo de espera de un cambio (de commit a producción) y frecuencia de despliegue.
- Estabilidad: porcentaje de cambios que fallan en producción y tiempo de recuperación de un despliegue fallido.
DORA agregó la confiabilidad (disponibilidad, latencia, rendimiento, escalabilidad) como indicador del desempeño operativo, y el syllabus muestra cómo QA la mejora con enfoques test-first, pruebas no funcionales, chaos engineering y quality hunting.
Después vienen CALMS (cultura, automatización, lean, medición y compartir) vistos desde QA, y las tres vías de DevOps de The Phoenix Project: flujo, retroalimentación y aprendizaje continuo. Por ejemplo, QA apoya el flujo con enfoques test-first, la retroalimentación con automatización continua y monitoreo, y el aprendizaje con eventos de calidad y buenas suites de regresión.
La segunda mitad trata la implementación en la organización: roles en un equipo DevOps, Site Reliability Engineering (SRE) con sus SLA, SLO y SLI (por ejemplo, un SLO de "99.9% de disponibilidad mensual" medido por un SLI de solicitudes exitosas), y las topologías de equipo: colaboración Dev y Ops, responsabilidades de operación totalmente compartidas, o equipo SRE. También los antipatrones: silos Dev y Ops, "Dev no necesita a Ops" y el famoso "equipo DevOps" que solo administra herramientas.
Capítulo 2. Aseguramiento de la calidad y pruebas en DevOps
Seis horas dedicadas a dónde y cómo aporta QA. Primero, en el flujo de valor: la calidad del producto, de los procesos y de las personas. Después compara los objetivos de prueba en DevOps frente a modelos secuenciales y ágiles.
Un tema central es la prueba continua (continuous testing): probar desde el concepto hasta producción y más allá. Sus principios: probar temprano y seguido, colaboración multifuncional (la calidad es de todos), automatización integrada, monitoreo y observabilidad en producción, y mejora adaptativa. Como ejemplo de marco cita el holistic testing de Janet Gregory y Lisa Crispin.
También explica por qué los pull requests son una herramienta de calidad: promueven revisión y conocimiento compartido, disparan pruebas automáticas, refuerzan estándares con análisis estático, mejoran la trazabilidad, favorecen cambios pequeños y actúan como quality gate.
Luego recorre el ciclo DevOps etapa por etapa y el papel de QA en cada una: continuous discovery, integración continua (CI), entrega continua (CD), despliegue continuo (con estrategias como canary, blue-green o dark launching) y release on demand. Cierra con un objetivo K3: implementar un pipeline de CI/CD en seis pasos: modelar el flujo de valor desde commit hasta release con un walking skeleton, automatizar build y despliegue, automatizar la etapa de commit, automatizar la etapa de aceptación, automatizar el release y evolucionar el pipeline.
Capítulo 3. Tareas automatizadas y manuales en DevOps
Es el capítulo más largo: más de ocho horas. Se divide en tres bloques.
Cómo la automatización apoya a QA: una fuente única de verdad para el testware (casos, scripts y datos versionados junto al código), trazabilidad automática entre base de prueba y testware, reportes de calidad uniformes en el pipeline que combinan resultados automáticos y manuales (objetivo K3), automatización de la gestión de datos de prueba, análisis estadístico de resultados a lo largo del tiempo (por ejemplo, para detectar pruebas inestables o flaky) y entornos de prueba estandarizados, controlados y automatizados.
Automatización en equipos DevOps: cómo encaja la regresión en cada etapa del pipeline, la preparación de pruebas de API (K3), incluido el contract testing entre servicios, y una comparación del grado de automatización en DevOps frente a ágil y secuencial. Si quieres practicar pruebas de API, nuestro curso de API Automation con Postman es un buen complemento.
Pruebas manuales en DevOps: sí, siguen existiendo. El syllabus da ejemplos de pruebas manuales valiosas, explica cómo integrar las pruebas exploratorias en el pipeline, cómo el crowd testing refuerza la cultura de retroalimentación y presenta los quality hunting events (K3): equipos pequeños compiten durante un tiempo limitado por dar la evaluación más valiosa del nivel de calidad del producto. A diferencia del bug hunting, el objetivo no es cazar la mayor cantidad de defectos, sino obtener una visión compartida de la calidad y del riesgo.
Capítulo 4. Herramientas y prácticas en DevOps
El último capítulo es un recorrido amplio, mayormente K1 y K2. Primero, las capacidades de las herramientas en DevOps y las que apoyan QA y pruebas, para que sepas seleccionarlas. Luego, las actividades no de prueba dentro del pipeline (como análisis de seguridad o empaquetado) y las estrategias de liberación: canary, blue-green, rolling, phased rollout, progressive delivery, hotfix y dark launching.
Después, un repaso de prácticas que todo tester en DevOps debe reconocer:
- Infraestructura como código (IaC): los entornos se definen en archivos versionados, así que también se revisan y prueban.
- Feature toggles: separan el despliegue de la liberación; el código está en producción pero la función se enciende cuando el negocio decide. Implican probar ambas rutas.
- Estrategias de branching.
- Chaos engineering: provocar fallas controladas para verificar la resiliencia.
- Telemetría y observabilidad: extender las pruebas a producción con datos reales de uso.
- SBOM (Software Bill of Materials): el inventario de componentes de software, clave para la gestión de configuración y la seguridad de la cadena de suministro.
- Contenedores.
Descarga el syllabus oficial
El syllabus de CT-QDO está disponible en inglés. Todo su contenido es evaluable salvo la introducción, los objetivos prácticos y los apéndices.
El examen CT-QDO
Estructura verificada
| Dato | Valor |
|---|---|
| Preguntas | 40, de opción múltiple |
| Para aprobar | 65% de los puntos |
| Duración | 60 minutos; 75 si presentas en un idioma que no es tu lengua materna |
| Requisito | Certificación ISTQB Foundation Level |
| Niveles cognitivos | K1, K2 y K3 |
Fuente: istqb.org y tablas oficiales de estructura de exámenes. Un detalle: la tabla oficial de ISTQB (v1.18) indica 44 puntos totales con 29 para aprobar, mientras que la página de la certificación menciona 45 y 30; en ambos casos la nota de corte es de aproximadamente 65%. Confirma el dato al reservar tu examen.
Modalidades
- En línea con supervisión remota (iSQI FLEX): 24/7, con cámara, micrófono, segunda cámara con tu celular e identificación oficial.
- Pearson VUE: centro de examen u OnVUE.
- Presencial en tu empresa: grupos de 6 o más, con un aplicador que lleva Cool Testers.
Ya no hay examen en papel. Como CT-QDO es muy reciente, verifica idiomas y disponibilidad con el proveedor antes de reservar.
Dónde comprarlo
Puedes comprarlo directo con un proveedor oficial de exámenes como iSQI, nuestro partner, o pedirlo a través de Cool Testers con nuestro examen de certificación si lo paga tu empresa o necesitas factura (tienes 1 año para presentarlo). Si tienes dudas sobre cuál opción te conviene, escríbenos por WhatsApp.
Cómo prepararte
- Ten tu CTFL al día. Es requisito, y CT-QDO usa mucho su vocabulario (enfoque de equipo completo, pirámide de pruebas, shift left).
- Lee el syllabus completo dos veces. Los keywords se evalúan a nivel K2: no basta con memorizar, tienes que poder distinguir conceptos parecidos (entrega continua vs. despliegue continuo; canary vs. blue-green; SLA vs. SLO vs. SLI).
- Arma un pipeline de prueba. Con GitHub Actions, GitLab CI o Azure DevOps, crea un pipeline sencillo con build, pruebas unitarias, pruebas de API y un despliegue a un entorno de prueba. Los objetivos K3 del capítulo 2 se entienden muchísimo mejor después de hacerlo.
- Practica pruebas de API y de contrato. Son K3 en el capítulo 3.
- Haz tus propias fichas para las listas del syllabus: métricas DORA, elementos de CALMS, tres vías, topologías y antipatrones, estrategias de liberación.
- Resuelve el examen de muestra oficial disponible en istqb.org.
- Refuerza automatización. Si vienes de pruebas manuales, cursos como Playwright o Implementa un área de automatización te darán la base práctica que este syllabus da por supuesta. Para empezar, lee nuestra guía de automatización de pruebas desde cero.
Beneficios y salidas profesionales
- Relevancia inmediata: la mayoría de las empresas de software ya trabajan con pipelines de CI/CD; un tester que habla el idioma de DevOps se integra mejor y aporta más.
- Perfil híbrido: abre la puerta a roles como quality engineer, SDET, QA en equipos de plataforma o colaboración con SRE.
- Mirada de negocio: aprendes a conectar la calidad con métricas que la dirección entiende, como las métricas DORA.
- Para desarrolladores y DevOps: es de las pocas certificaciones ISTQB pensadas explícitamente también para ellos, útil para formar una cultura de calidad en todo el equipo.
- Para empresas: un lenguaje común de calidad entre Dev, QA y Ops. Si quieres formar a tu equipo en pruebas y automatización, solicita una cotización.
Relación con otras certificaciones y siguiente paso
- Antes: CTFL 4.0 (obligatoria). Recomendable: Agile Tester (CTFL-AT).
- Automatización: CT-TAS para la estrategia y CTAL-TAE para la ingeniería de automatización.
- Ágil avanzado: CTAL-AT y, mientras siga disponible, CTAL-ATT. A escala: CT-ATLaS.
- Especialidades que encajan en DevOps: Performance Testing y Security Test Engineer.
- IA en el pipeline: CT-GenAI.
Preguntas frecuentes
¿Qué es la certificación ISTQB CT-QDO?
Es la certificación Specialist de ISTQB sobre aseguramiento de la calidad y pruebas en equipos DevOps. Su syllabus v1.0 se liberó en abril de 2026.
¿Cuál es el requisito para presentar CT-QDO?
Tener la certificación ISTQB Foundation Level (CTFL). ISTQB recomienda además algo de experiencia en desarrollo o pruebas y tomar un curso acreditado.
¿Cómo es el examen CT-QDO?
40 preguntas de opción múltiple en 60 minutos (75 si no es tu lengua materna). Se aprueba con alrededor del 65% de los puntos.
¿CT-QDO es solo para testers?
No. También está dirigida a desarrolladores, ingenieros DevOps y SRE, scrum masters y product owners, porque en DevOps la calidad es responsabilidad de todo el equipo.
¿Necesito saber programar?
No es requisito formal, pero conviene entender cómo funciona un pipeline de CI/CD y tener nociones de automatización y pruebas de API.
¿Cuánto tiempo de estudio requiere?
Un curso acreditado debe durar al menos 20.2 horas repartidas en un mínimo de tres días. Si estudias por tu cuenta, considera un tiempo similar más práctica.
¿Qué diferencia hay entre CT-QDO y CT-TAS?
CT-TAS se centra en la estrategia de automatización de pruebas en la organización. CT-QDO abarca toda la calidad en DevOps: cultura, flujo de valor, CI/CD, pruebas automáticas y manuales y prácticas operativas.