Introducción y objetivos de la automatización — Apuntes CTAL-TAE v2.0 (capítulo 1)

Qué es (y qué no es) la automatización de pruebas

Automatizar pruebas es usar software para ejecutar o dar soporte a actividades de prueba: ejecución, comparación de resultados, preparación de datos, informes y monitorización.
La automatización NO es una actividad de testing por sí misma: no diseña pruebas ni sustituye al pensamiento crítico ni a las pruebas exploratorias.
El código de automatización es software real: se diseña, se revisa, se versiona y se mantiene con los mismos estándares que el código de producción.
Se automatiza para obtener repetibilidad, feedback rápido y cobertura sostenida, no para "ahorrar testers".
Términos clave: SUT (System Under Test), TAS (Test Automation Solution), TAA (Test Automation Architecture), TAF (Test Automation Framework), testware.

Ventajas, desventajas y límites

Ventajas: ejecuta más pruebas en menos tiempo, elimina el error humano en tareas repetitivas, permite pruebas imposibles a mano (carga, concurrencia), da feedback temprano en CI y libera a las personas para pruebas de mayor valor.
Desventajas: coste inicial alto, coste de mantenimiento permanente, dependencia de herramientas y de habilidades de programación, riesgo de falsos negativos que erosionan la confianza.
Límite fundamental: la automatización comprueba lo que se le dijo que comprobara. No detecta problemas que nadie previó ni evalúa usabilidad o experiencia de usuario.
Automatizar una prueba mala solo consigue ejecutar más rápido una prueba mala.
El ROI aparece cuando el ahorro acumulado por ejecución supera el coste de desarrollo + mantenimiento; una prueba que se ejecuta dos veces al año rara vez lo alcanza.

La automatización a lo largo del SDLC

Modelos secuenciales: la automatización llega tarde, se centra en regresión de sistema y suele sufrir por requisitos ya congelados.
Modelos iterativos/ágiles: la automatización acompaña a cada incremento; se necesita testware que soporte cambios frecuentes de la interfaz.
DevOps y CI/CD: la automatización es el mecanismo de control de calidad de la pipeline; los tiempos de ejecución y la estabilidad pasan a ser requisitos duros.
Shift-left: automatizar unitarias, de componente, de API y de contrato antes que la interfaz de usuario.
Shift-right: monitorización, pruebas en producción, canary releases y observabilidad como complemento, no como sustituto.

Impacto de la arquitectura del SUT en la elección de herramientas

La tecnología del SUT condiciona la herramienta: web, móvil nativo, escritorio, embebido, mainframe, API, colas de mensajes o sistemas distribuidos requieren capacidades distintas.
Monolito: pocos puntos de integración pero entornos pesados y despliegues lentos. Microservicios: muchos interfaces, ideal para pruebas de API y de contrato.
Sistemas con interfaces propietarias o sin identificadores estables obligan a wrappers/adaptadores propios o a reconocimiento por imagen (frágil).
Si el SUT no expone puntos de control y observación, la automatización acabará dependiendo de la GUI, la capa más cara y frágil.
La decisión de herramienta debe considerar también el entorno de despliegue: contenedores, cloud, dispositivos reales frente a emuladores.

Siguiente paso

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