ISTQB CTAL-TAE v2.0 · Capítulo 4 de 8
Implementación de la automatización
Apuntes del capítulo 4 del syllabus CTAL-TAE v2.0, con 4 bloques de contenido y los puntos que más se preguntan en el examen.
Proyecto piloto
- El piloto valida herramienta, arquitectura y proceso sobre un alcance pequeño, representativo y con valor real.
- Debe tener objetivos medibles, duración acotada y criterios de éxito definidos antes de empezar.
- Un buen piloto entrega también la infraestructura mínima: repositorio, integración con CI, informes y convenciones.
- Al terminar se decide con datos: continuar, ajustar la arquitectura o cambiar de herramienta.
- Elegir un área estable y conocida evita confundir problemas del SUT con problemas de la automatización.
Despliegue, riesgos y contingencias
- Despliegue incremental por áreas o equipos; el "big bang" concentra todos los riesgos en un punto.
- Riesgos habituales: expectativas irreales, falta de habilidades, entorno inestable, mantenimiento no presupuestado, dependencia de una sola persona.
- Contingencias: formación y pairing, documentación, propiedad compartida del código, revisión por pares, presupuesto explícito de mantenimiento.
- Gestión del cambio: el equipo debe adoptar la suite; una suite que solo entiende su autor muere con su marcha.
- Definir desde el principio quién arregla un test roto y en qué plazo — sin eso, la suite se ignora en semanas.
Mantenibilidad del código de automatización
- Aplicar al testware las prácticas de ingeniería: control de versiones, revisión de código, estándares, análisis estático y refactorización periódica.
- Convenciones de nombres consistentes y estructura de carpetas por dominio funcional, no por tipo de fichero.
- Documentar el "por qué" (decisiones de arquitectura, workarounds), no el "qué" que ya dice el código.
- Evitar la duplicación de localizadores y de datos; centralizar en un único punto de cambio.
- Medir y vigilar la deuda técnica del testware igual que la del producto.
Tratamiento del flakiness
- Un test inestable (flaky) es el que pasa y falla sin cambios en el SUT; destruye la confianza más rápido que un fallo real.
- Causas frecuentes: sincronización, datos compartidos, dependencias entre tests, orden de ejecución, entorno y servicios externos.
- Medidas: esperas explícitas por condición, aislamiento de datos, reintentos controlados y trazados, cuarentena temporal con fecha límite.
- Reintentar sin investigar oculta defectos reales del producto: el reintento es una medida temporal, no la solución.
- Medir la tasa de flakiness por test y tratarla como un defecto con prioridad, no como ruido aceptable.
Siguiente paso
Ahora toca comprobar si se ha quedado: entra en el simulador, filtra por el capítulo 4 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.