- CTAL-TAE (Certified Tester Advanced Level Test Automation Engineering) es la certificación de ISTQB para quien diseña, construye y mantiene soluciones de automatización de pruebas. La versión vigente es la 2.0 (2024).
- Requisito: ISTQB Foundation Level (CTFL). Se recomienda experiencia en desarrollo o pruebas y saber programar.
- El syllabus tiene 8 capítulos: objetivos, preparación, arquitectura, implementación, CI/CD, reportes y métricas, verificación y mejora continua.
- El examen tiene 40 preguntas que suman 66 puntos, se aprueba con 43 (65%) y dura 90 minutos (113 si no es tu lengua materna).
- Es neutral frente a herramientas: lo que aprendes aplica a Playwright, Selenium, Cypress, Appium, Postman o cualquier otra.
- Ofrecemos el curso ISTQB Test Automation Engineer bajo demanda para empresas, en línea o presencial.
Cualquiera puede grabar un script que haga clic en una página. Lo difícil es lo que viene después: que cien pruebas sigan funcionando cuando cambia la interfaz, que corran solas en el pipeline, que sus resultados sirvan para decidir y que el costo de mantenerlas no se coma el beneficio. Ese es el terreno de la certificación ISTQB Test Automation Engineering (CTAL-TAE).
En esta guía te explico qué es la versión 2.0, para quién es, qué dice el syllabus capítulo por capítulo con ejemplos prácticos, cómo es el examen y cómo prepararte.
Qué es CTAL-TAE y dónde está en el portafolio ISTQB
CTAL-TAE es un módulo de nivel avanzado del portafolio ISTQB, junto a Test Analyst, Technical Test Analyst y Test Management. La versión 2.0 se publicó en mayo de 2024 y reemplazó a la de 2016 (antes llamada «Test Automation Engineer»), que ISTQB puso en fase de retiro.
La versión 2.0 modernizó el contenido: integración con pipelines de CI/CD, pruebas de API y contract testing, patrones de diseño como Page Object y Flow Model, principios SOLID, análisis estático del código de automatización y el uso de IA para tareas como el self-healing de localizadores.
Su complemento natural es Test Automation Strategy (CT-TAS): TAE es el «cómo construirlo» técnico; TAS es el «qué y por qué» estratégico a nivel organización. Para ver el mapa completo y costos en tu moneda, revisa nuestra guía de la certificación ISTQB.
Para quién es y requisitos previos
El syllabus dice que CTAL-TAE está dirigida 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. También sirve a quien necesita entender la automatización sin construirla: project managers, gerentes de calidad y de desarrollo, analistas de negocio y directores de TI.
- Requisito formal: tener la certificación ISTQB Foundation Level (CTFL) antes de presentar el examen. Si te falta, empieza por nuestro curso ISTQB Fundamentos 4.0.
- Recomendado: al menos seis meses de experiencia como ingeniero de pruebas o desarrollador, y un curso acreditado.
- Programación: el syllabus aclara que no enseña ingeniería de software, pero espera que el ingeniero de automatización tenga habilidades y experiencia en ella. En la práctica, conviene que ya hayas automatizado algo con algún lenguaje y herramienta. Si estás empezando, lee nuestra guía de automatización de pruebas desde cero.
Qué serás capaz de hacer: objetivos de negocio
El syllabus define 12 resultados de negocio:
| Código | Un TAE certificado puede… |
|---|---|
| TAE-B01 | Describir el propósito de la automatización de pruebas |
| TAE-B02 | Entender la automatización a lo largo del ciclo de vida de desarrollo |
| TAE-B03 | Entender la configuración de una infraestructura que habilite la automatización |
| TAE-B04 | Conocer el proceso de evaluación para elegir herramientas y estrategias |
| TAE-B05 | Entender conceptos de diseño para soluciones modulares y escalables |
| TAE-B06 | Elegir un enfoque, incluido un piloto, para planear el despliegue de la automatización |
| TAE-B07 | Diseñar y desarrollar soluciones de automatización nuevas o modificadas |
| TAE-B08 | Considerar alcance, enfoque y mantenimiento del testware |
| TAE-B09 | Entender cómo se integran las pruebas automatizadas en pipelines de CI/CD |
| TAE-B10 | Recolectar, analizar y reportar datos de automatización para informar a los interesados |
| TAE-B11 | Verificar la infraestructura de automatización |
| TAE-B12 | Definir oportunidades de mejora continua de la automatización |
Los objetivos se evalúan en niveles K2 (entender), K3 (aplicar) y K4 (analizar).
Contenido del syllabus capítulo por capítulo
| Capítulo | Tiempo | Temas clave |
|---|---|---|
| 1. Introducción y objetivos de la automatización | 45 min | Ventajas y desventajas, automatización en cascada, modelo V y ágil, selección de herramientas |
| 2. Preparación para la automatización | 180 min | Infraestructura, entornos (local, build, integración, preproducción, producción), análisis del SUT, evaluación de herramientas |
| 3. Arquitectura de automatización | 210 min | gTAA, diseño de la solución, capas del framework, enfoques de scripting, OOP, SOLID, patrones de diseño |
| 4. Implementación de la automatización | 150 min | Piloto y despliegue, riesgos de despliegue, mantenibilidad |
| 5. Estrategias de implementación y despliegue | 90 min | Pruebas en pipelines, gestión de configuración del testware, dependencias de API, contract testing |
| 6. Reportes y métricas | 150 min | Recolección de datos, logs, análisis de resultados, informes y dashboards |
| 7. Verificación de la solución | 135 min | Verificar entorno y herramientas, comportamiento correcto de las pruebas, resultados inesperados, análisis estático |
| 8. Mejora continua | 210 min | Mejora de casos con datos, recomendaciones técnicas, refactorización del testware, oportunidades de herramientas |
El syllabus fija un mínimo de 21 horas de formación acreditada en total (los tiempos por capítulo de la tabla suman 19.5 horas).
Capítulo 1. Introducción y objetivos de la automatización
Parte de lo básico pero con mirada de ingeniero. Ventajas: más pruebas en menos tiempo, ejecución desatendida, retroalimentación rápida, consistencia, pruebas que a mano serían imposibles (miles de combinaciones de datos, cargas). Desventajas: costos iniciales, mantenimiento, necesidad de habilidades técnicas, falsa sensación de seguridad y el riesgo de automatizar pruebas malas.
Explica cómo cambia la automatización en cascada, modelo V y desarrollo ágil, donde se automatiza dentro del sprint y en todos los niveles. Y cómo seleccionar herramientas adecuadas para un sistema concreto: tecnología del SUT (web, móvil, API, escritorio), lenguajes del equipo, integración con el pipeline, licencias y comunidad.
Capítulo 2. Preparación para la automatización
Antes de escribir una línea, hay que preparar el terreno. El capítulo describe qué necesita la infraestructura (acceso al SUT, datos de prueba, entornos, controlabilidad y observabilidad, interfaces de prueba) y cómo se aprovecha la automatización en cada entorno: local del desarrollador, de build, de integración, de preproducción y de producción (por ejemplo, pruebas de humo después de desplegar).
Los dos objetivos K4 son de los más importantes del examen: analizar un SUT para determinar la solución de automatización adecuada e ilustrar los hallazgos técnicos de una evaluación de herramientas. Ejemplo: una aplicación web con React y una API REST, un equipo que programa en TypeScript y un pipeline en GitHub Actions. El análisis llevaría a automatizar la mayor parte en la capa de API, un conjunto reducido de flujos de interfaz con una herramienta compatible con TypeScript y a documentar la evaluación con criterios comparables. Si estás en esa decisión, revisa nuestra comparativa Playwright vs. Selenium vs. Cypress.
Capítulo 3. Arquitectura de automatización
El capítulo más técnico y uno de los más largos (210 minutos). Presenta la arquitectura genérica de automatización (gTAA) con sus interfaces hacia el SUT, la gestión de proyecto, la gestión de pruebas y la gestión de la configuración, y sus capacidades: generación de pruebas (opcional, por ejemplo desde modelos), definición, ejecución (con logging y reportes) y adaptación (adaptadores para conectarse al SUT por API, protocolos o interfaz).
Después explica las capas del framework de automatización (TAF), que debes saber aplicar (K3):
- Scripts de prueba: los casos y suites; llaman a la capa de lógica de negocio, nunca directo a las bibliotecas base.
- Lógica de negocio: bibliotecas dependientes del SUT (pasos, flujos de usuario, llamadas a API).
- Bibliotecas base (core): independientes del SUT, reutilizables en cualquier proyecto con la misma tecnología.
Compara los enfoques para automatizar casos con sus pros y contras: capture/playback, scripting lineal, scripting estructurado, TDD, data-driven, keyword-driven y BDD. Y cierra con los principios de diseño: los cuatro de la programación orientada a objetos (encapsulamiento, abstracción, herencia y polimorfismo), los principios SOLID y los patrones más importantes para un TAE: facade, singleton (un solo driver que habla con el SUT), Page Object Model y Flow Model, que agrega una fachada de acciones de usuario sobre los page objects.
Ejemplo: si el botón «Pagar» cambia de identificador y tienes 80 pruebas que lo usan, con Page Object corriges el localizador en un solo lugar. Con Flow Model, además, la acción «completar compra» vive en un solo método reutilizado por todas las pruebas.
Capítulo 4. Implementación de la automatización
Cubre cómo llevar la automatización del papel al proyecto. Primero, el piloto (K3): definir alcance, lenguaje, herramientas, niveles de prueba, casos seleccionados y enfoque de desarrollo; crear prototipos para comparar opciones; integrar en CI/CD desde el piloto; y evaluar aspectos no técnicos como experiencia del equipo, estructura y licencias. Al terminar, el TAE y el test manager evalúan el resultado y deciden.
Luego, analizar los riesgos del despliegue y planear su mitigación (K4): empaquetado, logging, estructura de las pruebas y actualizaciones. Por último, los factores que favorecen o perjudican la mantenibilidad: convenciones de nombres, modularidad, documentación, independencia entre pruebas, manejo de datos y de esperas.
Capítulo 5. Estrategias de implementación y despliegue
Aquí la automatización se conecta con DevOps. El objetivo K3 es aplicar la automatización en distintos niveles dentro de los pipelines: pruebas de configuración del propio framework y pruebas de componente en el build, integración de componentes en integración continua, pruebas de sistema e integración de sistemas como quality gates en entrega o despliegue continuo, además de regresiones nocturnas y pruebas no funcionales periódicas. El syllabus compara dos formas de correr pruebas de sistema: dentro de la fase de despliegue (pueden frenar y revertir) o en un pipeline separado (más flexible, pero no actúan como quality gate).
También explica la gestión de configuración del testware (configuración de entornos, datos, suites y casos bajo control de versiones) y las dependencias en pruebas de API: conexiones entre APIs, documentación y contract testing, en enfoque dirigido por el consumidor o por el proveedor, para verificar que dos servicios se comunican según un contrato acordado. Si trabajas con APIs, nuestra formación de automatización de APIs con Postman es un buen complemento práctico.
Capítulo 6. Reportes y métricas
Una automatización que nadie entiende no sirve. El capítulo cubre cómo recolectar datos (K3) de la solución y del SUT: logs de pruebas, logs de la solución de automatización, logs del SUT, integración con otras herramientas y visualización. El objetivo K4 es analizar esos datos para entender los resultados: distinguir un defecto real del SUT de un problema del entorno o de la prueba. Cierra con cómo construir y publicar un informe de avance, a quiénes reportar, cómo crear dashboards y el uso de IA y machine learning para analizar logs.
Capítulo 7. Verificación de la solución
¿Quién prueba las pruebas? Este capítulo. Incluye planear la verificación del entorno (K3): instalación y configuración de herramientas, repetibilidad de setup y teardown, conectividad con sistemas internos y externos, y pruebas de los componentes del framework. Luego, cómo verificar que una prueba o suite se comporta correctamente (composición de la suite, repetibilidad, intrusividad de las herramientas), cómo investigar resultados inesperados (pruebas intermitentes, falsos positivos y falsos negativos, aserciones faltantes) y cómo el análisis estático mejora el código de automatización. Ejemplo clásico del syllabus: una contraseña en texto plano dentro de un script de prueba, que una herramienta de análisis estático detecta antes de que llegue al repositorio.
Capítulo 8. Mejora continua
El último capítulo pesa lo mismo que arquitectura (210 minutos) y concentra 13 de los 66 puntos del examen. Cubre:
- Mejorar casos con datos (K3): histogramas de resultados para encontrar pruebas frágiles, IA para self-healing de localizadores y validación de esquemas en APIs y bases de datos, que evita escribir decenas de aserciones individuales.
- Analizar una solución desplegada y recomendar mejoras (K4): scripting, ejecución, verificación, arquitectura, framework, setup y teardown, documentación, funcionalidades y actualizaciones.
- Reestructurar el testware cuando cambia el SUT (K3): consolidar funciones, refactorizar la arquitectura, estandarizar nombres y retirar scripts obsoletos.
- Otras oportunidades de herramientas: control del entorno, envejecimiento de datos, generación de capturas y videos.
Descarga el syllabus oficial
Todas las secciones son evaluables excepto la introducción y los apéndices.
El examen CTAL-TAE
Estructura verificada
| Dato | Valor |
|---|---|
| Preguntas | 40, de opción múltiple |
| Puntos totales | 66 (K2 vale 1 punto, K3 vale 2 y K4 vale 3) |
| Para aprobar | 43 puntos (65%) |
| Duración | 90 minutos; 113 si presentas en un idioma que no es tu lengua materna (+25%) |
| Niveles cognitivos | 20 preguntas K2, 14 K3 y 6 K4 |
| Requisito | ISTQB Foundation Level (CTFL) |
Distribución por capítulo según las tablas oficiales de ISTQB:
| Capítulo | Preguntas | Puntos |
|---|---|---|
| 1. Introducción y objetivos | 3 | 3 |
| 2. Preparación | 5 | 9 |
| 3. Arquitectura | 6 | 10 |
| 4. Implementación | 4 | 7 |
| 5. CI/CD y despliegue | 6 | 8 |
| 6. Reportes y métricas | 4 | 8 |
| 7. Verificación | 6 | 8 |
| 8. Mejora continua | 6 | 13 |
Modalidades
- En línea desde casa con supervisión remota (iSQI FLEX): disponible 24/7; para exámenes Advanced reserva con al menos 48 horas de anticipación. Necesitas cámara, micrófono, una segunda cámara con tu celular e identificación oficial.
- Pearson VUE: en un centro de examen o en línea con OnVUE.
- Presencial en tu empresa: para grupos de 6 o más personas, Cool Testers lleva un aplicador.
Ya no existe el examen en papel.
Dónde comprarlo
El examen no está incluido en el curso. Tienes dos opciones:
- Directo en iSQI, nuestro partner y proveedor oficial de exámenes, con un cupón de 20% sobre el precio de su página en la primera oportunidad, que te enviamos al inscribirte. Es lo más conveniente si tú lo pagas.
- Con Cool Testers: el examen de certificación con 1 o 2 oportunidades. Conviene si lo paga tu empresa o necesitas factura. Tienes 1 año para presentarlo.
Cómo prepararte
Plan de 7 semanas
| Semana | Qué estudiar | Meta |
|---|---|---|
| 1 | Capítulos 1 y 2 | Analizar un SUT real y escribir una evaluación de herramientas con criterios |
| 2 | Capítulo 3 | Dibujar la gTAA de tu proyecto y separar tu código en capas |
| 3 | Capítulo 3, patrones | Implementar Page Object y Flow Model en un mini proyecto |
| 4 | Capítulos 4 y 5 | Plan de piloto, riesgos de despliegue y un pipeline con pruebas por nivel |
| 5 | Capítulos 6 y 7 | Dashboard de resultados; investigar una prueba intermitente |
| 6 | Capítulo 8 | Proponer mejoras técnicas a una solución existente |
| 7 | Examen de muestra | Practicar K3 y K4; revisar palabras clave |
Errores comunes
- Estudiar desde la herramienta que usas. El examen es neutral: pregunta conceptos, no la sintaxis de Playwright o Selenium.
- Subestimar el capítulo 8. Aporta la mayor cantidad de puntos.
- Confundir capas. En el syllabus, los scripts no llaman directo a las bibliotecas base.
- Estudiar con material de la versión 2016. La estructura y los objetivos cambiaron.
Nuestro curso ISTQB Test Automation Engineer
Nuestro curso ISTQB Test Automation Engineer se imparte bajo demanda para empresas: en línea o presencial, en tus fechas, con un instructor certificado y ejemplos adaptados a la tecnología de tu equipo. Solicita una cotización. Si eres persona individual y quieres saber cuándo abrimos un grupo, avísanos por WhatsApp.
Para la parte práctica con herramientas, tenemos grupos abiertos de Playwright, Selenium y Postman, y para empresas, Implementa un Área de Automatización.
Beneficios y salidas profesionales
- De automatizador a ingeniero: demuestra que sabes diseñar arquitecturas mantenibles, no solo escribir scripts.
- Neutral frente a herramientas: lo que aprendes sobrevive al cambio de framework.
- DevOps: integras pruebas como quality gates en pipelines reales.
- Argumentos para decidir: sabes evaluar herramientas, planear pilotos y medir resultados, lo que piden los líderes antes de invertir.
- Para empresas: un equipo que construye automatización con una arquitectura común reduce mantenimiento y dependencia de una sola persona.
Roles típicos: ingeniero de automatización de pruebas, SDET, QA automation lead, arquitecto de automatización y QA en equipos DevOps. Si buscas trabajo remoto, revisa nuestra guía de vacantes de QA tester remoto.
Relación con otras certificaciones y siguiente paso
- Antes: CTFL 4.0, obligatoria.
- Estrategia: Test Automation Strategy (CT-TAS), el siguiente paso natural según el propio syllabus.
- Técnico: Technical Test Analyst (CTAL-TTA).
- DevOps: Quality in DevOps (CT-QDO).
- Especialidades: Performance Testing, Mobile Application Testing y Model-Based Testing.
- IA: CT-GenAI y nuestra guía de testing con IA y Playwright MCP.
Preguntas frecuentes
¿Necesito saber programar para CTAL-TAE?
El syllabus no enseña programación, pero asume habilidades de ingeniería de software. En la práctica, conviene haber automatizado pruebas con algún lenguaje antes de presentar.
¿Cuál es el requisito para presentar el examen?
Tener la certificación ISTQB Foundation Level (CTFL). Se recomienda al menos seis meses de experiencia en pruebas o desarrollo.
¿Cuántas preguntas tiene el examen CTAL-TAE v2.0?
40 preguntas de opción múltiple que suman 66 puntos. Apruebas con 43 (65%). Tienes 90 minutos, o 113 si no presentas en tu lengua materna.
¿El examen pregunta sobre Selenium, Playwright u otra herramienta?
No. El syllabus es neutral frente a herramientas: evalúa arquitectura, diseño, integración, métricas y mejora, que aplican a cualquier herramienta.
¿Qué diferencia hay entre CTAL-TAE y CT-TAS?
CTAL-TAE es técnico: cómo diseñar, construir y mantener la solución. CT-TAS es estratégico: cómo definir y gobernar la automatización en la organización.
¿Tienen curso abierto de TAE?
Lo impartimos bajo demanda para empresas, en línea o presencial. Si eres persona individual, escríbenos por WhatsApp para avisarte cuando abramos un grupo.
¿El examen está incluido en el curso?
No. Puedes comprarlo directo en iSQI con el cupón de 20% que te enviamos al inscribirte, o con Cool Testers si lo paga tu empresa o necesitas factura.