Qué cambia la IA en pruebas y qué no

Uno suele escuchar dos versiones de esto. Una dice que la IA no cambia nada en pruebas, que un modelo generando casos verosímiles es un truco de salón. La otra dice que el tester se acabó y que QA hoy es una licencia de software. Ninguna coincide con lo que vemos en los proyectos. La división que sí ayuda es entre las partes de las pruebas que se repiten y las partes en las que alguien tiene que decidir algo.

La parte repetitiva es donde se va la mayoría de las horas. Redactar el primer borrador de cien casos a partir de un documento de requisitos. Reescribir un defecto para que desarrollo pueda actuar sobre él. Comparar este ciclo con el anterior. Darse cuenta de que un área entera del producto no tiene cobertura. Es trabajo con patrón, y hacerlo bien es en buena medida cuestión de hacerlo de forma consistente.

La otra parte consiste en decidir cosas. Que un flujo importa más de lo que sugieren los requisitos, por cómo lo usan los clientes de verdad. Que un defecto de apariencia menor es el que va a obligar a devolver la versión. Que algo no está listo, en una fecha que ya se anunció. Nada de eso se repite de forma útil. Sale de conocer el producto y de haberse equivocado antes en algo parecido.

La IA es buena en lo primero. Lo segundo no lo hace en absoluto.

• Primeros borradores de casos a partir de un requisito o una historia, que después un tester edita, recorta y reordena
• Triage de defectos: agrupar duplicados, proponer severidad, ordenar los pasos de reproducción en algo accionable para desarrollo
• Análisis de cobertura: señalar las áreas del producto donde no se ha ejercitado nada
• Mantenimiento de suites automatizadas, cuando un cambio en la aplicación rompe un lote de scripts de la misma forma
• Resumir un ciclo largo en algo que un stakeholder de verdad vaya a leer

• La decisión de salida. Listo, listo con riesgos conocidos o todavía no: eso trae consecuencias, y lo tiene que firmar una persona
• Definir qué es lo más importante del producto: eso sale del negocio y de sus stakeholders, no de un modelo leyendo el backlog
• Pruebas exploratorias, donde el valor está justamente en seguir una corazonada que ninguna especificación describe
• Cualquier cosa que implique mandar sus datos de producción o su código a un lugar al que no deben ir

Preguntarle a un proveedor si usa IA dejó de ser informativo más o menos cuando todos empezaron a responder que sí. Funcionan mejor las preguntas angostas. ¿Qué pasos toca? ¿Qué revisa una persona antes de que algo le llegue a usted? ¿A dónde van sus datos? ¿Quién firma que una versión está lista, y sobre qué base?

Un proveedor que puede responder eso está supervisando la herramienta. Uno que no puede, o bien no la usa o bien no está mirando lo que hace, y a usted le conviene saber cuál es el caso antes de firmar nada.

De nuestro lado, la usamos en generación de casos, triage y análisis de cobertura, donde baja el mantenimiento. Si algo está listo para salir lo decide una persona, siempre, y puede explicar esa decisión sin remitirse a un modelo.