Preguntas frecuentes · Lo que más nos preguntan

SAPFX (paquete PyPI robotframework-sapfx, versión 0.8.5 publicada el 13 de octubre de 2026) es un ecosistema de código abierto para Robot Framework que opera SAP a través de tres bibliotecas: SapEccLibrary para SAP GUI para Windows, SapFioriLibrary para las aplicaciones SAP Fiori, SAPUI5 y SAP GUI for HTML (sobre Playwright) y SapApiLibrary para OData y RFC/BAPI. Sirve ante todo para automatizar pruebas SAP: las pruebas se escriben en lenguaje de negocio, sin identificadores técnicos, y una misma prueba puede recorrer varios canales. Como también sabe escribir, eliminar y contrastar lo que escribe por un segundo canal, se abre a otros usos (conjuntos de datos, bases de datos por poblar para las pruebas de rendimiento, parametrización y migración de datos), presentados como un rumbo y no como funciones entregadas. Licencia Apache 2.0. La página «SAPFX en imágenes» muestra capturas tomadas en directo y extractos de suites validadas; el vídeo «The SAPFX mindset» (11 min 11, en inglés, subtitulado en español) resume su mentalidad en siete principios.

Publicada en PyPI el 13 de octubre de 2026, aporta capacidades probadas del 7 al 13 de octubre de 2026 en S/4HANA 1909 y ABAP Platform 2023: una política de sesión que decide antes de cualquier gesto de escritura (solo lectura, exploración, completo) con una pista de auditoría; la aprobación de una escritura por una persona, ligada a un destino; un veredicto GO o NO-GO calculado sobre el archivo de resultados de una ejecución; la verificación del certificado SSL declarado en STRUST y del que el ICM sirve realmente; usuarios y roles de prueba creados y eliminados por RFC; la supervisión del registro de errores de la Gateway; el análisis de impacto de un transporte; la naturaleza de un servicio OData probada por sus marcadores, el modo Espacios y Páginas del launchpad y los fallos de autorización leídos en SU53. Cifras de la 0.8.5: 442 keywords, cada una con un ejemplo de uso, 3959 pruebas unitarias, 462 escenarios ejecutados en vivo. Detalles en la página SAPFX.

Sí. SAPFX se publica con licencia Apache 2.0: ninguna licencia que pagar, sea cual sea el número de usuarios o de puestos de ejecución, uso comercial incluido. El código fuente es público en GitHub (CyrilM29/robotframework-sapfx) y el paquete se instala desde PyPI, sin dependencia del proveedor. AI Cabra ofrece servicios de acompañamiento, migración y formación bajo presupuesto.

Tres canales: SAP GUI de escritorio (ECC, S/4HANA, mediante la API SAP GUI Scripting), la web Fiori/SAPUI5 (compatibilidad demostrada de UI5 1.71 a 2.0, incluido SAP GUI for HTML) y la API (OData v2 y v4, RFC opcional). Un mismo hecho de negocio puede verificarse por dos canales independientes en la misma suite de pruebas.

Se diseñó para probar, y ese es su núcleo. Pero lo que lo hace fiable para probar (escribir un dato, volver a leerlo por un segundo canal independiente, la pantalla por un lado y la API por otro, eliminarlo y comprobar que ha desaparecido) sirve también para otros usos: generar conjuntos de datos para las campañas de pruebas, poblar bases de datos SAP vacías o incompletas antes de las pruebas de rendimiento, cargar datos de parametrización o asegurar la inyección de datos en una migración, por ejemplo de ECC a S/4HANA. Para ser precisos sobre el estado: la escritura, la eliminación y el control cruzado están validados en directo en sistemas SAP de desarrollo; el generador de conjuntos de datos, los volúmenes de rendimiento y las cargas de migración son un rumbo, no funciones entregadas, y todavía no se ha ejecutado ninguna migración. En un sistema de cliente, cada destino se trata caso por caso, priorizando la reversibilidad.

