En la Parte 1 nos peleamos con el diagrama, lo domamos en ASCII, le pusimos nombres y apellidos a cada split, y conseguimos un mapa claro de todos los caminos posibles.
Pero ahora llega la pregunta del millón: ¿hay que probar absolutamente todos los caminos?
Spoiler: no siempre… y aquí es donde la teoría del ISTQB y la realidad del día a día se dan la mano (o se pelean).
Dos métricas clave: Branch Coverage y Path Coverage
Según ISTQB, la cobertura de pruebas estructurales se puede medir de varias formas, pero estas dos son las más conocidas:
-
Branch Coverage (o decision coverage) mide el porcentaje de ramas que han sido ejecutadas por el conjunto de pruebas.
-
Path Coverage mide el porcentaje de rutas completas que se han ejecutado, considerando todas las combinaciones posibles de decisiones en el flujo.
-
Dato útil: alcanzar un 100 % de branch coverage implica automáticamente tener 100 % de statement coverage (cobertura de sentencias).
En los materiales de Foundation Level del ISTQB, el énfasis está en cobertura de sentencias y decisiones como técnicas básicas, mientras que la cobertura de rutas se introduce como un concepto más avanzado y, sinceramente, más complejo de aplicar en la práctica.
¿Hasta dónde hay que llegar?
La cobertura de todos los caminos (path coverage) suena muy bien… hasta que te das cuenta de que con n decisiones podrías tener hasta 2ⁿ caminos distintos.
Por eso, ISTQB y la mayoría de buenas prácticas recomiendan el basis path testing:
-
Garantiza el 100 % de cobertura de ramas.
-
Añade algunas rutas extra necesarias para cubrir combinaciones críticas.
-
Evita que el número de casos se dispare de forma exponencial.
Aquí entra el momento de sinceridad: lo que se lee en libros y lo que pasa en proyectos con deadlines imposibles son dos mundos diferentes.
Cobertura para nuestro Agente
-
Escenario realista: si el presupuesto de testing es tan generoso como el stock de bolígrafos en la oficina, lo mínimo aceptable —y de hecho una buena práctica— es apuntar a un 100 % de branch coverage. Con nuestros números, eso son 12 de los 14 caminos. Te da robustez, control y la tranquilidad de que cada decisión posible se ha probado al menos una vez.
-
Escenario “nos sobra tiempo y café”: en este flujo concreto, la diferencia entre branch y path coverage completo son solo 2 casos más. Así que, si el contexto, el entorno o el cliente lo permiten, puede que merezca la pena “tirarse a la piscina” y cubrir el 100 % de paths. No porque sea obligatorio, sino porque aquí el coste extra es bajo y el valor de decir “lo hemos probado TODO” queda bonito en la reunión.
Regla de bolsillo:
-
Bajo recursos → 100 % branch coverage: seguro, alcanzable y defendible.
-
Recursos holgados o flujo pequeño → ve a por el 100 % de paths, por puro cierre y paz mental.
¿Cuántos necesito para 100% Branch Coverage?
Con nuestro flujo, el mínimo para cubrir todas las ramas (todas las opciones de cada IF) son 12 de 14 caminos. Una selección mínima que cumple es:
Ejecuta:
1, 2, 3, 4, 5, 6, 7, 8, 9, 12, 13, 14
Los caminos 10 y 11 (1B-2I-7J/K) no son necesarios para branch coverage porque ya cubrimos I, J y K con 4 y 5.
Llegó el momento: que la IA se ponga a trabajar
Aquí es donde entra el Data-Driven Testing (DDT), esa técnica en la que defines un solo set de pasos y los alimentas con diferentes datos, en lugar de clonar el caso de prueba hasta que tu herramienta empiece a pedir vacaciones. La gracia está en que separas el guion (los pasos) de los actores (los datos), y así todo encaja como un Lego.
Cualquier herramienta o framework decente que soporte datasets o parametrización lo puede manejar: desde un gestor de pruebas tipo Xray o Zephyr hasta un runner de automatización como Robot Framework o Cypress. La elección depende de tu stack y de cuánto cariño le tengas a tu actual ecosistema de pruebas (o de cuánto miedo te dé cambiarlo).
Llegados a este punto, después de tantas idas y venidas con el diagrama, la IA generativa (como ChatGPT) ya conoce el flujo como la palma de su mano. Ha memorizado cada bifurcación, cada letra, cada recoveco… y está lista para generar los casos de prueba como un cuchillo caliente atraviesa mantequilla.
Básicamente, le pediremos dos archivos CSV y dejaremos que trabaje mientras nosotros hacemos como que revisamos correos:
1. Dataset DDT
- Cada fila es un camino del flujo.
- Las columnas corresponden a nuestras interacciones: Input1, Bot1, Input2, Bot2… hasta cubrir todos los pasos posibles.
- Un “-” indica que el flujo termina ahí.
- Este CSV es el buffet libre de datos que va a alimentar nuestros pasos de prueba, listo para importar en herramientas de testing.
2. Pasos parametrizados
- Columnas tipo Action, Data, Expected Result
- Las celdas de Data y Expected Result llevan variables como ${Input1} o ${Bot2}, que la herramienta sustituirá por los valores del dataset (sin necesidad de duplicar casos de prueba).
- Subes el dataset como conjunto de datos
- Importas el CSV de pasos como caso de prueba base
- La herramienta se encarga del resto y lanzar cada fila en los test run como si fueran un caso de prueba nuevo e independiente.
Ejemplo de un camino "desparametrizado"
Moraleja final
En este punto, la IA generativa no solo ha aprendido a fondo un flujo: está engrasada. Ha interiorizado tu lógica, tu nomenclatura y tu estilo de diseño, lo que significa que puede aplicar el mismo patrón a otros flujos del mismo proyecto sin volver a empezar de cero.
Si tu proyecto requiere diseñar varios asistentes, procesos o árboles de decisión, el beneficio se vuelve exponencial: cada nuevo flujo se construye más rápido, con menos fricción y con la coherencia intacta entre todos ellos.
En otras palabras, has convertido a la IA en tu arquitecto residente de casos de prueba. Y aunque no te traiga café, al menos no se queja cuando le pides el tercer diagrama del día.
Comentarios
Publicar un comentario