Un ciclo de calidad completo, operado sobre tu producto.

Managed Quality Engineering. Refinamiento, testing agéntico, automatización y CI/CD operados por UPEX con responsabilidad humana, y observación de producción hasta el nivel de madurez que tenga sentido para tu producto.

Solicitar una evaluación inicial

Ver cómo funciona el IQL

// Qué opera UPEX

Operado

Prevention01 · refinamientoOperado
Early Detection02 · testing agénticoOperado
Continuous Detection03 · automatización y CIOperado
Production Observation04 · según madurezSegún producto

01Evaluación
02Setup
03Operación
04Mejora continua

// El problema

Cinco frases que ya se dijeron en tu equipo de ingeniería

Ninguna se arregla con más horas. Se arreglan con un ciclo de calidad que alguien opere de punta a punta.

«La regresión nos come la semana antes de cada release.»
Y cuando aparece algo urgente, lo que se recorta es exactamente lo que después se rompe.
«El pipeline está en rojo hace dos semanas. Le damos otra corrida y pasa.»
Ya nadie mira los reportes. Tienes automatización, pero no confías en ella.
«Solo probamos por la interfaz.»
Los bugs de datos y los contratos rotos entre servicios los descubre producción.
«Compramos licencias de IA para el equipo y no vemos retorno.»
Nadie sabe darle contexto al agente ni cuándo desconfiar de lo que devuelve.
«El código generado por IA crece más rápido que la cobertura.»
Cada sprint entra más código del que el equipo puede revisar, y las pruebas no acompañan el ritmo.
Ninguno de estos es un problema de esfuerzo. Son problemas de método, y el método se puede operar.

// Qué opera UPEX

Cuatro capas, del refinamiento a producción

El IQL leído en resultados. Cada capa dice qué cambia en tu proceso y qué obtiene tu equipo; hasta dónde llega cada producto lo decide la evaluación inicial.

01 · PreventionPasos 1-2
QA entra en el refinamiento: tus historias llegan al sprint con criterios verificables y plan de aceptación.
02 · Early DetectionPasos 3-4
Detección temprana: tu equipo recibe los bugs antes del PR, no después del release.
03 · Continuous DetectionPasos 5-10
Regresión en CI en la que tu equipo puede creer: solo lo que demostró valor se automatiza.
04 · Production ObservationPasos 11-15
Producción como fuente de la estrategia de calidad, hasta donde tu infraestructura lo permita.

IQL define qué observar y qué mejorar; el nivel de madurez define hasta dónde implementar Late Game; los targets concretos los define cada producto.

¿Qué quieres hacer con el IQL?

UPEX GalaxyAprenderlo
UPEX SatelliteContratar gente formada en él

Ver la vista ejecutiva del método

// Cómo se contrata

Cuatro modelos, una secuencia

Se entra por la evaluación inicial. Lo que sigue depende de lo que la evaluación encuentre y de lo que tu equipo quiera operar por su cuenta.

Modelo	Lo que obtienes
01 · Punto de entradaEvaluación inicial	Un mapa de riesgos de tu producto y una recomendación escrita sobre qué cambiar primero. Mapa de riesgos del producto y de su proceso de entrega Análisis de la cobertura actual, manual y automatizada Revisión del pipeline y de los incidentes recientes Recomendaciones escritas, con orden de adopción
02 · ImplementaciónIQL Setup	El ciclo de calidad funcionando sobre tu producto, con tu equipo adentro desde el primer día. Contexto agéntico sobre tu repositorio, tu tracker y tu API Automatización con trazabilidad a cada historia Gates de calidad en tu CI Reportes de ejecución legibles por ingeniería Documentación y adopción con el equipo
03 · Operación recurrenteOperación mensual	Cada historia del sprint sale con cobertura y la suite de regresión no se degrada. Cobertura de cada historia del sprint Triage de primer nivel de los bugs encontrados Revisión de los reportes de cada ejecución Participación en el refinamiento Mantenimiento de la automatización
04 · LiderazgoFractional QA Lead	Criterio de calidad senior a tiempo parcial, sin abrir un puesto. Criterios de calidad del producto Refinamiento de alto nivel con producto e ingeniería Interfaz con el liderazgo técnico Revisión final de lo que se libera Asíncrono siempre que sea posible

El alcance y los plazos se acuerdan por producto, después de la evaluación inicial.

// Cómo funciona

De la evaluación a la mejora continua