En el perímetro que cubre (SAP GUI, SAP Fiori, WebGUI, OData y RFC, autorreparación registrada de los localizadores), SAPFX responde a la misma necesidad que las suites de pruebas comerciales del mercado, que se venden con licencia. Lo que esas suites aportan y SAPFX no tiene: un soporte del proveedor y un editor gráfico. Las pruebas de SAPFX se escriben en keywords legibles sin programar. El enfoque de SAPFX es la ausencia de licencia, la durabilidad y la apertura (Apache 2.0, Robot Framework estándar), no una crítica de su calidad.

Las bibliotecas abiertas más extendidas cubren cada una un solo canal: SAP GUI de escritorio una, la web UI5 fuera de Robot Framework la otra. SAPFX cubre los tres canales dentro de Robot Framework, con un único informe unificado. Los localizadores por etiqueta, popularizados por la biblioteca dedicada a SAP GUI, existen también en SAPFX (herencia Apache 2.0 asumida), con una diferencia de contrato: una ambigüedad siempre se señala con la lista de candidatos, nunca se resuelve en silencio.

Cuatro mecanismos: las pruebas no contienen ningún identificador técnico (los localizadores viven en una capa de recursos separada); las esperas se ajustan al estado real de SAP, nunca a pausas fijas; las aserciones leen el tipo de mensaje, no el texto traducido; y la autorreparación de los localizadores registra cada reparación, nunca en silencio.

Cinco agentes de IA planifican, generan, reparan, verifican y documentan las pruebas pilotando el sistema SAP real mediante MCP (servidor rf-mcp y plugins de SAPFX). Cada paso generado se ejecuta en vivo antes de escribirse, y el agente de reparación corrige la capa de recursos, nunca las pruebas. Nada es silencioso: una persona revisa y las reparaciones quedan registradas. Antes de escribir en SAP, un agente puede quedar sujeto a la aprobación de una persona (la herramienta MCP sapfx_approve_write del taller, apoyada en la política de sesión de las bibliotecas, publicada en la 0.8.5), y Prompt Eval puntúa la petición de prueba antes de que los agentes gasten sus tokens. Estos agentes forman parte del taller SAPFX, no del paquete PyPI; la suite que producen se reproduce solo con Robot Framework, sin ningún agente.

pip install robotframework-sapfx (Python 3.10 o posterior, Robot Framework 7.4 o posterior). La parte SAP Fiori se prueba sin ningún sistema SAP, en el Demo Kit público de OpenUI5 o en una aplicación SAP Fiori Elements servida en local; SAP GUI y las API se validan con la imagen Docker gratuita de ABAP Platform Trial. Consulte nuestra Guía de inicio y la página «SAPFX en imágenes» para ver pruebas reales.

Un entorno Python 3.10 o posterior con Robot Framework 7.4 o posterior y, después, el paquete robotframework-sapfx desde PyPI; para SAP Fiori, el extra robotframework-sapfx[web] añade la biblioteca Browser (Playwright), y el canal RFC, opcional, requiere pyrfc. Para el canal SAP GUI se añade una condición: SAP GUI Scripting debe estar activado, tanto en el servidor como en el puesto cliente. Suele ser la primera etapa de un proyecto y corresponde a su equipo Basis. Los canales Fiori y API no tienen esa limitación.

Sí, con un matiz según el canal. Las pruebas Fiori y API se ejecutan en cualquier lugar, incluso en un agente Linux headless. Las pruebas SAP GUI necesitan un agente Windows con SAP GUI instalado: es una limitación de SAP GUI Scripting, no de SAPFX. En la práctica, las dos familias se ejecutan en dos agentes distintos dentro de la misma cadena.

