Las combinaciones de casos de prueba con IA son útiles cuando una funcionalidad depende de varias condiciones al mismo tiempo. En aplicaciones reales, los defectos no siempre aparecen por un dato inválido aislado. Surgen cuando coinciden un rol, un estado, un límite, un canal y la respuesta inesperada de una dependencia. Uso la IA para construir ese mapa, pero no para ejecutar ciegamente todas las posibilidades.
La cobertura completa por fuerza bruta casi nunca es viable. Diez variables con cuatro valores cada una producen más de un millón de combinaciones. El trabajo del QA consiste en reducir ese espacio sin perder los escenarios que protegen riesgos importantes. La IA puede acelerar el inventario y detectar relaciones, mientras técnicas como partición de equivalencia, valores límite, tablas de decisión, transición de estados y pairwise ayudan a seleccionar.
Cómo convertir variables y reglas en una matriz de pruebas con IA
Comienzo por separar cuatro elementos:
- Variables: canal, perfil, tipo de cuenta, moneda, monto, fecha o estado.
- Valores o particiones: rangos válidos, inválidos, límites y categorías equivalentes.
- Restricciones: combinaciones imposibles o no permitidas.
- Riesgos: resultados que causarían daño al usuario, al dinero, a los datos o a la operación.
Si entrego únicamente una lista de campos, la IA puede combinar valores de forma matemática pero no comprender cuáles tienen sentido. Por eso incluyo reglas confirmadas y le pido que marque cualquier combinación que dependa de un supuesto.
El error de pedir «todas las posibilidades»
La frase parece ambiciosa, pero suele producir tres problemas. Primero, la salida se vuelve demasiado grande para revisar. Segundo, aparecen combinaciones equivalentes que no agregan cobertura. Tercero, la cantidad oculta los escenarios realmente críticos.
Prefiero trabajar por capas. Empiezo con el flujo principal y los límites. Después agrego decisiones de negocio, estados y permisos. Finalmente incorporo fallos de integración, concurrencia y tiempo. Cada capa responde a un tipo de riesgo y puede asignarse a un nivel de prueba distinto.
Ejemplo: variables de una transferencia
Una transferencia aparentemente sencilla puede depender de:
- canal: web, aplicación móvil o API;
- usuario: titular, delegado o perfil restringido;
- cuenta origen: activa, bloqueada, cerrada o sin saldo;
- destinatario: nuevo, frecuente, eliminado o bloqueado;
- monto: cero, mínimo, interior del rango, máximo o superior;
- acumulado diario: por debajo, exactamente en el límite o superado;
- autenticación: válida, vencida, incorrecta o interrumpida;
- respuesta externa: éxito, rechazo, timeout o respuesta tardía;
- hora: jornada normal, cambio de día o ventana de mantenimiento.
No necesito combinar cada canal con cada estado si el comportamiento se implementa en una capa compartida y ya existe evidencia suficiente. En cambio, sí podría ampliar cobertura cuando una versión móvil antigua usa un contrato diferente o cuando el cambio de día afecta el acumulado.
Las técnicas que pido aplicar
Particiones de equivalencia
Agrupo valores que deberían recibir el mismo tratamiento. Para el monto puedo tener inválido inferior, válido y inválido superior. Luego selecciono representantes, evitando probar números distintos que ejercitan exactamente la misma regla.
Valores límite
Para cada frontera pruebo valores justo por debajo, exactamente en el límite y justo por encima. Si el sistema maneja decimales, moneda o redondeo, documento la precisión esperada.
Tablas de decisión
Son útiles cuando el resultado depende de varias condiciones. Por ejemplo: saldo suficiente, límite disponible, cuenta activa y autenticación válida. La IA puede proponer reglas, pero yo verifico que no invente combinaciones ni acciones.
Transiciones de estado
No solo valido estados individuales. Reviso caminos permitidos y prohibidos: creada, pendiente, procesando, exitosa, rechazada, reversada. También considero eventos repetidos, tardíos o fuera de orden.
Cobertura pairwise
Cuando muchas variables pueden interactuar, pairwise busca cubrir cada par de valores al menos una vez dentro de un conjunto reducido. El proyecto de pruebas combinatorias automatizadas de NIST ofrece una base técnica y herramientas para este enfoque. No reemplaza los escenarios de negocio críticos; los complementa.
Un prompt que obliga a mostrar el razonamiento útil
En lugar de solicitar una tabla final de inmediato, divido el trabajo:
- Identifica variables y cita la regla que origina cada una.
- Propón particiones y límites sin inventar valores.
- Enumera restricciones y combinaciones imposibles.
- Relaciona variables que podrían interactuar.
- Señala escenarios obligatorios por riesgo.
- Propón un conjunto reducido y explica qué cubre.
- Lista incertidumbres que requieren confirmación.
La explicación me permite detectar errores. Si la IA excluye una combinación porque «normalmente no ocurre», necesito confirmar que la arquitectura realmente la impide.
Cómo elijo qué automatizar
Automatizo combinaciones estables, repetibles y con resultados claros. Las validaciones de reglas y contratos suelen ser mejores candidatas para API o capas inferiores que para interfaz. Los escenarios visuales o exploratorios pueden mantenerse manuales si requieren observación y aprendizaje.
También cuido los datos. Una matriz grande puede tardar poco en generarse y mucho en ejecutarse si cada caso depende de usuarios o cuentas difíciles de preparar. La cobertura debe considerar costo de creación, limpieza y diagnóstico.
Qué no delegaría a la IA
No delegaría la definición de qué riesgo es aceptable, la confirmación de una combinación imposible ni la decisión de que la cobertura es suficiente. Tampoco asumiría que un algoritmo pairwise cubre una regla que depende de tres o más condiciones específicas.
La IA puede ordenar y reducir, pero el QA debe agregar casos obligatorios derivados de incidentes, dinero, seguridad, cumplimiento y conocimiento del producto.
Cómo medir el resultado
Comparo el número inicial de combinaciones con el conjunto seleccionado, pero no presento la reducción como éxito por sí sola. Registro qué reglas, pares, límites, estados y riesgos quedaron cubiertos. Después observo defectos encontrados, redundancia y costo de mantenimiento.
Si una combinación detecta un defecto, reviso si representa una clase de riesgo más amplia. Tal vez no necesito agregar solo ese caso: puedo mejorar la regla, el generador de datos o la cobertura en otra capa.
Cobertura amplia y ejecutable
El objetivo no es demostrar que imaginé más escenarios que el resto del equipo. Es construir una cobertura que pueda ejecutarse, explicarse y mantenerse. La IA amplía el mapa; las técnicas de diseño reducen el espacio; el análisis de riesgo decide dónde profundizar.
Esta práctica parte de historias bien analizadas. Por eso conviene comenzar con el artículo sobre cómo hacer preguntas efectivas y conectar después las combinaciones con la estrategia de pruebas de APIs.
La matriz puede transformarse después en casos de prueba creados con IA y alimentarse con datos de prueba sintéticos y seguros.