ISTQB CTAL-TAE v2.0 · Capítulo 3 de 8
Arquitectura de automatización (gTAA)
Apuntes del capítulo 3 del syllabus CTAL-TAE v2.0, con 5 bloques de contenido y los puntos que más se preguntan en el examen.
La gTAA y sus capas
- La gTAA (generic Test Automation Architecture) es un modelo de referencia en capas para diseñar una solución de automatización mantenible.
- Capa de generación de pruebas (Test Generation): da soporte al diseño manual o automático de casos de prueba.
- Capa de definición de pruebas (Test Definition): define casos, datos y librerías de forma independiente del SUT y de la herramienta.
- Capa de ejecución de pruebas (Test Execution): ejecuta, registra el log y compara resultados esperados y obtenidos.
- Capa de adaptación (Test Adaptation): conecta la solución con los interfaces reales del SUT (GUI, API, servicios, hardware) mediante adaptadores.
- Transversalmente: gestión de configuración, gestión del proyecto de automatización y reporting.
Enfoques de scripting
- Lineal / capture-replay: rápido de crear, imposible de mantener; sirve solo para demos o pruebas de un solo uso.
- Estructurado: introduce control de flujo y funciones reutilizables; primer nivel de mantenibilidad.
- Data-driven: separa datos de la lógica; un mismo script cubre muchos casos cambiando la tabla de datos.
- Keyword-driven: separa además las acciones en palabras clave; permite que personas no programadoras definan casos.
- Process-driven / model-based: los casos se derivan de flujos de negocio o de un modelo formal del comportamiento.
- BDD: escenarios en lenguaje natural (Gherkin) vinculados a código; su valor real es la conversación y la comprensión compartida, no la sintaxis.
Principios de diseño aplicados al testware
- Separación de responsabilidades: casos de prueba, datos, localizadores, acciones de negocio y utilidades técnicas viven en sitios distintos.
- DRY: la duplicación de lógica multiplica el coste de cada cambio del SUT.
- Abstracción por capas: el caso de prueba habla el lenguaje del negocio ("iniciar sesión"), no el de la herramienta ("click en #btn-submit").
- KISS y legibilidad: un test debe leerse como una especificación; la astucia técnica se paga en mantenimiento.
- Un test, un objetivo: aserciones claras y fallo con un mensaje que explique qué se esperaba y qué ocurrió.
- Sin dependencias entre tests y sin estado compartido: cada test se prepara y se limpia solo.
Patrones de diseño en automatización
- Page Object Model: cada pantalla se encapsula en una clase que expone acciones de negocio y oculta los localizadores.
- Screenplay / Actor: modela actores, tareas y preguntas; escala mejor que POM en suites grandes y muy reutilizables.
- Facade y Adapter: ocultan APIs complejas o cambiantes tras una interfaz estable propia.
- Factory y Builder: crean datos y objetos de prueba con valores por defecto sensatos y variaciones explícitas.
- Wrappers sobre la herramienta: aislar la librería (driver, cliente HTTP) permite cambiarla sin reescribir la suite.
- Fluent interfaces para mejorar la legibilidad de los pasos encadenados.
Requisitos de calidad de la solución (TAS)
- Mantenibilidad: el criterio dominante; determina el coste a lo largo de toda la vida de la suite.
- Fiabilidad: resultados deterministas; sincronización explícita en lugar de esperas fijas (sleep).
- Rendimiento: tiempo de ejecución compatible con la pipeline; paralelización y selección de pruebas.
- Portabilidad: ejecutable en local, en CI y en distintos entornos sin cambios de código.
- Seguridad: credenciales fuera del repositorio, en gestores de secretos; nunca datos reales sensibles en logs.
- Reusabilidad y escalabilidad: librerías compartidas, convenios de nombres y estructura por dominios.
Siguiente paso
Ahora toca comprobar si se ha quedado: entra en el simulador, filtra por el capítulo 3 y haz una tanda de diez preguntas. Cada respuesta incluye la justificación completa.
El syllabus oficial completo del CTAL-TAE v2.0 se descarga gratis desde istqb.org, y los términos están definidos en el glosario oficial.