Lo mantenemos nosotros, y el código está publicado con licencia Apache 2.0 en GitHub. Esa es precisamente la respuesta a la pregunta: puede recuperarlo, bifurcarlo y mantenerlo vivo sin pedir permiso a nadie. En la versión 0.8.5, publicada en PyPI el 13 de octubre de 2026, el proyecto incluye 3959 pruebas unitarias reproducidas sin SAP en integración continua, 462 escenarios validados en vivo en 4 sistemas SAP reales (campañas del 12 de julio al 13 de octubre de 2026) y un 95 % de cobertura de código medida en integración continua, con un umbral mínimo del 85 %. Esa red de seguridad es la que hace realista una continuidad.

El mantenimiento estándar de SAP Solution Manager 7.2, que incluye CBTA, termina el 31 de diciembre de 2027 (nota SAP 3585220). SAP orienta a sus clientes hacia SAP Cloud ALM, que gestiona y sigue las pruebas; su ejecución automatizada pasa por herramientas que se conectan a él. Por tanto, los escenarios CBTA existentes deben retomarse en otra herramienta. SAPFX es una vía abierta y sin licencia: los escenarios se reescriben en Robot Framework, en SAP GUI, SAP Fiori y las API, y una guía de migración desde CBTA acompaña a las bibliotecas. La reescritura sigue siendo un trabajo, que podemos acompañar bajo presupuesto, directamente o con socios especializados.

Cinco agentes, cada uno limitado a un rol, trabajan sobre el sistema SAP real a través del servidor MCP rf-mcp y los plugins de SAPFX, bajo control humano: sap-planner confronta la petición con el sistema real, percibido pantalla a pantalla, y escribe un plan observado en specs/; sap-generator ejecuta cada paso en el sistema antes de escribirlo en la suite .robot, sellada con la huella de su plan; sap-healer repara la capa resources/, nunca la prueba ni sus aserciones, y registra cada diagnóstico; sap-verifier hace una revisión independiente en solo lectura frente al invariante de negocio y las evidencias; sap-istqb estructura los planes y casos de prueba según el ISTQB y la norma ISO/IEC/IEEE 29119-3, con un bloque de reproducción, y revisa el diseño de cada suite generada. Forman parte del taller SAPFX, no del paquete PyPI.

Diez herramientas, reunidas en el taller SAPFX, opcionales y entregadas bajo presupuesto (no están ni en el paquete PyPI ni en el repositorio público): un grabador SAP GUI y un grabador web para SAP Fiori y el WebGUI; Prompt Eval, que puntúa una petición de prueba antes de confiarla a los agentes; cinco agentes de IA y su marco (contrato de misión, hook de permisos, hilo de reanudación); el puente MCP (tres plugins de rf-mcp y la capa sapfx-mcp, con la aprobación por una persona de una escritura en SAP); el mantenimiento preventivo; la cartografía de las interfaces de un sistema SAP (relevamiento por RFC en solo lectura, láminas A3, informe y pruebas capturadas en SAP GUI); una capa de negocio de ejemplo; un pack de despliegue para Windows. Lo que producen sigue siendo Robot Framework corriente, que se ejecuta sin ellas. Detalle en la página de las herramientas del taller.

Con Prompt Eval, la herramienta del taller SAPFX añadida el 10 de octubre de 2026. Una petición de prueba confiada a los agentes es un prompt, y tratarla de principio a fin cuesta del orden de dos millones de tokens de agentes en nuestras campañas. Prompt Eval la puntúa antes: su forma y su parte de plantilla se verifican sin llamada a un modelo; un modelo de lenguaje, servido en local por defecto y puntuado con cero si no responde, juzga ocho criterios (intención, hechos frente a hipótesis, nivel de prueba, aserción, objetivo, repetibilidad, capacidades, postura); una sonda RFC en solo lectura verifica que las transacciones, tablas y módulos de función nombrados existen en el sistema objetivo. La puntuación mide la redacción, no el coste, y «jugable» no exime de la exploración en el sistema. Ver Prompt Eval.

