- Qué es: la certificación ISTQB Advanced Level Technical Test Analyst (CTAL-TTA) valida que dominas el lado técnico de las pruebas: caja blanca, análisis estático y dinámico, características no funcionales, revisiones de código y arquitectura, y automatización.
- Versión vigente: v4.0 (publicada en 2021), disponible también en español.
- Requisito obligatorio: tener la certificación ISTQB Foundation Level (CTFL). El syllabus asume conocimientos generales de programación y de arquitecturas de sistemas.
- Examen: 45 preguntas de opción múltiple, 78 puntos posibles, apruebas con 51 (65%), 120 minutos (150 si no es tu lengua materna).
- Contenido: 6 capítulos y un mínimo de 20 horas de formación; los bloques más grandes son características de calidad técnicas (345 min) y técnicas de caja blanca (300 min).
- Para quién: testers técnicos, automatizadores, desarrolladores que prueban, ingenieros de rendimiento o seguridad y QA en sistemas críticos.
Si te sientes más cómodo leyendo código, revisando logs o configurando una herramienta de carga que redactando casos de negocio, el Technical Test Analyst es tu certificación de Nivel Avanzado. En esta guía te explicamos qué cubre cada capítulo de la v4.0, cómo es el examen, cómo prepararte y qué puertas te abre.
El contenido técnico está basado en el syllabus oficial CTAL-TTA v4.0 y en lo publicado en ISTQB.org. Para la visión de todo el portafolio, costos en tu moneda y funcionamiento del examen, revisa nuestra guía principal de la certificación ISTQB.
Qué es el CTAL-TTA y dónde está en el portafolio ISTQB
El Certified Tester Advanced Level Technical Test Analyst (CTAL-TTA) es una de las certificaciones core del Nivel Avanzado de ISTQB. Se complementa con el Test Analyst (CTAL-TA), que cubre el lado funcional y de negocio, y con el Test Management (CTAL-TM), que cubre la gestión.
Una forma sencilla de verlo, tomada del propio syllabus: en el análisis de riesgos, el Technical Test Analyst aporta la probabilidad de cada riesgo técnico de producto, mientras que el Test Analyst aporta el impacto de negocio si el problema ocurre. Uno mira el sistema por dentro; el otro, desde el usuario.
La versión vigente: v4.0
La v4.0 se publicó en 2021 y sigue siendo la versión vigente en ISTQB.org. Respecto a la versión 2019, estos son los cambios principales:
- Se eliminó basis path testing (pruebas de camino básico) y el tema de grafos de llamadas.
- Data flow analysis se reescribió y subió a nivel K3 (aplicar).
- Se reescribieron las secciones de fiabilidad y rendimiento.
- Se agregó la sección de perfiles operacionales.
- Se reescribió la sección de selección de técnicas de caja blanca y la de MC/DC, y control flow analysis ahora incluye la complejidad ciclomática.
Para quién es y requisitos previos
El CTAL-TTA es para ti si trabajas, o quieres trabajar, en alguno de estos roles:
- Tester técnico o QA engineer que prueba APIs, servicios y componentes.
- Ingeniero de automatización que quiere entender las decisiones de arquitectura de su framework.
- Desarrollador que hace pruebas unitarias y de integración y quiere medir la cobertura con criterio.
- Especialista en rendimiento, seguridad o fiabilidad que necesita una base común con el resto del equipo.
- QA en sistemas críticos (automotriz, aeronáutica, salud, industria) donde las normas exigen niveles de cobertura de código.
Requisitos oficiales
- Obligatorio: la certificación ISTQB Certified Tester Foundation Level.
- Experiencia práctica: ISTQB.org pide "experiencia práctica suficiente" y remite al board miembro o al proveedor de examen para el criterio específico.
- Conocimientos esperados: el syllabus asume experiencia básica en conceptos generales de programación y de arquitecturas de sistemas. No necesitas ser desarrollador, pero sí leer pseudocódigo sin problema.
- Curso acreditado: recomendado, no obligatorio.
¿Aún no tienes Foundation? Empieza por el curso ISTQB Fundamentos 4.0. Si vienes del mundo funcional, una buena forma de ganar base técnica es la automatización de pruebas desde cero.
Qué serás capaz de hacer
El documento oficial de visión general del CTAL-TTA define ocho objetivos de negocio. Un Technical Test Analyst certificado puede:
| Código | Objetivo de negocio |
|---|---|
| TTA1 | Reconocer y clasificar los riesgos típicos de rendimiento, seguridad, fiabilidad, portabilidad y mantenibilidad del software. |
| TTA2 | Aportar el detalle técnico para planear, diseñar y ejecutar pruebas que mitiguen esos riesgos. |
| TTA3 | Seleccionar y aplicar técnicas de caja blanca adecuadas para lograr la confianza requerida con base en la cobertura del diseño. |
| TTA4 | Participar en revisiones técnicas con desarrolladores y arquitectos, aplicando el conocimiento de defectos típicos en código y arquitectura. |
| TTA5 | Mejorar la calidad del código y la arquitectura usando distintas técnicas de análisis. |
| TTA6 | Explicar costos y beneficios de introducir ciertos tipos de automatización de pruebas. |
| TTA7 | Seleccionar las herramientas adecuadas para automatizar tareas técnicas de prueba. |
| TTA8 | Comprender los aspectos y conceptos técnicos de aplicar la automatización de pruebas. |
Contenido del syllabus capítulo por capítulo
El syllabus tiene seis capítulos examinables. Para cursos acreditados exige un mínimo de 20 horas (1,200 minutos) de formación:
| Capítulo | Tiempo mínimo | Temas clave |
|---|---|---|
| 1. Las tareas del TTA en las pruebas basadas en riesgo | 30 min | Identificación, evaluación y mitigación de riesgos técnicos |
| 2. Técnicas de prueba de caja blanca | 300 min | Sentencias, decisiones, MC/DC, condición múltiple, pruebas de API, selección de técnica (sistemas críticos y no críticos) |
| 3. Análisis estático y dinámico | 180 min | Flujo de control, complejidad ciclomática, flujo de datos, mantenibilidad, fugas de memoria, punteros salvajes, rendimiento |
| 4. Características de calidad para pruebas técnicas | 345 min | Planeación no funcional, seguridad, fiabilidad, rendimiento, mantenibilidad, portabilidad, compatibilidad, perfiles operacionales |
| 5. Revisiones | 165 min | Preparación de revisiones, checklists de arquitectura y de código |
| 6. Herramientas de prueba y automatización | 180 min | Proyecto de automatización, data-driven y keyword-driven, herramientas de fault seeding e inyección de fallas, rendimiento, web, MBT, build, móvil |
Capítulo 1. Las tareas del TTA en las pruebas basadas en riesgo (30 min)
Es el capítulo más corto, pero marca el enfoque de todo lo demás. El TTA participa en la identificación (entrevistas con expertos, lluvia de ideas con desarrolladores, arquitectos, operaciones), la evaluación (propone la probabilidad inicial del riesgo según las guías del test manager) y la mitigación (diseña y ejecuta pruebas para las áreas de alto riesgo y evalúa el riesgo residual).
El syllabus lista factores genéricos que debes considerar. En riesgos de producto: complejidad de la tecnología y del código, cantidad de cambios en el código fuente, historial de defectos técnicos y problemas de interfaces e integración. En riesgos de proyecto: conflictos sobre requisitos técnicos, equipos distribuidos, herramientas y habilidades, presión de tiempo y alta tasa de cambio de requisitos técnicos.
Capítulo 2. Técnicas de prueba de caja blanca (300 min)
Aquí está la parte más "matemática" del examen. Debes diseñar casos de prueba (K3) para lograr un nivel de cobertura definido con cada técnica:
- Pruebas de sentencias: ejecutar cada sentencia ejecutable. El syllabus considera la cobertura total de sentencias como mínimo deseable para todo código probado.
- Pruebas de decisión: ejecutar cada resultado de cada decisión (verdadero/falso en un IF, cada caso en un CASE, entrar y no entrar en un bucle).
-
MC/DC (Modified Condition/Decision Coverage): demostrar que cada condición atómica afecta de forma independiente el resultado de la decisión. Con N condiciones independientes, normalmente bastan N+1 ejecuciones. Por ejemplo, para
if (saldo > 0 && activo && !bloqueado)necesitas al menos 4 casos, no los 8 de todas las combinaciones. - Condición múltiple: probar todas las combinaciones de valores de las condiciones atómicas. Es la más exhaustiva y la más costosa.
- Pruebas de API (K2): el syllabus las trata como un tipo de prueba más que una técnica. Destaca la importancia de las pruebas negativas, la combinatoria de parámetros y probar los mecanismos de recuperación y reintento, porque las APIs suelen estar débilmente acopladas y pueden perder transacciones.
El objetivo de nivel K4 del capítulo es seleccionar la técnica de caja blanca adecuada según la situación. Dos ideas clave:
- La cobertura de caja blanca conviene especificarla al 100%: pedir 80% suele dejar sin probar justo el código más complejo y propenso a defectos.
- En sistemas críticos para la seguridad, la norma manda. El syllabus muestra la tabla de IEC 61508: para SIL 1 se recomiendan cobertura de sentencias, de ramas y MC/DC; en SIL 4 las tres son altamente recomendadas. También menciona ISO 26262 (automotriz) y DO-178C (aeronáutica), cada una con requisitos distintos.
Si te interesa el sector automotriz, revisa también la certificación Automotive Software Tester (CT-AuT).
Capítulo 3. Análisis estático y dinámico (180 min)
Análisis estático (sin ejecutar el código), con tres objetivos K3:
- Análisis de flujo de control: detectar anomalías (bucles mal diseñados, código inalcanzable, funciones nunca llamadas) y calcular la complejidad ciclomática, un indicador de cuántos caminos independientes tiene un componente. A mayor complejidad, más candidato a refactorizar.
- Análisis de flujo de datos: seguir el ciclo de vida de cada variable (definir, usar, destruir) y detectar secuencias anómalas: definir dos veces sin usar, usar antes de definir, usar después de destruir o definir sin liberar (posible fuga de memoria).
- Mejorar la mantenibilidad: verificar estándares de codificación, detectar código repetido, medir acoplamiento (bajo es mejor) y cohesión (alta es mejor), y revisar la estructura de sitios web.
Análisis dinámico (durante la ejecución), con un objetivo K3: aplicarlo para un fin concreto, como detectar fugas de memoria (que suelen aparecer solo después de horas en producción), punteros salvajes (que pueden no causar nada, corromper datos o tumbar el programa) y analizar la eficiencia de rendimiento.
Capítulo 4. Características de calidad para pruebas técnicas (345 min)
Es el capítulo más largo. Empieza con la planeación de pruebas no funcionales, donde está el otro K4 importante: analizar requisitos no funcionales de un escenario y escribir las secciones correspondientes del plan de pruebas. Consideras requisitos de stakeholders, entornos de prueba, adquisición de herramientas y capacitación, aspectos organizacionales y protección de datos.
Luego recorre las características del modelo ISO 25010, explicando por qué incluir cada tipo de prueba y cómo planearlo y especificarlo:
- Seguridad: confidencialidad, integridad, no repudio, responsabilidad, autenticidad. Por qué incluirla y cómo planear y especificar pruebas de seguridad.
- Fiabilidad: madurez, disponibilidad, tolerancia a fallas y recuperabilidad, incluidos modelos de crecimiento de fiabilidad.
- Rendimiento: comportamiento temporal, uso de recursos y capacidad; pruebas de carga, estrés y escalabilidad.
- Mantenibilidad: analizabilidad, modificabilidad, modularidad, reusabilidad y testabilidad.
- Portabilidad: instalabilidad, adaptabilidad y reemplazabilidad.
- Compatibilidad: coexistencia con otros sistemas en el mismo entorno.
- Perfiles operacionales: patrones de uso (cuántos usuarios, qué operaciones, con qué frecuencia) para generar cargas realistas en pruebas de fiabilidad y rendimiento.
Ejemplo: para una app de pagos que lanzará una promoción, el perfil operacional define 70% consultas de saldo, 25% pagos y 5% altas de tarjeta; con él configuras una prueba de carga al volumen esperado y una de estrés al triple. Si quieres profundizar, revisa Performance Testing (CT-PT), Security Tester (CT-SEC) y nuestro curso de performance con JMeter.
Capítulo 5. Revisiones (165 min)
El TTA debe participar activamente en revisiones técnicas y necesita tiempo de preparación; sin él, la revisión se convierte en una corrección de redacción. Los dos objetivos K4 piden analizar un diseño de arquitectura y un fragmento de código o pseudocódigo con un checklist del syllabus:
- Checklist de arquitectura (ejemplo de comportamiento temporal en sitios web): pool de conexiones, balanceo de carga, procesamiento distribuido, caché, instanciación diferida, concurrencia de transacciones, separación OLTP/OLAP y replicación de datos.
- Checklist de código: estructura, documentación, variables, operaciones aritméticas, bucles y ramas, y programación defensiva.
En el examen esto se traduce en preguntas donde lees pseudocódigo y señalas qué problemas del checklist están presentes.
Capítulo 6. Herramientas de prueba y automatización (180 min)
El syllabus insiste en que un proyecto de automatización es un proyecto de desarrollo de software: necesita arquitectura, diseño, revisiones y pruebas propias. Temas principales:
- Tareas del TTA al definir un proyecto de automatización: elegir la herramienta, definir interfaces con gestión de pruebas, defectos e integración continua, desarrollar adaptadores, elegir el enfoque, estimar con el test manager y planear el mantenimiento.
- Data-driven vs. keyword-driven: y automatizar por GUI, API o línea de comandos.
- Problemas técnicos que arruinan el retorno de inversión: no manejar fallas del software durante la ejecución o no regresar el sistema a un estado conocido al terminar cada prueba.
- Construir palabras clave a partir de un proceso de negocio (K3): por ejemplo "Iniciar_Sesion", "Seleccionar_Pedido", "Cancelar_Pedido", equilibrando nivel de detalle y mantenimiento.
- Herramientas específicas: fault seeding (insertar defectos para medir la calidad de tus pruebas), inyección de fallas (forzar condiciones de error), rendimiento, pruebas web, pruebas basadas en modelos, pruebas de componentes y build, y simuladores y emuladores para móvil.
Para llevar esto a la práctica, revisa nuestros cursos de Playwright, API Automation con Postman y automatización móvil con Appium.
Descarga el syllabus oficial
Descarga el programa de estudio oficial CTAL-TTA v4.0, la fuente de todas las preguntas del examen:
En ISTQB.org también encontrarás las preguntas de examen de muestra, las notas de versión y el documento de visión general con los objetivos de negocio.
El examen CTAL-TTA v4.0
| Característica | Detalle |
|---|---|
| Número de preguntas | 45, de opción múltiple |
| Puntos posibles | 78 |
| Puntaje para aprobar | 51 puntos (65%) |
| Duración | 120 minutos; 150 minutos (+25%) si no lo presentas en tu lengua materna |
| Requisito | Certificación ISTQB Foundation Level |
| Vigencia | La certificación ISTQB no caduca |
Fuente: página oficial de CTAL-TTA y tabla de estructura de exámenes de ISTQB.
Todo el syllabus es examinable salvo la introducción y los apéndices. Las preguntas pueden combinar material de varias secciones. No necesitas un curso acreditado para presentarlo.
Modalidades
- En línea con supervisión remota (iSQI FLEX): 24/7. Para Advanced Level 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 hay examen en papel. La certificación vale igual en cualquier idioma.
Dónde comprarlo
- Directo en iSQI.org, nuestro partner y proveedor oficial de exámenes. Si te inscribes a uno de nuestros cursos te enviamos un cupón de 20% sobre el precio de su página para tu primera oportunidad.
- Con Cool Testers, con 1 o 2 oportunidades, si lo paga tu empresa o necesitas factura. Tienes 1 año para presentarlo.
Consulta precios en tu moneda en la guía de la certificación ISTQB.
Cómo prepararte
- Repasa caja blanca de Foundation y luego practica MC/DC hasta que puedas armar los pares de casos sin dudar. Es de lo más preguntado y de lo más fácil de entrenar con ejercicios.
- Lee pseudocódigo todos los días. Los capítulos 2, 3 y 5 te piden calcular cobertura, complejidad ciclomática, detectar anomalías de flujo de datos y aplicar checklists de código.
- Haz tablas resumen del capítulo 4: por cada característica (seguridad, fiabilidad, rendimiento, mantenibilidad, portabilidad, compatibilidad) anota subcaracterísticas, por qué probarla, tipos de defecto que encuentra y cuándo en el ciclo de vida.
- Practica el K4 de planeación: toma un requisito no funcional real de tu proyecto y escribe la sección del plan de pruebas.
- Resuelve el examen de muestra oficial cronometrado y analiza cada justificación.
- Conecta con tu trabajo: mide la cobertura de tu suite actual, ejecuta un análisis estático o revisa un pull request con el checklist del syllabus.
Beneficios y salidas profesionales
- Puente entre QA y desarrollo: hablas el mismo idioma que desarrolladores y arquitectos en revisiones de código y diseño.
- Base para especializarte: rendimiento, seguridad, automatización o sistemas críticos parten de lo que ves aquí.
- Roles a los que apunta: QA engineer senior, SDET, ingeniero de automatización, ingeniero de rendimiento, analista de pruebas técnicas, QA en sistemas embebidos o regulados.
- Criterio para la automatización: entiendes por qué fracasan los proyectos de automatización y cómo diseñarlos para que den retorno.
- Reconocimiento internacional y sin caducidad.
Si estás eligiendo herramienta, te puede servir nuestra comparativa Playwright vs. Selenium vs. Cypress.
Relación con otras certificaciones y siguiente paso
| Si te interesa… | Siguiente certificación |
|---|---|
| Diseñar y mantener soluciones de automatización | Test Automation Engineering (CTAL-TAE) y Test Automation Strategy (CT-TAS) |
| El lado funcional y de negocio | Test Analyst (CTAL-TA) |
| Liderar y gestionar las pruebas | Test Management (CTAL-TM) |
| Ágil técnico (TDD, BDD, CI) | Agile Technical Tester (CTAL-ATT) |
| DevOps | Quality in DevOps (CT-QDO) |
| Rendimiento | Performance Testing (CT-PT) |
| Seguridad | Security Tester (CT-SEC) y Security Test Engineer (CT-STE) |
| Pruebas basadas en modelos | Model-Based Testing (CT-MBT) |
| IA | AI Testing (CT-AI) y testing con IA y Playwright MCP |
Preguntas frecuentes
¿Necesito saber programar para el Technical Test Analyst?
No necesitas ser desarrollador, pero el syllabus asume conocimientos generales de programación y de arquitecturas de sistemas. En el examen vas a leer pseudocódigo, calcular cobertura y detectar problemas en fragmentos de código.
¿Cuántas preguntas tiene el examen CTAL-TTA y cuál es la calificación mínima?
Tiene 45 preguntas de opción múltiple con 78 puntos posibles. Apruebas con 51 puntos (65%). Dura 120 minutos, o 150 si no lo presentas en tu lengua materna.
¿Qué requisito necesito para presentar el CTAL-TTA?
Tener la certificación ISTQB Certified Tester Foundation Level. ISTQB.org también menciona experiencia práctica suficiente, cuyo criterio específico define el board miembro o el proveedor de examen. El curso acreditado no es obligatorio.
¿Conviene más Test Analyst o Technical Test Analyst?
Depende de tu perfil. Si trabajas con negocio, requisitos y pruebas funcionales, elige Test Analyst. Si trabajas con código, APIs, rendimiento, seguridad o automatización, elige Technical Test Analyst. Muchas personas terminan haciendo ambas.
¿El CTAL-TTA sirve para automatización?
Sí. El capítulo 6 cubre cómo definir un proyecto de automatización, data-driven vs. keyword-driven, causas técnicas de fracaso y herramientas específicas. Si la automatización es tu foco principal, complementa con Test Automation Engineering (CTAL-TAE).
¿La v4.0 incluye basis path testing?
No. Basis path testing se eliminó en la v4.0. Las técnicas de caja blanca evaluadas son sentencias, decisiones, MC/DC y condición múltiple, además de las pruebas de API.
¿La certificación caduca?
No. Las certificaciones ISTQB de Foundation y Advanced Level no caducan.