Identificar oportunidades de mejora

  • Las mejoras se identifican con datos: métricas de duración, flakiness, fallos por causa y coste de mantenimiento.
  • Fuentes de mejora: retrospectivas, análisis de defectos escapados, revisión de la suite y feedback de los desarrolladores.
  • Priorizar por impacto: primero lo que bloquea la pipeline o lo que consume más tiempo de análisis.
  • La mejora continua es una actividad planificada con tiempo asignado, no un hueco entre sprints.
  • Cada cambio de mejora debe poder medirse antes y después para saber si funcionó.

Mejorar los casos de prueba automatizados

  • Eliminar casos redundantes, obsoletos o que nunca han detectado nada relevante.
  • Reforzar aserciones débiles y dividir tests que comprueban demasiadas cosas a la vez.
  • Reducir el tiempo de ejecución: preparar estado por API en lugar de por interfaz, evitar pasos innecesarios, reutilizar sesiones.
  • Revisar la cobertura frente a los riesgos actuales del producto, no frente a los de hace dos años.
  • Borrar tests también es mejorar: una suite más pequeña y fiable vale más que una grande e ignorada.

Mejorar la arquitectura y el código

  • Refactorizar hacia capas y patrones cuando el coste de cada cambio del SUT se dispara.
  • Consolidar librerías y utilidades duplicadas entre equipos en componentes compartidos y versionados.
  • Actualizar herramientas y dependencias de forma planificada: el retraso acumulado convierte la actualización en un proyecto.
  • Migrar o sustituir herramientas cuando dejan de encajar; planificar la coexistencia temporal de ambas soluciones.
  • Reestructurar el testware para permitir paralelización y ejecución selectiva.

Ampliar el alcance de la automatización

  • Usar herramientas para tareas más allá de la ejecución: generación de datos, preparación de entornos, monitorización, análisis de resultados.
  • Automatizar la gestión del propio proceso: creación de defectos, publicación de informes, etiquetado de ejecuciones.
  • Incorporar nuevos tipos de prueba: rendimiento, accesibilidad, seguridad básica, pruebas de contrato.
  • Extender la automatización a nuevos niveles o áreas solo cuando la base existente es estable.
  • Compartir conocimiento y estándares entre equipos para que la mejora sea organizativa y no local.

Siguiente paso

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