Verifican las bibliotecas frente a dobles locales: objetos COM simulados en lugar de SAP GUI, dobles del navegador y de los canales HTTP y RFC, y la lógica pura probada por separado. Se ejecutan en integración continua sin sistema SAP ni licencia de usuario, y miden un 95 % de cobertura de código (umbral mínimo del 85 % impuesto en CI). Esa cobertura no garantiza la ausencia de defectos de negocio: se completa con 462 escenarios validados en vivo en cuatro sistemas SAP reales.

rf-test-agents, versión 1.0.0, es una solución libre bajo Apache 2.0 para pruebas Robot Framework. Cinco agentes especializados planifican, generan, reparan, verifican y documentan las pruebas aplicando el método STDD. Los controles de software verifican las convenciones y la procedencia de las pruebas; no miden la calidad general de los modelos. El repositorio cuenta con 310 pruebas unitarias, todas superadas en CI el 5 de octubre de 2026. Esta V1 disponible es distinta de CabraMesh, nuestros trabajos V2 de arquitectura agéntica todavía en investigación. Descubrir CabraMesh: ingeniería agéntica V2.

Agent Contract v1 descompone el ciclo de prueba en 5 roles estancos para eliminar cualquier conflicto de intereses: rf-planner cartografía y especifica las pruebas (archivos specs/) con trazabilidad ISTQB; rf-generator pilota la aplicación viva paso a paso antes de inscribir cualquier código; rf-healer repara quirúrgicamente los localizadores en resources/page_objects/ sin modificar nunca el cuerpo de la prueba; rf-verifier audita en solo lectura el rigor de las aserciones; y rf-istqb genera sin conexión la documentación ISO/IEC/IEEE 29119-3 y las matrices de trazabilidad.

La regla de oro absoluta de rf-generator es: ninguna palabra clave ni escenario .robot se consigna en el código sin haberse ejecutado antes con éxito en vivo sobre la aplicación de destino. Conectado mediante el servidor MCP rf-mcp (RobotMCP), el agente opera según el bucle determinista percibir → actuar → percibir. Verifica el estado del DOM o del sistema después de cada acción y elimina así cualquier alucinación de selector o de comportamiento de la aplicación.

Para preservar la integridad de la detección de errores, el campo de acción de rf-healer se limita estrictamente a la capa de automatización (resources/page_objects/). Tiene formalmente prohibido tocar los archivos de prueba de tests/, suprimir un paso o debilitar una aserción de negocio. Si un selector ha cambiado por un rediseño técnico, lo recalibra y registra la modificación en docs/heal-journal.md. Si el propio recorrido funcional ha cambiado, falla deliberadamente y cede el control a rf-planner para una revisión humana.

Las consignas textuales dadas a una IA están sujetas al olvido y a derivas estocásticas. rf-test-agents aplica 4 controles mecánicos deterministas, ejecutados en CI en cada push y mediante un hook de edición de Claude Code: check_spec_sync.py (control de procedencia SHA256 que vincula cada prueba a su especificación aprobada), check_conventions.py (rechazo estricto de los selectores CSS/XPath en bruto y prohibición absoluta de Sleep), check_guidance_sync.py (comprueba que las convenciones de CLAUDE.md se recogen en las definiciones de los agentes) y check_no_em_dash.py (neutralidad de estilo). Si un control falla, la CI falla; en Claude Code, solo check_conventions.py bloquea la edición. La sincronización de las definiciones de agentes entre Claude Code y GitHub Copilot se comprueba aparte, con regen_agent_definitions.py --check.

Estos tres pilares forman un ecosistema coherente y sin dependencia propietaria: rf-test-agents aporta la arquitectura multiagente universal y los controles mecánicos para cualquier proyecto de Robot Framework (web, API, móvil); SAPFX especializa este enfoque para el ERP crítico (SAP GUI, Fiori, API OData / RFC con el canal RFC plenamente operativo) con sus propios 5 agentes (servidor MCP rf-mcp y plugins de SAPFX); y CabrIA, programa de I+D, pretende aportar el cerebro soberano (modelo MoE 35B, con entrenamiento local previsto, y RAG híbrido FastMCP qa-brain ya en servicio) para pilotar estos agentes 100 % on-premise o en una nube soberana (Francia, UE), sin que ningún dato salga de su perímetro.