Un mismo ciclo, cuatro momentos. Ninguno exige que tu equipo cambie de herramientas para empezar.

01
Evaluación
Accesos de lectura a repositorio, tracker y CI, conversaciones cortas con el equipo, y un mapa de riesgos con recomendación escrita.
02
Setup
UPEX configura el método sobre tu stack: contexto para los agentes, automatización, gates en CI y reportes, con tu equipo participando.
03
Operación
Comunicación asíncrona en tu canal, refinamiento de cada historia y reporte de cada ciclo; todo queda en tu tracker y en tu repositorio.
04
Mejora continua
Lo que vuelve de los entornos que definas alimenta el siguiente ciclo: qué observar, qué probar y qué automatizar.

Todo lo producido es tuyo: código, casos, artefactos y configuración viven en tus sistemas, no en los de UPEX.

// Quién hace qué

Agentes que ejecutan, personas que responden

Quality Engineering operado con IA y con responsabilidad humana. Ningún agente decide por tu equipo.

01
Agent executes.
Los agentes
Ejecutan los flujos repetibles: análisis de historias, cobertura, ejecución en CI, mantenimiento de la suite.
02
Evidence proves.
Los Quality Engineers de UPEX
Supervisan cada ejecución, revisan la evidencia y hacen el triage de primer nivel.
03
Human owns the decision.
El QA Lead
Es dueño de los criterios de calidad y de la decisión final: qué se prioriza, qué se automatiza, qué se aprueba.

Los agentes corren lo repetible. La evidencia sostiene cada conclusión. Una persona firma cada decisión.

Los límites del agente

Son parte del método, no una promesa comercial: valen igual en el Dojo y en tu producto.

