Preparación para la automatización — Apuntes CTAL-TAE v2.0 (capítulo 2)

Factores del SUT que condicionan la automatización

Interfaces disponibles: GUI, API/REST, línea de comandos, base de datos, colas de mensajes, ficheros. Cuantos más interfaces estables, mejor.
Estabilidad del SUT: si la interfaz cambia cada sprint, la automatización de GUI se convierte en deuda desde el día uno.
Datos de prueba: disponibilidad, volumen, anonimización, restauración del estado inicial y aislamiento entre ejecuciones.
Dependencias externas: servicios de terceros, pasarelas de pago, hardware. Se resuelven con stubs, mocks o virtualización de servicios.
Tamaño y complejidad: sistemas heredados sin documentación exigen una fase de exploración técnica previa.

Diseño para la testabilidad (SUT testability)

Observabilidad: poder ver el estado interno — logs estructurados, endpoints de salud, trazas, eventos, códigos de error significativos.
Controlabilidad: poder llevar el sistema a un estado concreto — APIs de setup, creación de datos por servicio, feature flags, inyección de configuración.
Identificadores estables: atributos como data-testid o id propios para automatización, nunca XPaths posicionales dependientes del maquetado.
Test hooks: puntos de enganche pensados para pruebas, acordados con desarrollo y desactivables en producción.
La testabilidad se negocia con el equipo de desarrollo antes de escribir el primer script: es un requisito no funcional del producto.

Entornos y datos de prueba

El entorno de automatización debe ser reproducible: infraestructura como código, contenedores y versiones fijadas.
Aislamiento: cada ejecución debe partir de un estado conocido; los tests que dependen del orden o de residuos previos son una fuente clásica de flakiness.
Estrategias de datos: datos fijos (fixtures), generados, extraídos de producción anonimizados o creados vía API en el propio test.
Los datos sensibles requieren anonimización o sintetización por cumplimiento legal (RGPD).
Un entorno compartido con pruebas manuales o con otros equipos degrada la fiabilidad: conviene entorno dedicado o efímero.

Selección y evaluación de herramientas

Criterios técnicos: compatibilidad con la tecnología del SUT, soporte de los interfaces necesarios, integración con CI/CD, capacidades de informe, ejecución paralela y multiplataforma.
Criterios organizativos: coste total (licencia, formación, mantenimiento), habilidades del equipo, soporte y comunidad, madurez, vendor lock-in y estrategia de salida.
Comercial frente a open source: la comparación relevante es coste total de propiedad y encaje, no el precio de la licencia.
Prueba de concepto (PoC) o piloto sobre un caso representativo antes de comprometerse: es la única evidencia fiable.
Considerar el ecosistema completo: gestión de casos, reporting, gestión de datos, dispositivos, virtualización de servicios.

Análisis coste-beneficio y expectativas

Estimar coste de creación, coste de mantenimiento por cambio y ahorro por ejecución para calcular el punto de equilibrio.
Priorizar por riesgo, frecuencia de ejecución y estabilidad del área del SUT; no por facilidad de automatizar.
Gestionar expectativas de dirección: la automatización no elimina defectos, no sustituye pruebas exploratorias y no da resultados el primer mes.
Objetivos medibles y acordados desde el inicio (tiempo de feedback, cobertura de regresión, tasa de flakiness) evitan la decepción posterior.
Malas métricas de partida — por ejemplo "porcentaje de casos automatizados" — incentivan automatizar lo fácil, no lo valioso.

Siguiente paso

Ahora toca comprobar si se ha quedado: entra en el simulador, filtra por el capítulo 2 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.