El Spec-Test-Driven Development (STDD) es la mentalidad común de rf-test-agents, SAPFX y ODOOFX. Tres eslabones, cada uno de los cuales guía al siguiente. Primero la especificación: una visión de conjunto en lenguaje humano, estructurada o no (objetivo de negocio, historia de usuario, escenario BDD, caso de prueba existente), que el planner confronta con el sistema vivo para redactar su versión observada en specs/, revisada por una persona: es la fuente de verdad. Después la prueba: generada a partir de esa especificación, con cada paso ejecutado en vivo antes de escribirse y la suite sellada con la huella SHA256 de su plan; un plan modificado sin regenerar la suite hace fallar el control. Por último el desarrollo: lo que la prueba exige y la biblioteca todavía no sabe hacer se convierte en una keyword de la biblioteca, nunca en un rodeo dentro de una suite. El healer repara la capa resources/, nunca la prueba, y un flujo de negocio que cambia remite a la especificación. Lo que distingue al STDD: la especificación se escribe en lenguaje humano, en cualquier forma (el BDD es una de ellas); su versión de referencia se observa en el sistema real y está protegida mecánicamente; y además guía el código de automatización.

STDD es un método que utiliza agentes, no una arquitectura agéntica. rf-test-agents V1.0.0 es la herramienta libre bajo Apache 2.0 que lo aplica. CabraMesh es el nombre de nuestros trabajos V2 en ingeniería agéntica: roles acotados, modelos locales adaptados a las tareas, acciones controladas y evidencias verificables. CabraMesh sigue en investigación; no se afirma ningún despliegue ni mejora medida. Descubrir CabraMesh: ingeniería agéntica V2.

Frente a TDD. STDD conserva la lógica de TDD y la adelanta un ladrillo. TDD es rojo, verde, refactor: primero el test, que falla, y luego el código que lo hace pasar. En STDD el primer ladrillo es la spec, y una spec es verde por defecto, en teoría: se escribe, se cree y nadie la ejecuta, así que nada puede hacerla fallar. STDD la somete a la prueba del sistema real: roja donde el sistema la refuta, verde una vez observada, y solo entonces llegan el test y el código.

El vídeo STDD lo muestra en imágenes: capítulo «De TDD a STDD», en el minuto 1:00 (8 min 34 en total, en inglés, con subtítulos en español).

No. El STDD es un método que utiliza agentes: somete la especificación a la prueba del sistema real antes de escribir la prueba y el código. rf-test-agents (versión 1.0.0, Apache 2.0) es la herramienta libre que lo aplica a Robot Framework. La ingeniería agéntica responde a otra pregunta: cómo organizar los roles, las autorizaciones, la ejecución y la verificación de agentes que actúan. Ese es el ámbito de CabraMesh, nuestros trabajos V2, todavía en investigación. Descubrir rf-test-agents · Descubrir CabraMesh.

CabraMesh es el nombre de nuestros trabajos V2 en ingeniería agéntica: una arquitectura local que busca que los agentes actúen en un marco controlado, bajo control humano, apoyando cada conclusión en evidencias. Sus líneas directrices: roles especializados con contextos acotados, modelos cualificados por tarea, una ejecución regida por controles deterministas y evidencias que van más allá del veredicto del agente. CabraMesh sigue en investigación: no se afirma ningún despliegue ni mejora medida, sus mecanismos internos no se describen públicamente y no tiene repositorio público. La V1 disponible en libre es rf-test-agents (versión 1.0.0, Apache 2.0). Descubrir CabraMesh.

