En casi todos los proyectos de software hay un momento incómodo que se repite. El equipo de QA empieza a diseñar las pruebas y descubre que el requerimiento no está tan claro como parecía.
La historia de usuario dice una cosa, el documento funcional matiza otra y el diseño técnico asume una tercera. Alguien tiene que decidir cuál es la correcta, y muchas veces esa conversación ocurre cuando el código ya está escrito.
Este artículo cuenta cómo dos analistas de nuestro equipo abordaron ese problema con una idea simple, y por qué el resultado más importante no fue el que esperaban.
El problema: probar sobre artefactos que no coinciden
En el modelo tradicional, QA trabaja al final de la cadena. Recibe la historia de usuario y los documentos que la acompañan, y a partir de ellos tiene que:
- Analizar la historia y entender qué se espera.
- Identificar qué escenarios se pueden probar y automatizar.
- Diseñar los casos de prueba.
- Armar la planilla de estrategia.
- Cargar los casos en la herramienta de automatización, ejecutarlos y revisar los resultados.
Todo a mano, y casi siempre con una persona dedicada por completo durante el proceso.
El trabajo es pesado, pero ese no es el problema de fondo. El problema es que QA diseña pruebas a partir de artefactos que a veces no coinciden entre sí. Cada documento se escribió en un momento distinto, por una persona distinta, con una interpretación distinta. Y cuando hay alto volumen de historias y presión por entregar, dos cosas pasan casi siempre:
- Quedan escenarios sin cubrir, porque no hay una forma sistemática de extraerlos desde el requerimiento.
- Los casos se corrigen una y otra vez, por errores de redacción, formato o interpretación.
En ese contexto, incluso una herramienta de automatización de pruebas puede sentirse como una carga más en lugar de una ayuda.
La hipótesis: si la especificación es precisa, las pruebas también pueden serlo
GenDEV, el agente de especificación de nuestra Suite Loica, se diseñó para una tarea concreta: convertir una idea de negocio en una especificación técnica validada contra el código real del cliente, con el contexto completo y no una parte de él.
Flor y Nicol, analistas de QA de nuestro equipo, conocen el proceso de certificación en detalle y saben dónde están sus puntos débiles. Su hipótesis fue directa:
Si GenDEV produce especificaciones con ese nivel de precisión, esa misma precisión debería servir para diseñar las pruebas que después ejecuta GenQA.
Dicho de otra forma: en lugar de que QA reinterprete el requerimiento desde cero, las pruebas nacen del mismo artefacto que usa el resto del equipo.
Lo probaron en un piloto para una empresa de distribución eléctrica, con funcionalidades reales como formularios y emisión de boletas.
Cómo funciona el flujo, paso a paso
El flujo conecta las dos mitades de la suite, el diseño en GenDEV y la ejecución en GenQA, a través de una capa intermedia que consolida los artefactos. En cada paso hay una persona que revisa y aprueba antes de seguir.
-
Punto de partida. Se puede partir de un documento de requerimientos (PRD) ya aprobado o de la historia de usuario en bruto. Si el PRD no se aprueba, se itera con negocio y QA hasta que esté bien.
Control humano: el Product Owner o QA aprueba el PRD.
-
Análisis técnico y de negocio. GenDEV analiza la historia desde dos ángulos complementarios: el código y las reglas de negocio. Así identifica los escenarios que hay que probar.
Control humano: QA guía el análisis y valida las respuestas.
-
Alcance y cobertura. Se construye una matriz que muestra qué porcentaje de los criterios del requerimiento está cubierto, qué se puede automatizar en la interfaz y qué no. También se detectan datos o cuentas de prueba que faltan. La regla es que ningún criterio quede sin considerar.
Control humano: QA acepta el alcance.
-
Estrategia y planillas. Se genera la estrategia de pruebas consolidada, la planilla para el gestor de proyectos del cliente y la planilla lista para cargar en GenQA.
Control humano: QA valida los casos antes de cargarlos.
-
Ejecución y triage. GenQA importa los casos, arma la suite y la ejecuta. Cuando algo falla, se distingue entre un error real del software y un problema del ambiente de pruebas. Se ajusta y se vuelve a ejecutar hasta aprobar.
Control humano: QA decide si cada falla es un bug real o del ambiente.
El resultado es una trazabilidad de punta a punta: de la historia de usuario a la certificación, cada paso deja un artefacto y una aprobación.
El resultado esperado: menos horas de diseño
El ahorro de tiempo en el diseño de pruebas era lo previsto, y se cumplió.
Según la estimación del propio equipo, el proceso completo por caso de uso pasó de 3 a 4 horas a 2 a 2,5 horas, es decir, entre 15 % y 35 % menos de horas del analista.
Vale la pena ser precisos: es una estimación de un piloto de 5 a 10 casos, todavía no validada a volumen. Además, parte del tiempo que se ahorró en diseño se reinvirtió a propósito en revisión y validación humana en cada etapa. Nos parece la decisión correcta, porque el objetivo no es sacar a la persona del proceso, sino que su tiempo vaya a lo que requiere criterio.
El resultado inesperado: las preguntas llegan antes
Lo que no estaba en la hipótesis resultó ser lo más valioso.
Como las pruebas se diseñan desde la especificación y no desde el código terminado, las dudas empezaron a aparecer al inicio del proceso y no al final:
- ¿Qué pasa con este caso límite que la historia no menciona?
- ¿Este criterio aplica a todos los tipos de cliente o solo a algunos?
- ¿Qué datos de prueba necesitamos y existen?
Son preguntas que siempre aparecen. La diferencia está en cuándo. Descubiertas al final obligan a rehacer trabajo en plena línea de producción. Descubiertas al principio son una conversación de quince minutos.
Además, al trabajar sobre un solo artefacto que todos los equipos leen, se reduce la doble interpretación. Negocio, desarrollo y QA discuten sobre el mismo documento, no sobre tres versiones parecidas.
Dos condiciones, y ninguna sobra
Hay una lección que queremos destacar, porque va más allá de este caso: el resultado fue posible porque se juntaron dos cosas.
- Una herramienta con profundidad real: GenDEV no genera texto genérico. Razona sobre el código, la documentación y las dependencias de cada cliente. Esa base es la que permite que su resultado sirva incluso en etapas para las que no fue diseñado originalmente.
- Personas que saben qué pedirle: Ninguna inteligencia artificial descubre sola el problema que vale la pena resolver. Flor y Nicol conocían el proceso de certificación, sabían dónde dolía y formularon una hipótesis concreta. La herramienta amplificó ese conocimiento, no lo reemplazó.
Las herramientas potentes se vuelven más potentes en manos de quien se toma el trabajo de explorarlas hasta el límite.
Si quiere aplicar esta idea en su equipo
Tres preguntas para empezar, sin comprar nada:
- ¿Desde qué documento diseña pruebas su equipo de QA? Si la respuesta es “desde varios” o “desde lo que se construyó”, ahí hay un espacio claro de mejora.
- ¿En qué momento aparecen las dudas sobre el requerimiento? Revise los últimos retrabajos: si las preguntas surgieron durante la certificación, llegaron tarde.
- ¿Puede medir la cobertura de los criterios de aceptación? Si no sabe qué porcentaje de lo pedido está probado, tampoco sabe qué quedó fuera.
Lo que viene
Estamos incorporando este flujo al trabajo del equipo y ampliando el piloto a más casos, con registro formal de horas, para pasar de una estimación a una medición. La capa que conecta ambas herramientas todavía se está definiendo, y los aprendizajes de este piloto son justamente lo que la está moldeando.
Suite Loica es GenDEV más GenQA: el plano antes de programar y la revisión después. Pero este caso muestra algo más importante: cuando la especificación y las pruebas nacen del mismo lugar, el proceso completo mejora, no solo cada etapa por separado.
Si quiere ver cómo se aplicaría en su organización, le proponemos 45 minutos con nuestro equipo, sobre su código real y sin presentaciones. La primera conversación es un diagnóstico, no una demo.
