CabraFlow · De la demo comentada a la prueba automatizada, en diseño
CabraFlow es un proyecto en diseño que pretende generar una prueba automatizada a partir de una demostración comentada en voz alta: usted mostraría su proceso de negocio en la aplicación y la prueba se escribiría en microfrases de negocio, reproducible en Playwright o en Robot Framework. A 6 de octubre de 2026 existen seis especificaciones, redactadas el 12 de agosto de 2026; no hay ninguna línea de código, ningún prototipo ni ninguna demostración.
El callejón sin salida del mantenimiento de las pruebas de interfaz
El problema que CabraFlow quiere resolver: los enfoques actuales imponen un compromiso entre la fragilidad de las pruebas y la complejidad de escribirlas.
Selectores muertos y scripts desechables
Los grabadores tradicionales fijan rutas CSS o XPath. Ante el menor cambio en el DOM, en un identificador o en la maquetación, las pruebas se rompen, y el tiempo se va en repararlas en lugar de validar la aplicación.
Fractura entre el negocio y el código
Escribir Playwright puro, o cualquier otro framework de pruebas en TypeScript, exige competencias de desarrollo. Los expertos funcionales, que conocen la lógica de negocio, no pueden ni escribir ni revisar estas pruebas.
Formatos cerrados y licencias por puesto
Las suites de pruebas propietarias suelen guardar las pruebas en formatos cerrados, difíciles de versionar en Git y de reutilizar en otra herramienta, con licencias facturadas por puesto.
Seis decisiones de diseño, recogidas en las especificaciones
Lo que CabraFlow está diseñado para hacer. Son intenciones escritas, no funciones disponibles: ninguna está implementada todavía.
Captura por voz y por gestos
El modo previsto generaría una prueba automatizada por voz: usted navegaría comentando sus acciones y el flujo se escribiría a medida que avanza la demostración. La transcripción sería local (se contempla el motor Whisper). Este modo solo se construirá después de un ensayo con criterios cuantificados.
Árbol de accesibilidad
Los destinos se resolverían por sus roles y nombres accesibles, tal como los percibe un lector de pantalla, con los localizadores orientados al usuario de Playwright. El lenguaje de prueba está diseñado sin selectores CSS ni XPath.
Microfrases de negocio
El lenguaje visible estaría hecho con las palabras de su organización («Validar el pedido urgente»), creadas durante la captura, nunca con un vocabulario de herramienta ni con código.
Reproducción en tres destinos
Un mismo flujo YAML está diseñado para ejecutarse en un runner nativo y exportarse como script de Playwright (.spec.ts) o como suite de Robot Framework (.robot). El archivo YAML seguiría siendo la única fuente.
Exportación documental ISTQB
El mismo flujo produciría una especificación de casos de prueba (pasos, resultados esperados, trazabilidad mediante etiquetas), regenerada desde la fuente en lugar de reescrita a mano.
Local por diseño
La inferencia del modo de voz está prevista íntegramente en local, sin API en la nube: la voz y los datos de pantalla permanecerían en su equipo. Sin tarjeta gráfica, se prevé un modo de «voz diferida».
El bucle previsto: del gesto de negocio a la prueba reproducible
El esquema muestra cómo CabraFlow transformaría una demostración en una prueba Playwright o Robot Framework, según las especificaciones. Describe una intención de diseño: nada está construido ni medido todavía.
Tres puertas de entrada previstas, un solo archivo fuente
Están previstas tres formas de crear una prueba, cada una en una fase distinta del plan. Todas llevarían al mismo archivo YAML versionable.
Demostración por voz
Abriría la aplicación y hablaría con naturalidad («Selecciono el perfil del cliente y después valido el presupuesto»); los bloques de palabras clave se añadirían a medida que navega. Previsto en la fase 4, tras un ensayo con criterios cuantificados.
Estudio gráfico
Ensamblaría y parametrizaría las microfrases de negocio en un estudio visual: variables tipadas, conjuntos de datos, ensayo aislado de una palabra clave. Previsto en la fase 3.
Archivo de texto y Git
Editaría el archivo YAML en su editor, con autocompletado proporcionado por un esquema JSON, y podría consultar el código Playwright generado. Previsto desde la fase 1, la primera etapa ejecutable.
Previsto para los agentes de IA (MCP): la captura, la reproducción y la reparación están diseñadas para exponerse mediante el estándar abierto Model Context Protocol (MCP), de modo que un agente pueda pilotar el bucle como un probador humano. Previsto en la fase 2; hoy no hay nada expuesto.
Ni bifurcación ni reinvención
CabraFlow está diseñado como un orquestador sobre Playwright, no como una bifurcación. Tomaría de Robot Framework el principio keyword-driven y la composición, y de Playwright el motor de ejecución y los localizadores orientados al usuario.
Los flujos están diseñados para exportarse a Playwright o a Robot Framework, de modo que un equipo no dependa de un formato propio de CabraFlow.
En qué punto está el programa de I+D
A 6 de octubre de 2026, CabraFlow está en la fase 0: seis especificaciones redactadas el 12 de agosto de 2026 (visión, arquitectura, lenguaje de palabras clave, modo de voz, plan de realización, diseño del estudio). Ninguna línea de código, ningún prototipo, ninguna demostración.
Describimos el estado real, en el presente de la fase en curso: no se anuncia ninguna cifra de rendimiento antes de haberla medido, y no se mostrará nada antes de que la fase 1 sea ejecutable.
Lo que existe, lo que vendrá y con qué condición
El plan de realización avanza por fases, y cada una debe aportar algo utilizable por sí solo. Solo está hecha la primera parte de la fase 0.
Las especificaciones
Seis especificaciones redactadas el 12 de agosto de 2026. Quedan por crear el repositorio de código y la integración continua, y por elegir el nombre del paquete.
El núcleo ejecutable
Un motor de línea de comandos que ejecuta un flujo YAML sobre una pequeña aplicación de demostración local, sin ningún selector en las pruebas. Criterio de salida: un perfil técnico-funcional escribe un flujo con autocompletado y lo ejecuta. Es la condición para cualquier primera demostración.
Agentes MCP y reparación
El bucle expuesto a los agentes mediante MCP, la exportación a Playwright (.spec.ts) y una reparación propuesta ante un fallo, siempre señalada en el informe, nunca una prueba en verde en silencio.
El estudio gráfico
Una aplicación de escritorio para ensamblar las microfrases de negocio en bloques, sincronizados con el archivo YAML, con un ejecutor integrado. El estudio de esta fase no incluirá el modo de voz.
El modo de voz, tras un ensayo cuantificado
Primero, un ensayo sobre diez demostraciones comentadas grabadas. El modo de voz solo se integrará si más del 85 % de los pasos son correctos sin corrección manual y si la latencia percibida se mantiene por debajo de 2 s. Estos umbrales todavía no se han medido.
Ecosistema
Exportación a Robot Framework (.robot), exportación documental ISTQB, ejecución en integración continua y bibliotecas de palabras clave compartibles.
Estado del proyecto y alcance
Diseñar la transformación de una demostración comentada en pruebas Playwright o Robot Framework. Revisado el 6 de octubre de 2026. Balance interno de I+D, sin validación independiente ni resultado de cliente reivindicado.
- Fase 0: especificaciones Seis especificaciones redactadas el 12 de agosto de 2026; ninguna línea de código, prototipo ni demostración a 6 de octubre de 2026. El modo de voz espera un criterio cuantificado (más del 85 % de pasos correctos, menos de 2 s de latencia), todavía sin medir. Repositorio interno, estado del 06/10/2026
Hablemos de su cadena de pruebas automatizadas
Cuéntenos en qué punto están sus retos de automatización de interfaces (fragilidad de los selectores, implicación de los equipos de negocio, mantenimiento). Sus casos concretos nos ayudan a contrastar el diseño de CabraFlow con necesidades reales; todavía no hay ningún prototipo que probar.
- Un intercambio técnico, no comercial
- Sus datos permanecen en Francia