ODOOFX es la vertical Odoo de AI Cabra: una biblioteca de código abierto para Robot Framework (Apache 2.0) destinada a probar Odoo Community y Enterprise por tres canales: la interfaz web (Browser / Playwright), la API RPC (XML-RPC hasta Odoo 18, la API JSON-2 a partir de Odoo 19) y la introspección ORM. Cinco agentes (odoo-planner, odoo-generator, odoo-healer, odoo-istqb, odoo-verifier) aplican en ella el Spec-Test-Driven Development definido en rf-test-agents, como SAPFX lo hace para SAP. La versión 0.2.0 está publicada en PyPI desde el 13 de octubre de 2026 (pip install robotframework-odoofx): sus canales RPC y web están probados en vivo en Odoo 16 y 19 con 117 pruebas, el cliente web cubre el inicio de sesión, la navegación, la lectura de las vistas, la entrada y el guardado de formularios y los botones de acción (los asistentes, las líneas de sección y de nota y la supresión de línea quedan por cubrir) y no se reivindica ningún resultado en una instancia de cliente. El código es público en GitHub (CyrilM29/robotframework-odoofx), la documentación de las keywords está en línea y el proyecto se presenta en la página de ODOOFX.

AI Cabra desarrolla soluciones de automatización de QA impulsadas por la IA que combinan machine learning, visión artificial, NLP y LLM para detectar los errores antes, generar automáticamente casos de prueba y optimizar sus ciclos de CI/CD. Intervenimos en consultoría de arquitectura, auditoría de madurez, acompañamiento u orientación hacia socios para sus migraciones de suites heredadas y soporte experto de nivel 3.

Unos costes de QA más bajos que con las soluciones propietarias (sin licencias), una mayor cobertura de pruebas, aplicaciones más fiables y una integración fluida en sus flujos de trabajo de CI/CD. Los beneficios dependen de su contexto: los cuantificamos con usted durante un proyecto piloto en lugar de adelantar un porcentaje genérico sin compromiso.

No. Equipamos a un equipo, no lo sustituimos. Las pruebas que producimos se escriben en lenguaje de negocio, precisamente para que sus probadores funcionales las lean, las critiquen y las hagan evolucionar sin volver a pasar por nosotros. La IA propone; la persona que conoce el negocio valida.

Sí. Nuestra experiencia abarca la integración de LLM con RAG (Retrieval-Augmented Generation), el fine-tuning de modelos de IA para la QA, la ingeniería de prompts avanzada y el desarrollo de agentes de IA inteligentes para acelerar la detección de errores y la generación de casos de prueba.

El RAG (Retrieval-Augmented Generation) combina búsqueda documental y generación para dar respuestas precisas y actualizadas. Lo utilizamos para aprovechar su base de pruebas, especificaciones y tickets con el fin de orientar las validaciones y los informes de QA.

Sí, cumplen al 100 % el RGPD. Nuestros modelos de IA se despliegan on-premise en su infraestructura o en una nube soberana (Francia, UE). Ningún dato sensible sale de sus servidores. Adaptamos el despliegue a sus requisitos de seguridad: cifrado, control de acceso y registro de actividad.

Por supuesto. Nuestros agentes de IA funcionan en modo aislado en su infraestructura o en nuestra infraestructura segura en Francia. Sus datos de prueba, su código fuente y sus logs permanecen en su entorno seguro. No almacenamos ni transmitimos ningún dato sensible a servidores de terceros.

Se ve, y ahí está la clave. Nuestros agentes trabajan bajo revisión humana y, cuando una prueba se repara sola, la reparación queda registrada, nunca es silenciosa. Una prueba que se corrige a escondidas deja de ser una prueba: se convierte en un testigo complaciente. Preferimos un fallo visible a un éxito dudoso.

Nuestro equipo está formado por expertos en IA y QA procedentes de grandes consultoras tecnológicas, con una sólida experiencia en automatización de pruebas, machine learning e integración de LLM en proyectos de envergadura internacional. También contamos con una gran experiencia en comercio electrónico: embudos de compra, pagos y UX adaptable.

