El cambio hacia las pruebas asistidas por IA

Los desarrolladores usan IA para escribir código. Los equipos de producto la usan para convertir ideas en requisitos. Los testers la usan para generar escenarios, analizar defectos y mantener viva la automatización. La oportunidad es bastante real: le quita trabajo repetitivo a un equipo pequeño y le permite cubrir más terreno.

El problema es que producir más actividad de pruebas y lograr mejor calidad no son lo mismo, y es fácil comprar lo primero creyendo que compró lo segundo. Hoy se genera software más rápido de lo que un equipo alcanza a entenderlo con seguridad, lo cual carga más peso sobre la disciplina en lugar de menos.

Pruebas asistidas por IA es usar IA para apoyar un proceso de QA que usted ya tiene: generar ideas de prueba, redactar automatización, resumir logs, agrupar defectos, producir datos sintéticos.

Probar sistemas de IA es probar un producto que a su vez corre sobre aprendizaje automático o IA generativa. Eso exige técnicas adicionales, porque las salidas son probabilísticas y se mueven con los datos y con el contexto. Alucinación, fundamentación en la fuente, inyección de prompts, fuga de datos y consistencia entre ejecuciones repetidas pasan todas a ser cosas que hay que probar.

La distinción importa porque los controles son distintos. Un caso de prueba redactado por IA solo necesita la revisión que recibe cualquier caso. Probar un asistente de IA necesita bastante más que eso.

Para el primer cambio, lo útil es tener clara la repartición de responsabilidades:

Empiece por una tarea repetitiva que ya entienda bien: redactar escenarios a partir de requisitos estables, encontrar huecos en un paquete de regresión, resumir logs. Ese trabajo es fácil de revisar y fácil de deshacer. Un agente autónomo con permiso para cambiar ambientes no es ni lo uno ni lo otro.

1. ¿Qué problema resuelve, y cómo vamos a medir la mejora?
2. ¿Qué datos recibe, dónde se procesan y quién puede acceder a ellos?
3. ¿Podemos revisar, reproducir y auditar su salida?
4. ¿Qué pasa cuando se equivoca, no está disponible o miente con seguridad?
5. ¿Qué permisos tiene, y se pueden limitar?

Para cualquier herramienta, cinco preguntas suelen bastar para separar un producto de una demostración:

Las herramientas de IA piden requisitos, código, logs, datos de prueba, capturas y tickets. Enterrados en ese material hay credenciales, datos personales, condiciones comerciales y la forma de los sistemas de un cliente. Acuerde una política de uso antes del primer piloto, que cubra qué herramientas se aprueban, qué datos no pueden acercarse a ellas, quién es dueño de las cuentas, cuánto se retiene y cómo se reporta una sospecha de exposición.

Después aplique privilegio mínimo. Un asistente que redacta una prueba no tiene por qué cambiar datos, editar un repositorio ni desplegar nada. Empiece en solo lectura. Trabaje en ambientes de prueba con datos sintéticos o enmascarados. Nunca deje que un agente se acerque a producción o al sistema de un tercero sin autorización escrita.

Cuando el producto que se prueba es en sí mismo de IA, el top diez de OWASP GenAI sirve como lista de chequeo para empezar: inyección de prompts, divulgación de información sensible, cadena de suministro y envenenamiento de modelos, manejo indebido de salidas, exceso de autonomía.

«Humano en el circuito» no es un control salvo que esa persona tenga tiempo para mirar en serio, información para juzgar y posición para estar en desacuerdo sin que le cueste. Un revisor que aprueba cientos de casos generados sin leerlos es un sello de goma, y en general todos en la sala lo saben.

Arme la supervisión alrededor de los puntos de decisión. Las salidas de bajo riesgo, como ideas, resúmenes y clasificaciones, se pueden revisar por muestreo en vez de leerlas línea por línea. Todo lo que identifique un riesgo que bloquea una salida necesita que decida una persona con experiencia, con la evidencia conservada. Todo lo que toque producción, clientes o a un tercero necesita autorización escrita y aprobación explícita, sin ninguna acción autónoma.

Un equipo de QA debería poder decir sin dudar quién aprueba un resultado generado por IA, quién lo puede revertir y en qué punto se detiene el trabajo. Una cosa más que vale la pena hacer: siempre que pueda, mantenga separado el sistema que genera la salida del que la evalúa.

El caso de negocio creíble nunca fue que la IA reemplace al equipo. Es que un equipo con criterio dedique menos de su semana al trabajo repetitivo y más al riesgo y a la exploración.

Esas ganancias son reales, y no son automáticas. La investigación de DORA sobre desarrollo asistido por IA habla de gestionar una caída de productividad durante la adopción. Un estudio aleatorizado de METR con 16 desarrolladores open-source experimentados sobre 246 incidencias reales encontró que permitir el uso de IA hizo que las tareas tomaran 19% más tiempo en promedio en ese contexto. Un estudio en una configuración no prueba que la IA frene a todos los equipos. Sí es una razón decente para medir su propio flujo en vez de confiar en la promesa de un proveedor, o en su propia impresión de qué tan rápido se siente todo.

Así que mida el ciclo completo y no el paso de generación. Tiempo de diseñar, ejecutar, analizar y mantener. Defectos que se escapan, falsos positivos y las correcciones hechas en revisión. Cobertura de los recorridos que importan. Costo con el tiempo de revisión y el retrabajo contados. Si la IA ahorra treinta minutos de redacción y genera una hora de revisión, le costó media hora.

Los equipos que salgan bien parados de esto no serán los que compraron más herramientas. Serán los que conocían sus riesgos, formaron a su gente, mantuvieron sus datos donde debían estar, contrastaron las salidas de IA con evidencia y dejaron el criterio humano en los puntos donde contaba.

Úsela para bajar el trabajo repetitivo y para sacar a la superficie patrones difíciles de ver a mano. No deje que la velocidad ocupe el lugar del entendimiento, y no confunda una salida impresionante con una confiable. La idea es ampliar lo que el equipo alcanza a cubrir, no entregarle a otro la responsabilidad por la calidad.

• NIST AI Risk Management Framework — https://www.nist.gov/itl/ai-risk-management-framework
• OWASP GenAI Security Project, Top 10 para aplicaciones con LLM e IA generativa — https://genai.owasp.org/llm-top-10/
• ISTQB Certified Tester AI Testing (CT-AI) — https://istqb.org/certifications/certified-tester-ai-testing-ct-ai/
• METR, medición del impacto de la IA de principios de 2025 en la productividad de desarrolladores open-source — https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/
• DORA, el retorno del desarrollo asistido por IA — https://dora.dev/ai/