Ser finalista no equivale a ganar
a1qa informó en octubre de 2025 que fue preseleccionada como finalista en Best Test Automation Project (Functional) y AI Driven Automation. En esa comunicación, la empresa atribuye a sus prácticas más velocidad, menos esfuerzo manual y menores costos; son afirmaciones de la compañía sobre su trabajo, no mediciones independientes publicadas con un grupo de comparación.
La página oficial de ganadores de North American Software Testing Awards 2025 registra a Infosys – Healthcare project como ganador de AI-Powered Quality Assurance, una categoría distinta de AI Driven Automation. a1qa fue finalista en esta última, no ganadora de aquella. Finalista es un reconocimiento, pero no equivale al premio ni valida por sí solo una tasa de reducción de riesgos o costos.
Los premios, las conferencias y los casos de proveedores muestran en qué áreas se está probando la IA: diseño de pruebas, análisis de defectos, automatización visual, preparación de datos y evaluación de sistemas de IA. El World Quality Report 2025–26, elaborado por Capgemini, Sogeti y OpenText, dice que 89% de las organizaciones encuestadas estaba probando o usando IA generativa en calidad de software. Solo 15% había extendido su uso a toda la empresa.
El informe también indica que las organizaciones que reportaron resultados observaron, en promedio, un aumento de productividad del 19%; un tercio dijo que las mejoras fueron pequeñas. Como la encuesta fue elaborada por empresas del sector, sirve para conocer lo que estas organizaciones reportan, pero no garantiza el mismo resultado en todas las empresas ni funciona como una comparación independiente.
Cómo evaluar una promesa de aceleración
Pide una comparación clara: ¿qué etapas de la entrega se hicieron más rápidas?, ¿qué gravedad tenían los defectos medidos?, ¿se contó el tiempo de revisión, mantenimiento de pruebas e incidentes?, ¿cuántos proyectos se analizaron y durante cuánto tiempo?, ¿quién reunió los datos? Solicita cantidades y proporciones, no solo porcentajes generales, y separa el tiempo ahorrado al ejecutar pruebas del costo de integrar y supervisar la herramienta.
Una prueba controlada útil identifica una tarea acotada, criterios de éxito previos, datos que puede procesar el agente, mecanismo para detenerlo, revisión independiente y costo total de propiedad. Sin esos elementos, el caso sirve como inspiración, no como pronóstico financiero para tu equipo.
En un caso publicado sobre pruebas de regresión para una empresa minorista, a1qa describe un conjunto de unas cinco mil pruebas y una primera etapa limitada a una parte del producto. Según la empresa, el tiempo para decidir si una versión podía publicarse bajó de unas dos semanas a cinco días hábiles o menos. También informa que preparar algunas pruebas convertidas tomó más de 30% menos tiempo. La IA ayudaba a proponer pruebas desde los requisitos, encontrar huecos, preparar datos ficticios y clasificar fallos; una persona aprobaba las pruebas antes de incorporarlas.
El caso resulta más informativo que un porcentaje aislado porque explica qué parte del trabajo se cambió y cómo. Aun así, lo publicó el proveedor y no es una evaluación independiente ni una garantía de que otros equipos obtengan lo mismo. Para compararlo con otro proyecto, habría que saber qué pruebas se midieron, cuánto tiempo de revisión se incluyó y qué pasó con los defectos que llegaron a producción y el mantenimiento posterior.
Una ficha de evaluación que sirve para compras y pruebas controladas
Pide cinco datos para poder comparar: qué incluyó el proyecto y qué dejó fuera; cómo era la situación inicial y cuánto duró la medición; qué significan “ahorro” y “defecto”; cuánto costó todo, incluida la revisión de personas; y qué pasó con la seguridad, la estabilidad y el mantenimiento en las siguientes versiones. Elige una tarea con un resultado esperado claro y compara el proceso actual con el asistido usando ejemplos equivalentes. Decide de antemano qué resultado haría que amplíes, corrijas o detengas la prueba inicial.
El reconocimiento externo puede ayudar a encontrar equipos que experimentan y preguntas que vale la pena hacer. La decisión de adopción, sin embargo, necesita evidencia de tu propio producto: resultados reproducibles, menos riesgo relevante o menor costo total sin trasladar trabajo invisible a QA, desarrollo u operaciones.
Un premio puede demostrar que una candidatura fue evaluada y reconocida dentro de una categoría, edición y jurado concretos. Sirve para descubrir proveedores, técnicas o proyectos que vale la pena estudiar. No demuestra automáticamente que la solución sea superior a todas las alternativas, que el resultado se repita en otros equipos ni que el retorno compense el costo. La categoría exacta importa: “AI Driven Automation”, “AI-Powered Quality Assurance” y “test automation” no son sinónimos. Antes de usar una insignia como evidencia, confirma si la empresa fue finalista o ganadora, cuál fue la categoría oficial y a qué proyecto se otorgó.
También conviene separar el premio del caso operativo. Una empresa puede tener un reconocimiento válido y publicar una historia comercial con beneficios reales, pero esos beneficios seguirían necesitando alcance, periodo y método. Los porcentajes de productividad no aclaran qué actividad se midió, si incluye preparación y revisión, ni qué ocurrió con defectos en producción. Una nota rigurosa presenta la afirmación como lo que es —por ejemplo, “el proveedor reporta”— y no la convierte en un hecho independiente. Esa distinción protege al lector y hace que la comparación sirva para decidir, no para repetir un titular.
Leer el caso de a1qa como una hipótesis que se puede comprobar
El caso publicado por a1qa sobre regresión para retail describe un inventario de miles de pruebas y una fase inicial acotada. La compañía reporta que la decisión de release pasó de alrededor de dos semanas a cinco días hábiles o menos, y que preparar algunos casos convertidos requirió más de 30% menos tiempo. También describe sugerencias de pruebas desde requisitos, búsqueda de huecos, datos ficticios y clasificación de fallos, con aprobación humana. Es más informativo que una frase genérica porque dice qué tareas cambió; sigue siendo un caso redactado por el proveedor y no muestra un grupo de comparación independiente.
Para trasladar esa experiencia a tu equipo, pregunta qué tipos de pruebas entraron, cuántas se transformaron, cuánto tiempo humano se contó y qué proporción necesitó corrección. Revisa si la mejora duró varios releases, si cambiaron el equipo o las reglas de aceptación y si el defecto escapado se mantuvo estable. Solicita ejemplos de resultados fallidos además de los éxitos. Si el proveedor no puede compartir datos por confidencialidad, puede describir metodología agregada o permitir una prueba controlada en datos controlados; no hace falta divulgar código sensible para aclarar qué se midió.
Antes de una prueba controlada, escribe una ficha de una página con el problema, la población de casos, la línea base y la decisión que tomarás. Define una muestra representativa con flujos frecuentes y casos de alto riesgo; no dejes que el proveedor elija solo los ejemplos donde su herramienta luce mejor. Ejecuta el proceso actual y el asistido con reglas comparables. Registra precisión de hallazgos, cobertura de riesgos, casos duplicados, esfuerzo de configuración, triage, mantenimiento y tiempo total. Separa licencias, consumo de modelos, infraestructura, soporte y costo interno de revisión.
Acordá umbrales de éxito y de parada antes de ver los resultados. Una prueba controlada puede fallar por un mal encaje de herramienta, contexto insuficiente, límites de seguridad o integración; esas causas no son equivalentes. Si mejora la velocidad pero suben los defectos graves o el trabajo de mantenimiento, el balance no es positivo. Si un premio motiva a mirar un producto, bien; la compra debe depender de evidencia reproducible en tus propios procesos y de una salida que permita exportar los datos y desactivar la solución sin dejar el equipo bloqueado.
Qué preguntar en una demostración de software del proveedor
Durante una demostración, pide seguir un cambio desde el requisito hasta el resultado, no solo mirar una pantalla que genera pruebas. ¿Qué versión del producto se está probando? ¿De dónde salió cada criterio? ¿Puede el sistema mostrar por qué considera que una ejecución falló? ¿Qué ocurre si una página tarda o cambia? ¿Cómo se separa una falla del ambiente de un defecto? ¿Puede una persona revisar y corregir la propuesta antes de guardarla? Estas preguntas revelan si la herramienta encaja en el trabajo cotidiano o si el ejemplo depende de datos preparados de antemano.
Comprueba además la salida y la portabilidad. Solicita exportar casos, resultados y evidencia en formatos que tu equipo pueda conservar; pregunta quién tiene acceso a los datos, cuánto tiempo se guardan y cómo se eliminan al terminar la prueba controlada. Revisa qué ocurre si cambia el proveedor o se cancela la licencia. Un reconocimiento ayuda a encontrar una empresa para conversar, pero una evaluación útil incluye condiciones de uso, límites operativos, responsabilidades y un plan de salida. La decisión final debería poder justificarse incluso si el premio deja de ser noticia.
El mismo criterio sirve para leer anuncios de mercado. Una lista de finalistas indica que hubo postulaciones y una evaluación según reglas determinadas; no indica cuántas soluciones participaron ni cómo se comportaron las candidaturas que no recibieron mención. La página de ganadores permite verificar el resultado oficial, mientras que el proveedor puede aclarar qué parte de su producto o proyecto presentó. Cada documento responde una pregunta distinta. Contrastarlos evita confundir la reputación de una empresa con la validación independiente de todas sus cifras comerciales.