SAPFX no cuesta nada: es de código abierto con licencia Apache 2.0, sin licencias que pagar ni usuarios que declarar. Para los servicios de acompañamiento (auditoría, acompañamiento metodológico u orientación hacia socios para sus migraciones, formación, integración CI/CD), presupuestamos tras un encuadre técnico preciso, en función del perímetro real de su sistema de información.

CabrIA es el programa de I+D de AI Cabra: un modelo de IA abierto, especializado en Quality Engineering, destinado a un fine-tuning local sobre las ejecuciones de prueba reales del equipo (Robot Framework, Playwright, agentes mediante MCP) y acoplado a una base de conocimiento RAG en la que cada respuesta cita sus fuentes. El conjunto está diseñado para funcionar on-premise, en una estación de IA local.

Un asistente generalista conoce las pruebas de software en general; CabrIA está diseñado para aprender su terreno. El fine-tuning previsto debe inscribir en el modelo sus convenciones y sus gestos (diseñar un plan de pruebas, escribir una suite, diagnosticar un fallo, reparar un localizador), y la base de conocimiento guarda los hechos que cambian: trampas conocidas de sus aplicaciones, procedimientos, versiones. Se actualiza sin volver a entrenar el modelo.

La arquitectura MoE de 35 000 millones de parámetros en total solo activa unos 3000 millones de parámetros por token procesado. Este desacoplamiento ofrece la profundidad de razonamiento y la riqueza léxica de un gran modelo, al tiempo que mantiene una huella de memoria compacta y una velocidad de ejecución elevada (rendimiento histórico de unos 100 tok/s en inferencia local GGUF, según las condiciones, sin garantía). Es el compromiso elegido para un despliegue ágil en una estación de trabajo dedicada.

La arquitectura ADR 0002 separa estrictamente el saber hacer duradero de los hechos volátiles. El saber hacer (convenciones de Robot Framework, selectores accesibles de Playwright, estrategias de diagnóstico) debe aprenderse en los pesos mediante un fine-tuning LoRA SFT y después DPO, todavía por realizar. Los hechos volátiles (trampas de las aplicaciones, versiones de build, notas de encuadre) los gestiona un RAG local híbrido (FastMCP qa-brain, en servicio, sobre una base vectorial Qdrant densa F16, con BM25 complementario y reranker, 4119 pasajes indexados a 9 de octubre de 2026). Cada respuesta cita sus pasajes; una respuesta sin citas se rechaza y se sustituye por los pasajes en bruto.

No. La base de conocimiento y la restitución funcionan en una estación de IA local, dentro de su infraestructura, y el entrenamiento (fine-tuning), todavía por realizar, también está previsto allí. Es el mismo principio de soberanía que el resto de nuestras soluciones: ningún dato de prueba se envía a una API en la nube.

Leyendo sus fuentes. Cada respuesta de CabrIA cita los pasajes de los que procede, lo que le permite remontarse a la especificación, a la prueba o al ticket de origen; una respuesta sin citas se rechaza y se sustituye por los pasajes en bruto. Es una restricción de diseño, no una opción: un asistente de QA que no se puede verificar no tiene cabida en una cadena de calidad.

Intervienen dos salvaguardas estrictas: un registrador de vuelo universal dotado de un depurador (scrubber) automático que enmascara sobre la marcha identificadores, secretos de API y datos personales antes de cualquier almacenamiento; y después una refinería con un juez distinto, confirmación de las notas y trazabilidad. La validación sistemática del código generado sobre fixtures sin conexión sigue siendo un hito por completar antes del entrenamiento. A 9 de octubre de 2026 hay 1892 ejemplos de entrenamiento admitidos (917 críticas de pruebas, 526 diagnósticos, 313 pares especificación-suite, 136 lecciones aprendidas). El 9 de octubre de 2026 se superaron 1070 de 1071 pruebas automatizadas, en un solo proceso; la prueba restante consulta los servicios reales del laboratorio y superó su tiempo de espera. Estas pruebas verifican el software, no la calidad de cada respuesta del modelo.