Lectura
El agente lee código, schema de API (por MCP), tracker y datos de prueba; nunca datos de producción ni datos personales reales.
Escritura
Escribe en ramas propias, en artefactos QA del tracker y en archivos de test; nunca en main, en producción ni en la configuración de CI sin pull request.
Aprobación
Toda transición que cambie el estado de negocio de una historia, todo veredicto ROI y todo merge los aprueba una persona; el agente propone.
Secretos
Los tokens viven en variables de entorno y en el login de la CLI; nunca en prompts, artefactos, commits ni en el tracker.
Validación
Ninguna conclusión entra a un artefacto sin evidencia reproducible (comando, respuesta, captura, fila); cada herramienta se sonda antes de asumirla («probe, don't assume»).
Trazabilidad
Cada artefacto y cada test que produce el agente enlaza al ítem del tracker (@atc('KEY'), labels) y cada sesión deja rastro auditable (rama, commit, artefacto).
Checkpoints
Los skills no corren de punta a punta sin parar: cada stage termina en un punto de revisión humana.

// El método por capas

Qué es del IQL y qué es de tu stack

El método se separa en tres capas para que nadie crea que exige un tracker, un framework o un proveedor de CI en particular.

01
IQL Core
Los principios y el flujo que no cambian aunque cambie el stack, el tracker o el cliente.
02
IQL Implementation Standard
Lo que UPEX prescribe o recomienda al implementarlo: patrones, herramientas y guardrails de IA.
03
Environment Integrations
Lo que trae tu entorno y con lo que el método se integra: tracker, repositorio, CI, chat, observabilidad.

El IQL no exige migraciones sin justificación técnica.

El IQL no exige reemplazar el ecosistema del cliente. Exige que exista el equivalente funcional: un tracker con workflow, un CI que corra en cada PR y, para el Late Game, una fuente de observación en producción.

Herramientas por capa y nivel de decisión

Cada herramienta lleva su nivel de decisión y el porqué. Lo que dice «lo trae el cliente» se integra; lo que dice «recomendado» se cambia con una evaluación técnica.

Herramienta	Capa	Decisión	Por qué
KATA	Implementation Standard	RECOMMENDED	Es la arquitectura que hace trazable cada ATC a su historia (`@atc('KEY')`) y la que los skills del boilerplate saben operar. Cuando UPEX construye la automatización desde cero se usa tal cual; sobre un framework que el cliente conserva se aplican sus invariantes (capas, inyección de dependencias, decoradores) mediante `/adapt-framework`, sin reescribirlo.
Playwright	Implementation Standard	RECOMMENDED	Default cuando UPEX automatiza desde cero: el boilerplate y la capa 2 de KATA lo asumen. No es obligatorio porque el IQL no exige migraciones sin justificación técnica: un stack maduro existente (Cypress, WebdriverIO) se evalúa al inicio y se conserva, se adapta o se migra por etapas.
Xray	Implementation Standard	ADAPTABLE	Modalidad de TMS con la que UPEX opera (`jira-xray`): la cobertura de la historia la da el ATS de forma nativa. El boilerplate arranca en `jira-native` (`tms_cli: null`) y esa modalidad está soportada; otro TMS (TestRail, Zephyr) se evalúa como adaptación. La modalidad la decide la evaluación inicial, no el método.
Harness agéntico (Claude Code, OpenCode, Codex)	Implementation Standard	ADAPTABLE	Los skills, commands y MCPs del boilerplate se ejecutan con Claude Code, OpenCode (cualquier LLM) o Codex, y son adaptables a cualquier otro harness. El método vive en los skills (markdown), no en el agente: cambiar de harness cambia velocidad y ergonomía, no el flujo.
MCPs (OpenAPI, base de datos, tracker, navegador)	Implementation Standard	ADAPTABLE	Son la forma en que el agente lee schema, datos y tracker; cuáles se conectan depende del stack del cliente. Regla del boilerplate: el MCP lee, nunca ejecuta (la API se ejercita con curl y el token de la CLI), y un MCP configurado está en rojo hasta que responde de verdad.
Docker	Implementation Standard	RECOMMENDED	Reproducibilidad de la corrida de Playwright en CI con la imagen oficial. Si el CI del cliente ya provee runners con navegadores, se adapta.
Cliente de API (Postman, Bruno, curl)	Implementation Standard	ADAPTABLE	Exploración de la pata API de la Trifuerza. El boilerplate usa OpenAPI MCP + curl; cualquier cliente equivalente sirve.
k6	Implementation Standard	ADAPTABLE	Solo cuando el atributo performance entra por riesgo en el Step 1. No forma parte del Dojo ni se promete en la oferta a empresas.
Jira (o tracker equivalente)	Environment Integration	CLIENT-CONTROLLED	El tracker es del cliente. El IQL exige un workflow con los estados y transiciones de `iql.jiraStates`; hoy el Implementation Standard solo tiene Jira implementado (`.agents/jira-workflows.json`), así que Azure DevOps u otro tracker es trabajo de adaptación evaluado al inicio.
Confluence (o wiki del equipo)	Environment Integration	CLIENT-CONTROLLED	Donde viva la documentación del cliente. Los artefactos QA viven en el tracker, no en el wiki.
GitHub / GitLab (repositorio y pull requests)	Environment Integration	CLIENT-CONTROLLED	El repositorio y el flujo de pull request los trae el cliente. El estándar exige rama por historia y PR revisado.
GitHub Actions (o CI equivalente)	Environment Integration	CLIENT-CONTROLLED	El CI lo trae el cliente (GitHub Actions, GitLab CI, Jenkins). El estándar exige que los ATCs corran en cada PR; el pipeline de referencia del boilerplate está escrito para GitHub Actions.
Slack / Teams	Environment Integration	CLIENT-CONTROLLED	Canal de avisos de CI y de alertas. El IQL no depende de cuál.
Sentry / Grafana / Datadog	Environment Integration	CLIENT-CONTROLLED	El Late Game observa con lo que el cliente ya tiene. El IQL define qué observar; la herramienta la define el entorno. Prerrequisito del nivel Production Observation.
UptimeRobot (o monitor de disponibilidad)	Environment Integration	CLIENT-CONTROLLED	Cualquier monitor de uptime equivalente.
Despliegue progresivo / feature flags	Environment Integration	CLIENT-CONTROLLED	Prerrequisito de canary y A/B. Sin esto los steps 11 y 12 no se implementan.
Herramientas de chaos (Gremlin, Litmus, scripts propios)	Environment Integration	CLIENT-CONTROLLED	Prerrequisito del step 14.

Ver las 17 herramientas

KATA
Implementation StandardRECOMMENDED
Es la arquitectura que hace trazable cada ATC a su historia (@atc('KEY')) y la que los skills del boilerplate saben operar. Cuando UPEX construye la automatización desde cero se usa tal cual; sobre un framework que el cliente conserva se aplican sus invariantes (capas, inyección de dependencias, decoradores) mediante /adapt-framework, sin reescribirlo.
Playwright
Implementation StandardRECOMMENDED
Default cuando UPEX automatiza desde cero: el boilerplate y la capa 2 de KATA lo asumen. No es obligatorio porque el IQL no exige migraciones sin justificación técnica: un stack maduro existente (Cypress, WebdriverIO) se evalúa al inicio y se conserva, se adapta o se migra por etapas.
Xray
Implementation StandardADAPTABLE
Modalidad de TMS con la que UPEX opera (jira-xray): la cobertura de la historia la da el ATS de forma nativa. El boilerplate arranca en jira-native (tms_cli: null) y esa modalidad está soportada; otro TMS (TestRail, Zephyr) se evalúa como adaptación. La modalidad la decide la evaluación inicial, no el método.
Harness agéntico (Claude Code, OpenCode, Codex)
Implementation StandardADAPTABLE
Los skills, commands y MCPs del boilerplate se ejecutan con Claude Code, OpenCode (cualquier LLM) o Codex, y son adaptables a cualquier otro harness. El método vive en los skills (markdown), no en el agente: cambiar de harness cambia velocidad y ergonomía, no el flujo.
MCPs (OpenAPI, base de datos, tracker, navegador)
Implementation StandardADAPTABLE
Son la forma en que el agente lee schema, datos y tracker; cuáles se conectan depende del stack del cliente. Regla del boilerplate: el MCP lee, nunca ejecuta (la API se ejercita con curl y el token de la CLI), y un MCP configurado está en rojo hasta que responde de verdad.
Docker
Implementation StandardRECOMMENDED
Reproducibilidad de la corrida de Playwright en CI con la imagen oficial. Si el CI del cliente ya provee runners con navegadores, se adapta.
Cliente de API (Postman, Bruno, curl)
Implementation StandardADAPTABLE
Exploración de la pata API de la Trifuerza. El boilerplate usa OpenAPI MCP + curl; cualquier cliente equivalente sirve.
k6
Implementation StandardADAPTABLE
Solo cuando el atributo performance entra por riesgo en el Step 1. No forma parte del Dojo ni se promete en la oferta a empresas.
Jira (o tracker equivalente)
Environment IntegrationCLIENT-CONTROLLED
El tracker es del cliente. El IQL exige un workflow con los estados y transiciones de iql.jiraStates; hoy el Implementation Standard solo tiene Jira implementado (.agents/jira-workflows.json), así que Azure DevOps u otro tracker es trabajo de adaptación evaluado al inicio.
Confluence (o wiki del equipo)
Environment IntegrationCLIENT-CONTROLLED
Donde viva la documentación del cliente. Los artefactos QA viven en el tracker, no en el wiki.
GitHub / GitLab (repositorio y pull requests)
Environment IntegrationCLIENT-CONTROLLED
El repositorio y el flujo de pull request los trae el cliente. El estándar exige rama por historia y PR revisado.
GitHub Actions (o CI equivalente)
Environment IntegrationCLIENT-CONTROLLED
El CI lo trae el cliente (GitHub Actions, GitLab CI, Jenkins). El estándar exige que los ATCs corran en cada PR; el pipeline de referencia del boilerplate está escrito para GitHub Actions.
Slack / Teams
Environment IntegrationCLIENT-CONTROLLED
Canal de avisos de CI y de alertas. El IQL no depende de cuál.
Sentry / Grafana / Datadog
Environment IntegrationCLIENT-CONTROLLED
El Late Game observa con lo que el cliente ya tiene. El IQL define qué observar; la herramienta la define el entorno. Prerrequisito del nivel Production Observation.
UptimeRobot (o monitor de disponibilidad)
Environment IntegrationCLIENT-CONTROLLED
Cualquier monitor de uptime equivalente.
Despliegue progresivo / feature flags
Environment IntegrationCLIENT-CONTROLLED
Prerrequisito de canary y A/B. Sin esto los steps 11 y 12 no se implementan.
Herramientas de chaos (Gremlin, Litmus, scripts propios)
Environment IntegrationCLIENT-CONTROLLED
Prerrequisito del step 14.

Qué significa cada nivel

REQUIRED: Sin esto no es IQL como UPEX lo implementa.
RECOMMENDED: Default de UPEX; se cambia con una evaluación técnica que lo justifique.
ADAPTABLE: Hay más de una opción soportada; la evaluación inicial elige.
CLIENT-CONTROLLED: Lo trae el entorno del cliente; el IQL se integra.

// Con qué contamos

El método es público y ya corre

Todavía no publicamos métricas de clientes. Lo que sí se puede ver: el framework con el que operamos, la metodología completa y capturas del proyecto de referencia.