En caso de que hayas respondido la pregunta con un SI, entonces te propongo que sigas leyendo ya que suele ser el primer error encarar de esa manera el testing, y te lo explicaré a continuación.
Los sistemas convencionales operan con lógica determinista: ante la misma entrada, siempre la misma salida. Los sistemas basados en IA derivan su comportamiento de los datos de entrenamiento y pueden ser probabilísticos, no deterministas y degradarse con el tiempo.
Este nuevo escenario nos debe hacer repensar nuestra disciplina en cuanto al oráculo de prueba y la noción misma de resultado esperado.
¿Qué implica para la gestión de pruebas este nuevo enfoque que debemos adoptar a partir de desarrollos basados en IA?
▪️ Criterios de aceptación probabilísticos: umbrales de exactitud o F1-score en lugar de comparaciones exactas, con una tolerancia documentada y acordada con las partes interesadas.
▪️ Regresión frente al concept drift: monitoreo periódico del modelo en producción, no solo antes del despliegue.
▪️ Reestimación de esfuerzo y riesgo: sin un oráculo determinista, crece la dependencia de datos de referencia y de revisión humana.
Por lo que se puede leer, el testing de IA se volverá cada vez más necesario, por ende requerirá más profesionales que conozcan del tema.
¿Cómo reconocer estos nuevos escenarios?
Por «escenarios» me estoy refiriendo a identificar con un cierto grado de anticipación a los (a) criterios de aceptación probabilísticos, la (b) regresión frente al concepto drift y la (c) reestimacion de esfuerzo y riesgo, entonces me puse a investigar un poco.
Se me ocurrió encarar inicialmente este tema mediante IA Generativa, para lo cual necesariamente pensé en desarrollar frameworks que permitieran gestionar las pruebas de IA para estas instancias.
Ahora bien, estos frameworks son andamiajes de instrucción (scaffolds), no instrumentos validados. Es decir, un prompt bien diseñado mejora la calidad y la trazabilidad del razonamiento del modelo (sea cual fuere el que utilices), pero no sustituye datos de referencia ni juicio humano (recordar el concepto de «human-in-the-loop).
En sistemas de IA no existe oráculo determinista: el modelo asistente propone, la persona que prueba decide.
Los umbrales probabilísticos (F1, exactitud) no salen del prompt; deben acordarse con las partes interesadas sobre datos reales. Y todo output generado por un LLM es una hipótesis a verificar, nunca una conclusión. Esto es coherente con la definición de prueba según el programa de estudios del ISTQB CTAT: la prueba visibiliza el riesgo, entendido como amenaza al valor del producto.
El contenido que aquí propongo, para esta primera fase, cubre sólo el enfoque de prompt engineering. En la segunda fase incluiré los enfoques de loop y hardening engineering, que los estaré compartiendo durante la próxima edición del curso de Testing Ágil y Liderazgo con IA que dicto.
Estructura genérica del framework
Todos los prompts que comparto tienen la misma estructura de nueve bloques, ordenado según las mejores prácticas actuales de prompting (rol, contexto delimitado, razonamiento estructurado, formato de salida verificable y manejo explícito de incertidumbre):
[1. ROL] Definí la persona experta y su encuadre.
[2. OBJETIVO] Una sola meta, sin ambigüedad.
[3. CONTEXTO] Datos del Sprint, historia, modelo bajo prueba.
[4. ENTRADAS] Insumos delimitados con marcadores (<<< >>>).
[5. TAREA] Instrucción imperativa y acotada.
[6. RESTRICCIONES] Qué NO hacer; supuestos permitidos y prohibidos.
[7. RAZONAMIENTO] Pasos explícitos antes de concluir (cadena de pensamiento).
[8. SALIDA] Formato fijo y parseable (tabla o JSON).
[9. INCERTIDUMBRE] Declarar supuestos y marcar lo que no se puede determinar.El bloque [9] es el más importante bajo mi criterio, ya que obliga al modelo a separar lo que sabe de lo que infiere, replicando el modelo de «brecha de riesgo» del CPAT (lo que sabemos / lo que deberíamos saber).
Framework 1 — Criterios de aceptación probabilísticos
¿Cuándo aplicarlo en el Sprint?
Durante el Refinamiento y confirmándolo en la Planificación del Sprint, al escribir o revisar la historia de usuario y su Definition of Ready/Done. Es el momento en que se acuerda la tolerancia, no después de codificar.
Prompt (scaffold):
[ROL] Actuá como test lead especializado en validación de sistemas de IA.
[OBJETIVO] Traducir una historia de usuario en criterios de aceptación
probabilísticos, medibles y acordables con las partes interesadas.
[CONTEXTO] El componente bajo prueba es un modelo de IA sin salida determinista.
[ENTRADAS]
<<<historia>>> {historia de usuario + criterios actuales}
<<<metrica>>> {métrica disponible: exactitud / F1 / precisión / recall}
<<<datos_ref>>> {tamaño y naturaleza del set de referencia, si existe}
[TAREA] Proponé umbrales cuantitativos por criterio, con su tolerancia.
[RESTRICCIONES] No inventes umbrales si no hay base de datos que los sustente;
marcá esos casos como "a acordar con stakeholders". No uses comparación exacta.
[RAZONAMIENTO] 1) Identificá qué es verificable vs. exploratorio.
2) Asociá cada criterio a una métrica. 3) Justificá cada umbral o su ausencia.
[SALIDA] Tabla: | Criterio | Métrica | Umbral propuesto | Tolerancia | Fuente/Supuesto |
[INCERTIDUMBRE] Listá qué umbrales NO pueden fijarse sin datos y por qué.Input que requiere: historia de usuario con criterios en lenguaje natural, la métrica de evaluación disponible y la descripción del set de referencia.
Output esperable (para contrastar contra el obtenido): una tabla donde cada criterio funcional tenga métrica y umbral con tolerancia explícita, y donde los criterios sin base de datos aparezcan marcados como «a acordar», nunca inventados. Señal de buen resultado: no hay comparaciones exactas y toda cifra tiene fuente o supuesto declarado.
Framework 2 — Regresión frente al concept drift
¿Cuándo aplicarlo en el Sprint?
No es una verificación única previa al despliegue. Se instrumenta como ítem recurrente del backlog en cada Sprint y se debe aplicar en la Revisión del Sprint (evidencia de monitoreo en producción) y en la Retrospectiva (ajuste de la estrategia). El disparador operativo es el monitoreo continuo, no el evento de release. Aquí uno más de los cambios de «chip» que debemos tener.
Prompt (scaffold):
[ROL] Actuá como test lead que diseña la estrategia de regresión para un
modelo ya desplegado en producción.
[OBJETIVO] Distinguir regresión funcional de degradación por concept drift
y proponer el plan de monitoreo periódico.
[CONTEXTO] El modelo se comporta de forma probabilística y su entorno cambia.
[ENTRADAS]
<<<baseline>>> {métricas de referencia del modelo al desplegar}
<<<produccion>>> {métricas observadas en ventanas recientes}
<<<cambios>>> {cambios conocidos en datos de entrada o negocio}
[TAREA] Determiná si la variación es regresión, drift o ruido, y proponé
la cadencia y las alertas de monitoreo.
[RESTRICCIONES] No concluyas "drift" sin evidencia de cambio en la distribución
de entrada. Distinguí explícitamente causa de correlación.
[RAZONAMIENTO] 1) Compará baseline vs. producción. 2) Clasificá la variación.
3) Justificá con la evidencia disponible. 4) Definí umbrales de alerta.
[SALIDA] JSON: {clasificacion, evidencia, cadencia_monitoreo, alertas[], supuestos[]}
[INCERTIDUMBRE] Indicá qué no puede decidirse sin más datos de producción.Input que requiere: métricas de línea base del despliegue, métricas de producción en ventanas recientes y registro de cambios conocidos en entradas o reglas de negocio.
Output esperable: un JSON que clasifique la variación (regresión / drift / ruido) respaldada en evidencia, con una cadencia de monitoreo periódico y alertas definidas. Señal de buen resultado: el modelo no afirma «drift» sin evidencia de cambio en la distribución de entrada y separa causa de correlación.
Framework 3 — Reestimación de esfuerzo y riesgo
¿Cuándo aplicarlo en el Sprint?
Estimación inicial en Refinamiento / Planificación; reajuste en el Scrum diario cuando aparecen bloqueos o nuevos datos; y balance en la Retrospectiva. Se re-ejecuta cada vez que cambia la disponibilidad de datos de referencia o se detecta drift (enlaza con el Framework 2).
Prompt (scaffold):
[ROL] Actuá como test manager que estima esfuerzo y riesgo de prueba
en ausencia de oráculo determinista.
[OBJETIVO] Reestimar esfuerzo y riesgo considerando la dependencia de datos
de referencia y de revisión humana.
[CONTEXTO] Sin oráculo automático, parte de la verificación es manual.
[ENTRADAS]
<<<alcance>>> {historias/criterios de esta iteración}
<<<recursos>>> {datos de referencia y capacidad de revisión humana disponibles}
<<<estimacion_previa>>> {estimación anterior, si existe}
[TAREA] Reestimá esfuerzo y nivel de riesgo residual, explicitando el peso
de la revisión humana.
[RESTRICCIONES] No asumas automatización total. Toda estimación debe declarar
sus supuestos de datos y de disponibilidad de revisores.
[RAZONAMIENTO] 1) Separá lo automatizable de lo que requiere juicio humano.
2) Estimá cada parte. 3) Derivá riesgo residual. 4) Contrastá con la estimación previa.
[SALIDA] Tabla: | Elemento | Esfuerzo (auto) | Esfuerzo (humano) | Riesgo residual | Supuesto |
[INCERTIDUMBRE] Marcá los ítems cuya estimación es más frágil y por qué.Input que requiere: alcance de la iteración, inventario de datos de referencia y capacidad real de revisión humana, y la estimación previa si la hubiera.
Output esperable: una tabla que separe esfuerzo automatizable del que exige juicio humano, con riesgo residual y supuestos por ítem. Señal de buen resultado: la estimación crece de forma justificada donde falta oráculo determinista y no oculta la dependencia de revisión humana.
Cierre conceptual
Los tres frameworks comparten la misma estructura de nueve bloques y se aplican a eventos concretos del Sprint: los criterios probabilísticos en el Refinamiento, la regresión/drift como monitoreo continuo aplicado en la Revisión, y la reestimación como actividad viva desde la Planificación hasta la Retrospectiva. El bloque de incertidumbre es transversal y obliga a declarar lo que no se puede determinar.
Si te interesa este tema u otros relacionados con test management, project management e inteligencia artificial generativa aplicada a estas áreas, puedes seguirme por mis canales, y contactarme por DM desde LinkedIn por cualquier consulta que tengas:
