- CT-TAS (Certified Tester Test Automation Strategy) es la certificación de ISTQB para planear la automatización de pruebas con visión estratégica: qué automatizar, con qué recursos, cuánto cuesta, cómo medir su valor y cómo escalarla en la organización.
- Es un módulo Specialist, versión 1.0 (mayo de 2024). Requisito: certificación ISTQB Foundation Level (CTFL).
- Tiene 6 capítulos y exige un mínimo de 12.75 horas de formación acreditada.
- El examen: 40 preguntas, 60 minutos (75 si no es tu lengua materna) y se aprueba con 32 de 49 puntos (65%).
- Es el complemento estratégico de CTAL-TAE: TAE es el cómo técnico (arquitectura, frameworks, scripts); TAS es el qué, cuándo y por qué (inversión, ROI, riesgos, roles, despliegue).
- Ideal para test leads, test managers, arquitectos de pruebas e ingenieros de automatización con experiencia que deben justificar o escalar la automatización.
Casi todas las empresas "automatizan". Muchas menos pueden responder con datos preguntas como: ¿cuándo recuperamos la inversión?, ¿por qué tenemos 2,000 pruebas de interfaz y casi ninguna de API?, ¿compramos una herramienta o usamos código abierto?, ¿qué métricas le mostramos a la dirección? Cuando esas respuestas no existen, la automatización se vuelve un proyecto caro que nadie sabe si vale la pena.
La certificación ISTQB CT-TAS está hecha para eso. En esta guía te explico qué es, en qué se diferencia de CTAL-TAE, qué dice el syllabus capítulo por capítulo, cómo es el examen y cómo prepararte.
Qué es CT-TAS y dónde está en el portafolio ISTQB
CT-TAS es un módulo Specialist de ISTQB publicado en su versión 1.0 el 3 de mayo de 2024. El syllabus lo explica así: presenta los múltiples factores que entran en juego al planear la automatización en una organización, y deja fuera de alcance los aspectos técnicos de implementación, que cubre el syllabus CTAL-TAE. Su propósito es dar una visión estratégica para implementar la automatización en todos los proyectos de forma sistemática y consistente, demostrando valor para la organización.
CT-TAS frente a CTAL-TAE
| CT-TAS (Specialist) | CTAL-TAE (Core Advanced) | |
|---|---|---|
| Pregunta central | ¿Qué, cuándo y por qué automatizar, y cómo escalarlo? | ¿Cómo diseño, construyo y mantengo la solución de automatización? |
| Temas estrella | Costo de propiedad, licencias, roles, distribución de pruebas, ROI, métricas, despliegue, transición a pruebas continuas | Arquitectura de automatización, capas, frameworks, implementación, reportes, mantenimiento |
| Perfil | Test lead, test manager, arquitecto, TAE senior | Ingeniero de automatización, SDET, desarrollador |
| Examen | 40 preguntas, 60 min | 40 preguntas, 90 min |
Un detalle que confunde: dentro del syllabus, la sigla TAS también se usa como Test Automation Solution (la solución de automatización que construye el equipo) y TAE como el Test Automation Engineer, la persona. No lo mezcles con el nombre de la certificación.
¿Cuál primero? Si eres técnico y construyes frameworks, empieza por CTAL-TAE. Si lideras, decides presupuesto o defiendes la automatización frente a la dirección, CT-TAS te dará retorno más rápido. Lo ideal para un líder de automatización es tener ambas. Puedes ver todo el mapa de certificaciones en nuestra guía de la certificación ISTQB.
Para quién es y requisitos previos
El syllabus apunta a cualquier persona involucrada en pruebas y automatización: testers, analistas de pruebas, ingenieros de automatización, consultores, arquitectos de pruebas, test managers y desarrolladores, y también a quien necesita una visión básica: project managers, gerentes de calidad y desarrollo, analistas de negocio, directores de TI y consultores.
- Requisito formal: certificación ISTQB Foundation Level (CTFL v4.0 o anterior). Si te falta, revisa nuestro curso ISTQB Fundamentos 4.0.
- Muy recomendado: experiencia como ingeniero de pruebas senior, test lead o desarrollador, y algo de experiencia llevando tecnología a la empresa. ISTQB también pide "suficiente experiencia práctica" y deja los criterios específicos al board o proveedor de examen.
- No necesitas programar a nivel experto, pero sí entender cómo funciona una suite automatizada en un pipeline.
Qué serás capaz de hacer: objetivos de negocio
El syllabus define 15 objetivos de negocio (TAS-BO1 a TAS-BO15). Resumidos, una persona certificada puede:
- Entender los factores del software y los sistemas que influyen en el éxito de la automatización.
- Identificar costos y riesgos de implementar una solución de automatización.
- Entender los roles y responsabilidades de quienes contribuyen a la automatización.
- Planear la integración de la automatización en los distintos niveles de prueba.
- Identificar consideraciones estratégicas en distintos modelos de ciclo de vida.
- Entender la aplicabilidad y viabilidad de la automatización.
- Planear soluciones que respondan a las necesidades de la organización y entender las estrategias de despliegue.
- Entender las dependencias de la automatización en el entorno de pruebas.
- Entender los costos de construir y mantener la automatización.
- Saber qué métricas ayudan a tomar decisiones y qué reportes necesita cada stakeholder.
- Identificar cómo la automatización aporta valor al proyecto y a la organización.
- Definir la transición de pruebas manuales a automatizadas.
- Definir una estrategia que haga que los proyectos compartan activos y métodos para una implementación consistente en toda la organización.
Los objetivos de aprendizaje están en K2 (entender) y K3 (aplicar).
Contenido del syllabus capítulo por capítulo
| Capítulo | Tiempo mínimo | Temas clave |
|---|---|---|
| 1. Introducción y objetivos de la estrategia de automatización | 45 min | Objetivos de la automatización, factores técnicos de éxito, criterios de inversión para elegir proyectos |
| 2. Recursos de automatización | 60 min | Costo de propiedad (in-house, proveedor, outsourcing), modelos de licencia, factores de la estrategia, roles y habilidades |
| 3. Preparación para la automatización | 225 min | Distribuciones de pruebas (pirámide y otras), enfoque según arquitectura, shift left y shift right, ciclos de vida secuencial, ágil y DevOps, qué conviene y qué no automatizar |
| 4. Estrategias de despliegue y liberación en la organización | 135 min | Time to market, verificación de defectos, escenarios operativos, estrategia de despliegue, riesgos y mitigación, dependencias del entorno, datos e interfaces |
| 5. Análisis de impacto de la automatización | 150 min | ROI, métricas, consideraciones organizacionales, características del proyecto, decisiones a partir de reportes |
| 6. Estrategias de implementación y mejora | 150 min | Transición de manual a automatizado y de automatizado a pruebas continuas, evaluación de activos y prácticas para mejorar |
Capítulo 1. Introducción y objetivos de la estrategia de automatización
Un capítulo corto que fija el punto de partida: definir metas y objetivos claros para la automatización (no "automatizar todo", sino, por ejemplo, "reducir la regresión de 5 días a 4 horas para poder liberar cada dos semanas"), identificar los factores técnicos de éxito de un proyecto de automatización y resumir los criterios de inversión para elegir qué proyectos son buenos candidatos. Un sistema estable, con larga vida por delante y liberaciones frecuentes es mejor candidato que uno que se va a retirar en seis meses.
Capítulo 2. Recursos de automatización
Aquí se habla de dinero y de personas. Primero compara el costo de propiedad de tres caminos: solución propia (in-house) sobre herramientas abiertas o comerciales, solución de un proveedor, o subcontratar la automatización. Cada uno reparte de forma distinta el control, el riesgo y los costos.
Luego, los modelos de licencia: código abierto (sin costo de licencia, con comunidad, pero con costo de soporte interno), licencia por usuario o máquina, licencia flotante (se calcula por uso concurrente) y licencia de ejecución (runtime), típica de las granjas de dispositivos y navegadores en la nube, donde pagas por uso.
Después, los factores de la estrategia: tiempo disponible, nivel de experiencia y número de ingenieros, hardware, licencias, adaptabilidad, mantenimiento, plataformas (web, escritorio, móvil), soporte para CI/CD e integración con la gestión de pruebas y los reportes. Y cierra con los roles y habilidades: ingenieros de automatización con fuertes conocimientos de programación y arquitectura, al menos un experto en el dominio que guíe el concepto y la hoja de ruta, y liderazgo para formar al equipo. También recuerda algo sano: así como las pruebas exhaustivas son imposibles, el 100% de automatización tampoco es alcanzable.
Capítulo 3. Preparación para la automatización
El capítulo más largo. Empieza con las distribuciones de pruebas automatizadas a partir de la pirámide de Mike Cohn (componente, servicio e interfaz) y sus formas problemáticas:
- Pirámide: muchas pruebas rápidas abajo y pocas arriba. El estado objetivo habitual.
- Cono de helado: la pirámide invertida; casi todo se detecta en la interfaz, lo más caro de automatizar y mantener.
- Reloj de arena: mucho arriba y abajo, casi nada en servicios; aparecen defectos de integración.
- Paraguas: todo depende de pruebas de interfaz costosas; retroalimentación lenta y mantenimiento caro.
Un ejercicio muy útil que propone el syllabus: dibujar tu distribución actual y la objetivo. Si tu negocio vive en APIs, muchas pruebas de interfaz pueden bajar a la capa de servicio, con pruebas de integración de componentes, de contrato y de API.
Luego explica cómo elegir el enfoque según la arquitectura del sistema bajo prueba, cómo optimizar la distribución para lograr shift left y shift right (K3), y cómo encaja la automatización en ciclos de vida secuenciales, ágiles y DevOps con pruebas continuas (K3).
Cierra con la viabilidad. Criterios para elegir qué automatizar: ¿es técnicamente posible?, ¿el equipo está preparado?, ¿hay ROI?, ¿se ejecutará seguido?, ¿es repetible y fácil de mantener?, ¿cubre flujos de negocio frecuentes? Retos que solo la automatización resuelve: ejecución manual demasiado lenta, sincronización, resultados en un pipeline, análisis de grandes logs, precisión de tiempos, combinaciones de sistemas operativos, navegadores y dispositivos, grandes volúmenes de datos y pruebas no funcionales como estrés o confiabilidad. Y condiciones difíciles de automatizar: la consistencia visual entre plataformas, procesos con mucha intervención humana (como la revisión manual de una solicitud de crédito), restricciones del sistema operativo o esperas muy largas, como un cierre de sesión por inactividad de dos horas.
Capítulo 4. Estrategias de despliegue y liberación en la organización
Este capítulo baja la estrategia a tierra. Primero, la planeación: cómo la automatización acorta el time to market, cómo ayuda a verificar defectos reportados y cómo construir escenarios operativamente relevantes, es decir, pruebas que reflejen cómo los usuarios usan realmente el sistema.
Después, la estrategia de despliegue de la solución de automatización y sus riesgos. El syllabus menciona problemas técnicos (demasiadas abstracciones que hacen difícil entender qué hace el código, tablas de datos de prueba enormes que no se pueden migrar entre entornos, dependencias de librerías que no existen en todos los entornos), riesgos de proyecto (falta de personas para mantenerla, mantenimiento no planeado por cambios en el sistema, retrasos, objetos de interfaz no estándar, casos obsoletos que siguen consumiendo tiempo) y puntos de falla como migrar a otro entorno o desplegar a producción, y sobre todo olvidar que la automatización también es software y también hay que probarla. Para mitigarlos: gestión de configuración, un procedimiento de despliegue documentado y versionado, y distinguir el primer despliegue de los despliegues de mantenimiento.
Por último, las dependencias en el entorno de pruebas: componentes de la automatización, infraestructura y los requisitos de datos e interfaces para integrarse con el sistema bajo prueba.
Capítulo 5. Análisis de impacto de la automatización
El capítulo que más agradecen los líderes. Arranca con el retorno de inversión (ROI = ahorros / inversión), un objetivo K3. Para los ahorros considera el tiempo manual y automatizado por caso, el número de casos y de ejecuciones; para la inversión, el tiempo de preparación, desarrollo y mantenimiento de scripts, la ejecución y el porcentaje de scripts que fallan.
Un ejemplo sencillo con el modelo del syllabus (en horas, no en dinero): 200 casos de regresión de 10 minutos manuales que automatizados tardan 1 minuto. Cada ejecución ahorra 200 × 9 min = 30 horas. La inversión inicial es de 80 horas de preparación más 100 horas de desarrollo (30 minutos por script), y cada ejecución cuesta unas 5 horas de mantenimiento y análisis. El ahorro neto por ejecución es de 25 horas, así que la inversión de 180 horas se recupera a partir de la octava ejecución. Si el proyecto solo va a tener cinco ciclos de regresión, el syllabus es claro: no convendría automatizar.
Luego clasifica las métricas de automatización: proporción de pruebas que pasan y fallan, relación entre fallas y defectos reales (cuántas fallas son problemas de la automatización), tiempo de ejecución, número de casos automatizados, cobertura funcional y cobertura de código. Después analiza el valor para la organización (políticas, proyectos activos, expertos, entornos, licencias) y las características del proyecto que determinan la mejor implementación: dominio, plataformas, lenguaje y stack, madurez, apoyo de stakeholders, conocimiento del equipo, presupuesto y características de calidad. Cierra con cómo analizar los reportes para tomar decisiones.
Capítulo 6. Estrategias de implementación y mejora
El último capítulo trata la evolución. Primero, la transición de pruebas manuales a automatizadas: costos de transición, traslape funcional, datos compartidos, interdependencia entre pruebas, precondiciones, cobertura y pruebas ejecutables. Después, la transición a pruebas continuas: adaptar suites, stubs, drivers, interfaces e infraestructura a la solución actualizada e integrarla en el pipeline de CI/CD.
Termina con un objetivo K3: evaluar los activos y prácticas de automatización para encontrar mejoras. Algunas recomendaciones del syllabus: medir horas de desarrollo, de corrección y ahorradas; definir infraestructura y configuración consistentes entre proyectos; crear lineamientos comunes de desarrollo; modularizar scripts para reutilizarlos; eliminar traslapes; y si la automatización hace que el pipeline se encole, ejecutar solo una suite de smoke en cada cambio y dejar la regresión completa aparte o bajo demanda.
Descarga el syllabus oficial
El syllabus está disponible en español y en inglés. Todo su contenido es evaluable salvo la introducción y los apéndices.
El examen CT-TAS
Estructura verificada
| Dato | Valor |
|---|---|
| Preguntas | 40, de opción múltiple |
| Puntos totales | 49 |
| Para aprobar | 32 puntos (65%) |
| Duración | 60 minutos; 75 si no es tu lengua materna |
| Requisito | Certificación ISTQB Foundation Level |
| Niveles cognitivos | K2 y K3 |
Fuente: página de CT-TAS en istqb.org y tablas oficiales de estructura de exámenes de ISTQB. Espera preguntas de escenario ("dada esta situación, ¿qué recomendarías?") y al menos un cálculo de ROI.
Modalidades
- En línea desde casa (iSQI FLEX): supervisión remota 24/7 con cámara, micrófono, segunda cámara con tu celular e identificación oficial.
- Pearson VUE: centro de examen u OnVUE.
- En tu empresa: con 6 personas o más, Cool Testers lleva un aplicador.
El examen en papel ya no existe.
Dónde comprarlo
Puedes comprarlo directo con iSQI, nuestro partner y proveedor oficial de exámenes, o con Cool Testers mediante el examen de certificación (1 o 2 oportunidades), ideal si lo paga tu empresa o necesitas factura. Tienes 1 año para presentarlo. Si quieres que te ayudemos a elegir, escríbenos por WhatsApp.
Cómo prepararte
- Repasa CTFL 4.0, sobre todo la pirámide de pruebas, los niveles de prueba y la parte de herramientas.
- Lee el syllabus en el idioma en que vas a presentar. Las listas (factores, criterios, métricas, riesgos) son material típico de examen.
- Practica el cálculo de ROI con tu propio proyecto: cuenta casos, tiempos y ejecuciones reales y calcula el punto de recuperación.
- Dibuja la distribución de pruebas de tu sistema actual y la objetivo. Identifica si tienes un cono de helado o un paraguas.
- Arma una estrategia de una página para tu equipo: objetivos, alcance, herramientas y licencias, roles, métricas y plan de transición. Es la mejor forma de fijar los seis capítulos.
- Resuelve el examen de muestra oficial de istqb.org.
- Combina teoría y práctica. Nuestro curso Implementa un área de automatización trabaja justo la parte organizacional de llevar la automatización a una empresa, y el curso ISTQB Test Automation Engineering cubre la parte técnica de CTAL-TAE. Ambos están disponibles bajo demanda para empresas; solicita una cotización.
Beneficios y salidas profesionales
- Hablar el idioma de la dirección: ROI, costo de propiedad, riesgos y métricas. Es lo que convierte a un buen automatizador en un líder de automatización.
- Roles a los que apunta: test automation lead, arquitecto de pruebas, QA manager, consultor de automatización.
- Decisiones mejor fundamentadas: herramientas, licencias, outsourcing o equipo propio, y qué no automatizar.
- Escalar en la organización: el syllabus está pensado para pasar de proyectos aislados a una estrategia común con activos compartidos.
- Complemento perfecto de TAE: juntas cubren la estrategia y la ejecución técnica.
Relación con otras certificaciones y siguiente paso
- Antes: CTFL 4.0 (obligatoria).
- Pareja natural: CTAL-TAE, la ingeniería de automatización. Si eres líder, toma TAS y luego TAE; si eres técnico, al revés.
- DevOps: CT-QDO para llevar la automatización a pruebas continuas en un pipeline.
- Gestión: CTAL-TM y, más adelante, Expert Test Management.
- Ágil: CTAL-ATT (mientras siga disponible) o CT-ATLaS.
- IA: CT-GenAI, cada vez más presente en las estrategias de automatización.
Si estás eligiendo herramienta, te puede servir nuestra comparativa Playwright vs Selenium vs Cypress.
Preguntas frecuentes
¿Qué diferencia hay entre CT-TAS y CTAL-TAE?
CT-TAS es estratégica: qué automatizar, costos, ROI, roles, métricas y despliegue en la organización. CTAL-TAE es técnica: cómo diseñar, construir y mantener la solución de automatización.
¿Cuál es el requisito para presentar CT-TAS?
Tener la certificación ISTQB Foundation Level (CTFL) y experiencia práctica suficiente. No es obligatorio tener CTAL-TAE.
¿Cómo es el examen CT-TAS?
40 preguntas de opción múltiple que suman 49 puntos; apruebas con 32 (65%). Duración de 60 minutos, o 75 si no es tu lengua materna.
¿Necesito saber programar?
No es requisito y el examen no tiene código. Aun así, entender cómo funciona una suite automatizada te ayuda mucho a comprender el syllabus.
¿Hay syllabus en español?
Sí. Existe la versión en español del programa de estudios v1.0, además del original en inglés.
¿Cuánto tiempo de estudio necesito?
Un curso acreditado dura al menos 12.75 horas. Si estudias por tu cuenta, suma práctica aplicando los conceptos a tu propio proyecto.