AI Cabra ha optado deliberadamente por construir la cadena en una configuración de laboratorio de coste controlado: dos estaciones de trabajo con 128 GB de memoria unificada, para la inferencia local continua en formato cuantizado GGUF (rendimiento histórico de unos 100 tok/s, según las condiciones) y para el primer entrenamiento LoRA en bf16, todavía por realizar. El objetivo es demostrar que una IA de QA empresarial puede prescindir de un clúster de centro de datos desorbitado y de API facturadas por token.

Para limitar el sesgo de autoevaluación (el síndrome del modelo que considera sistemáticamente excelentes sus propias respuestas), nuestro banco de evaluación recurre a un modelo juez de referencia independiente de 30 000 millones de parámetros. Este árbitro externo evalúa el rigor de las aserciones, la limpieza del código producido y la exactitud de los diagnósticos según una rúbrica estricta. Aporta confirmación y trazabilidad de las notas, sin pretender eliminar todo sesgo; una avería de la estación no equivale a rechazar al candidato. El banco cuenta con 77 casos, de los cuales 19 son RAG (estado a 11 de septiembre de 2026).

Todavía no como producto: es un programa de I+D dirigido con la prueba por delante (banco de evaluación, captura, corpus, entrenamiento, puesta en servicio). El RAG local qa-brain está en servicio (4119 pasajes indexados a 9 de octubre de 2026); el primer fine-tuning sigue por realizar, con un conjunto de 1892 ejemplos admitidos a 9 de octubre de 2026. Publicaremos mediciones, no promesas. Contacte con nosotros para una demostración o para hablar de ello con vistas a su equipo de QA.

CabraFlow es un proyecto de AI Cabra en diseño: un orquestador de pruebas keyword-driven previsto sobre Playwright. La intención de diseño: usted haría la demostración de su negocio en la aplicación narrándola en voz alta, y la prueba se escribiría ante sus ojos, en microfrases de negocio, con sus propias palabras. No sería una bifurcación ni de Robot Framework ni de Playwright, sino un orquestador que uniría el enfoque keyword-driven del primero con el motor y los localizadores orientados al usuario del segundo. Estado a 6 de octubre de 2026: seis especificaciones redactadas el 12 de agosto de 2026, ninguna línea de código, ningún prototipo ni demostración. El modo de voz espera un criterio cuantificado (más del 85 % de pasos correctos, menos de 2 s de latencia) que todavía no se ha medido.

No, es la intención de diseño. El lenguaje visible serían microfrases de negocio creadas sobre la marcha con las palabras de quien hace la demostración («Validar el pedido», «Iniciar sesión como comprador»), nunca código ni vocabulario de herramienta. Está previsto un estudio gráfico para ensamblar y editar las palabras clave; los perfiles técnicos conservarían un modo de desarrollo en el que el archivo YAML de origen se edita directamente. Nada de esto está desarrollado todavía: CabraFlow se encuentra en la fase de especificaciones.

Es un objetivo de diseño, todavía no un resultado medido. El lenguaje no contendría ni CSS ni XPath: los destinos se resolverían mediante el árbol de accesibilidad (rol y nombre accesibles, los localizadores getByRole de Playwright), y la prueba interactuaría con la página como un usuario. Si un desarrollo cambia la estructura HTML conservando el rol semántico, la prueba debería resistir.

No, por diseño. La prueba sería un archivo YAML legible y versionable, previsto para reproducirse en tres destinos: el runner nativo, una exportación a Playwright (.spec.ts) y una exportación a Robot Framework (.robot), a los que se añadiría una exportación documental ISTQB para las pruebas de aceptación formales y la auditoría. Está previsto que las exportaciones se regeneren a partir del YAML. Nada de esto existe todavía: CabraFlow está en diseño.