Testing automatizado con IA, primer significado: IA que automatiza tus pruebas
Cobertura generada a partir de tu producto, pasos expresados como intenciones para que los cambios cosméticos no los rompan, fallos devueltos en un formato que quien los corrige pueda aprovechar. El software bajo prueba es convencional y determinista; la IA está en las herramientas.
Esto es lo que hace la mayoría de los productos de la categoría, y es lo que necesita la mayoría de los equipos.
Segundo significado: probar un sistema que contiene IA
Aquí el producto en sí no es determinista. La misma entrada produce salidas distintas, así que «lo esperado es igual a lo real» deja de estar disponible y necesitas otro tipo de aserción.
Propiedades, no igualdad
Comprueba que la salida tenga la forma correcta, cite una fuente, respete la longitud y rechace lo que debe rechazar.
Distribuciones, no ejecuciones
Una sola ejecución no te dice casi nada. Ejecuta muchas y haz seguimiento de la tasa.
Regresión, no valores absolutos
La pregunta es si este cambio lo empeoró, no si es perfecto.
El error común a ambos
Dar por hecho que una comprobación en verde significa algo sin haber confirmado nunca que esa comprobación puede fallar. En el caso determinista, eso produce suites de pruebas llenas de aserciones que nunca podrían ponerse en rojo. En el caso no determinista, produce arneses de evaluación que puntúan alto cualquier cosa.
Rompe algo a propósito. Un minuto, y es la única evidencia de que cualquiera de los dos tipos de comprobación está conectado con aquello que dice medir.
Trazar el límite en un producto mixto
La mayoría de los productos que contienen IA no son IA en su mayor parte, y lo útil es trazar la línea de forma explícita en lugar de dejar que el no determinismo se extienda.
Todo lo que rodea a la funcionalidad es software convencional: la autenticación, el almacenamiento, los límites de tasa, la interfaz que renderiza la salida. Todo eso se prueba de forma convencional, y tratar el producto entero como impredecible porque uno de sus componentes lo es te hace perder mucha cobertura barata y fiable.
Dentro del límite, pasa a propiedades y tasas. Metes la entrada, la salida varía, y lo que compruebas es que tenga la forma correcta, que cite algo real y que rechace lo que debe rechazar. Dejar escrito, una sola vez, dónde está ese límite es lo que evita que un equipo acabe probando de más las partes deterministas con métodos estadísticos o probando de menos la parte de IA porque las aserciones exactas no dejaban de fallar.
¿Cuál de los dos tienes?
Si tu producto daría la misma respuesta dos veces, estás en el primer caso y lo que quieres es cobertura generada contra la aplicación en ejecución. Si no, estás en el segundo y necesitas aserciones basadas en propiedades y tasas, en lugar de un simple pasa o falla.
Muchos productos son las dos cosas: una aplicación determinista con una funcionalidad de IA dentro. Prueba las partes deterministas de la forma habitual y trata la funcionalidad de IA como un problema aparte, en vez de estirar un mismo enfoque para cubrir ambas.
Terminal
npm install -g @testsprite/testsprite-cli
testsprite setup
El panel cubre lo mismo para quien no quiera una instalación local, y el conjunto completo de comandos está en el repositorio del CLI.
Dos caminos, y la elección depende en realidad de quién es dueño del pipeline. Conectar la GitHub App desde el panel no requiere ningún cambio en tu repositorio, porque reacciona al despliegue que tu build ya emite. Añadir un paso de GitHub Actions pone la comprobación en el repo, donde se revisa igual que el resto del build.
El significado que cubre TestSprite
El primero. Usa IA para verificar software convencional: cobertura generada a partir de tu producto, pasos expresados como intenciones, ejecución contra la aplicación desplegada y un fallo devuelto en un formato sobre el que un agente de programación puede actuar.
En un producto que contiene una funcionalidad de IA, eso cubre todo lo que la rodea, que es la mayor parte del producto: autenticación, almacenamiento, limitación de tasa, la interfaz, los flujos que el usuario recorre de verdad. Auto-Authentication, Dynamic Variables, Dependency Chains y Auto-Cleanup se encargan de los problemas de estado del lado de la API.
La funcionalidad en sí necesita aserciones basadas en propiedades y tasas, lo que supone un arnés distinto. Trazar ese límite de forma explícita es lo que te permite obtener cobertura barata y fiable sobre la mayoría determinista, en lugar de tratar el producto entero como impredecible.
¿Cuál de los dos hace TestSprite?
El primero. Verifica el comportamiento determinista de la aplicación contra el producto en ejecución, incluidas las aplicaciones que además contienen funcionalidades de IA.
¿Cómo probamos una funcionalidad de LLM?
Aserciones basadas en propiedades ejecutadas muchas veces, con seguimiento de tasas en lugar de resultados sueltos. Los rechazos, el formato y la presencia de citas suelen ser más comprobables que la calidad de la respuesta.
¿Puede la misma suite cubrir ambos casos?
Las partes deterministas, sí. La funcionalidad no determinista necesita su propio arnés, con su propia noción de resultado aprobado.
¿Qué tasa de aprobación es razonable para una funcionalidad de IA?
La que tuvieras antes. Los objetivos absolutos tomados de benchmarks rara vez se trasladan a tu producto.
¿Una sola ejecución fallida es un bug?
Por sí sola no, en una funcionalidad no determinista. La señal es una tasa que se movió; una sola ejecución es ruido.
Dos temas, una misma expresión.
El testing automatizado con IA significa o bien IA que prueba tu software, o bien probar software que contiene IA. Lo primero pide cobertura generada contra la aplicación en ejecución; lo segundo, propiedades y tasas. Ambos necesitan comprobaciones de las que hayas confirmado que pueden fallar.