Saltar a contenido

Los 4 modelos de orquestación de crowdar-qa-skills

Esta guía explica, sin necesidad de saber programar, las 4 formas distintas en las que el trabajo de QA automatizado puede arrancar y ejecutarse en este sistema.

Todos los modelos usan las mismas herramientas de base (las "skills": leer una historia, armar un plan de pruebas, explorar la app, generar tests, correrlos, reportar). Lo que cambia entre un modelo y otro es quién decide qué hacer y en qué orden, y quién se encarga de ejecutarlo.

1. Dos preguntas separadas (la clave para entenderlos)

Antes de ver cada modelo, hay que entender que en realidad se están respondiendo dos preguntas distintas:

Pregunta Posibles respuestas
¿Quién decide qué pasos hacer y en qué orden? Una persona · El asistente de IA · Una regla fija ya escrita
¿Quién se encarga de ejecutar esos pasos? El asistente de IA · Un motor de software (código) que sigue instrucciones al pie de la letra

Pensalo como pedir comida en un restaurante:

  • Un cocinero improvisando con lo que hay en la heladera: él mismo decide el menú y él mismo cocina. Cada vez puede salir distinto. Este representa el modelo 1.
  • Un mostrador con protocolos: la persona que te atiende escucha tu pedido y lo deriva al protocolo A o B ya escritos; a partir de ahí, todo sigue esa receta sin inventar nada. Este representa el modelo 2.
  • Una receta impresa que alguien sigue a mano: un humano decidió de antemano los pasos, y alguien (o algo) los va tildando uno por uno. Este representa el modelo 3.
  • Un semáforo automático: nadie decide nada en el momento — la regla ya está fija de antemano y siempre se aplica igual. Este representa el modelo 4.

2. Tabla resumen de los 4 modelos

# Modelo ¿Quién decide el flujo? ¿Quién lo ejecuta? Estado hoy en crowdar-qa-skills
1 Improvisado El asistente de IA El asistente de IA Disponible — es el uso del día a día en Claude Code
2 Híbrido adaptativo El asistente de IA clasifica y elige entre planes ya escritos Un motor de software (código), no el asistente En desarrollo — el motor que lo ejecuta se está construyendo (ver punto 6)
3 Human-in-the-loop Una persona (QA), siguiendo un playbook escrito de antemano El asistente de IA, dentro de cada paso del playbook Disponible — son los "playbooks" que ya existen en el proyecto
4 Declarativo puro Una regla fija, sin que nadie decida en el momento Un motor de software (código) En desarrollo — depende del mismo motor que se está construyendo para el Modelo 2

¡IMPORTANTE! Hoy ya podés trabajar con los Modelos 1 y 3. Los Modelos 2 y 4 están diseñados y documentados, y el "motor" (engine) que los va a ejecutar se está desarrollando activamente. Más detalle en el punto 6.

Los 4 modelos de orquestación: Improvisado, Híbrido adaptativo, Human-in-the-loop y Declarativo puro

3. Ejemplo guía: "TechStore", una tienda online con carrito de compras

Para que los ejemplos sean concretos, vamos a usar TechStore, una tienda online de electrónica con carrito de compras (agregar productos, ver el carrito, pagar).

3.1 Cómo se ve un test generado (Playwright vs. Lippia)

Sin importar qué modelo dispare el trabajo, el resultado final es siempre el mismo tipo de artefacto: un test automatizado. Lo único que cambia es qué framework lo ejecuta — eso lo define qa-stack.yaml del proyecto (test_framework: playwright o test_framework: lippia), no el modelo de orquestación.

Para el caso "agregar un producto al carrito" (historia US-010), así se ve el mismo caso de prueba en cada framework:

Con Playwright (tests/US-010/tc-01-agregar-producto-carrito.spec.js):

const { test, expect } = require('@playwright/test');

test.describe('US-010 — Agregar producto al carrito', () => {
  test.beforeEach(async ({ page }) => {
    await page.goto('/catalogo');
  });

  test('TC-01 — Agregar un producto disponible al carrito', async ({ page }) => {
    // ACT
    await page.getByRole('link', { name: 'Auriculares Bluetooth XT200' }).click();
    await page.getByRole('button', { name: 'Agregar al carrito' }).click();

    // ASSERT
    await expect(page.locator('[data-testid="cart-count"]')).toHaveText('1');
    await expect(page.locator('.toast-success')).toContainText('Producto agregado al carrito');
  });
});

Con Lippia (features/US-010/tc-01-agregar-producto-carrito.feature + CarritoSteps.java):

# language: es
Feature: US-010 — Agregar producto al carrito

  Background:
    Given el usuario está autenticado en la aplicación

  @US-010 @tc01 @smoke
  Scenario: TC-01 — Agregar un producto disponible al carrito
    Given el usuario está en el catálogo de TechStore
    When agrega el producto "Auriculares Bluetooth XT200" al carrito
    Then el contador del carrito muestra "1" producto
    And se muestra el mensaje "Producto agregado al carrito"

Cuando("^agrega el producto \"([^\"]*)\" al carrito$", (String producto) -> {
    driver.findElement(By.xpath("//a[normalize-space()='" + producto + "']")).click();
    wait.until(ExpectedConditions.elementToBeClickable(BOTON_AGREGAR_CARRITO));
    driver.findElement(BOTON_AGREGAR_CARRITO).click();
});

Entonces("^el contador del carrito muestra \"([^\"]*)\" producto$", (String cantidad) -> {
    wait.until(ExpectedConditions.visibilityOfElementLocated(CONTADOR_CARRITO));
    Assert.assertEquals(driver.findElement(CONTADOR_CARRITO).getText(), cantidad);
});

La diferencia entre frameworks es sintaxis y lenguaje (JavaScript vs. Java/Gherkin, selectores por rol vs. By.xpath/By.id). La diferencia entre modelos (1, 2, 3 o 4) es otra cosa completamente distinta: quién decidió correr este test y en qué momento — no cómo está escrito. Los ejemplos de cada modelo, más abajo, reutilizan este mismo caso de TechStore.

4. Modelos

Modelo 1 — Improvisado

Qué es: le pedís algo al asistente de IA en lenguaje natural (por ejemplo, dentro de Claude Code), y el asistente mismo decide qué herramientas usar y en qué orden, según lo que entendió de tu pedido.

Cuándo usarlo: para el trabajo interactivo del día a día — exploración, prototipos, pedidos puntuales, debugging.

Ejemplo con TechStore:

Le decís al asistente: "Armame los tests para la historia de agregar un producto al carrito."

El asistente, por sí solo, decide leer la historia de usuario, armar un plan de pruebas, explorar la app, generar la suite de tests, correrla y repararla si algo falla, y escribir el reporte final — sin que nadie le haya dicho el orden exacto. Es exactamente lo que hace hoy el playbook completo qa-workflow-e2e cuando se lo invocás directamente. El test que termina generando (en Playwright o en Lippia, según qa-stack.yaml) es el mismo que se muestra en el punto 3.1.

Lo que hay que tener en cuenta: como decide el asistente en el momento, dos corridas sobre el mismo pedido pueden no ser 100% idénticas — puede tomar un camino levemente distinto cada vez. Por eso no se recomienda para procesos donde se necesita que el resultado sea siempre reproducible (por ejemplo, un pipeline automático de CI/CD).

Modelo 2 — Híbrido adaptativo (en desarrollo — Fase 2 del roadmap)

Qué es: el asistente de IA no improvisa el flujo entero, solo clasifica el pedido y elige, entre una lista cerrada de "planes" ya escritos de antemano, cuál corresponde. A partir de ahí, un motor de software (no el asistente) ejecuta ese plan paso a paso, siempre de la misma forma.

Cuándo se usaría: en un pipeline automático, cuando llega un evento ambiguo que necesita algo de criterio para saber a qué plan corresponde. Por ejemplo, alguien deja un comentario en un Merge Request pidiendo algo en lenguaje libre.

Ejemplo con TechStore (cuando el motor esté listo):

Alguien comenta en un Merge Request de TechStore: "volvé a probar el flujo de pago, algo cambió ahí."

El "clasificador" entiende que ese pedido corresponde al plan regression-payment (ya escrito de antemano) y se lo pasa al motor, que lo ejecuta exactamente igual que la última vez que se corrió ese plan — sin inventar nada nuevo en el camino. El motor genera y corre el mismo tipo de test del punto 3.1 (Playwright o Lippia, según qa-stack.yaml del proyecto) — lo que cambia frente al Modelo 1 es que nadie improvisó el flujo: el clasificador solo eligió qué plan ya escrito correspondía.

Estado de desarrollo: este modelo necesita un motor determinístico (un programa que ejecuta planes YA escritos, paso a paso, sin usar el criterio del asistente para decidir la coreografía). Ese motor ya está diseñado en el plan técnico y se está construyendo actualmente — es la "Fase 2" del roadmap del proyecto.

Modelo 3 — Human-in-the-loop (con playbooks)

Qué es: una persona (de QA) decide el flujo de antemano y lo deja escrito en un documento paso a paso (un "playbook"). El asistente de IA no decide el orden — solo ejecuta lo que dice cada paso del playbook, con su propio criterio dentro de ese paso puntual.

Cuándo usarlo: para workflows especializados que se repiten seguido y conviene que salgan siempre igual: puesta en marcha de un proyecto nuevo, smoke test después de un deploy, regresión sobre un módulo puntual, una demo para el cliente.

Ejemplo con TechStore:

Alguien del equipo de QA sigue el playbook new-project-bootstrap.md para dejar TechStore configurado: primero el asistente detecta con qué está armado el proyecto, después arma el pipeline de CI, y por último corre una prueba piloto — siempre en ese orden, porque así lo define el playbook, no porque el asistente lo decidió en el momento.

Si el playbook usado fuera regression-on-module.md sobre el módulo de carrito, el paso "generar suite" produciría el mismo test del punto 3.1 (Playwright o Lippia) — la diferencia frente al Modelo 1 no está en el test generado, sino en que acá el orden de los pasos ya estaba escrito de antemano.

Disponible hoy: sí — son los playbooks que ya existen en la carpeta playbooks/ del repositorio (por ejemplo new-project-bootstrap.md, smoke-test-post-deploy.md, regression-on-module.md, demo-walkthrough.md, bug-fix-cycle.md). Las guías de esta misma documentación (los "instructivos") están escritas justamente para acompañarte a usar estos playbooks.

Modelo 4 — Declarativo puro (en desarrollo — Fase 3 del roadmap)

Qué es: una regla fija, escrita de antemano, que dispara siempre el mismo plan ante el mismo evento — sin que nadie decida nada en el momento, ni una persona ni el asistente de IA. Es el modelo más rígido y más predecible de los cuatro.

Cuándo se usaría: en pipelines de CI/CD, donde un evento técnico dispara automáticamente una acción fija. Por ejemplo: "cada vez que se sube código, correr el smoke test" o "cada noche, correr la regresión completa".

Ejemplo con TechStore (cuando el motor esté listo):

Cada vez que alguien sube un cambio de código a la rama principal de TechStore, se dispara automáticamente (sin que nadie lo pida) el plan qa-smoke. Y cada noche, a una hora fija, se dispara automáticamente el plan de regresión completa.

Estado de desarrollo: requiere el mismo motor determinístico que el Modelo 2, más una integración con la herramienta de CI/CD (GitHub Actions, GitLab CI o Bitbucket Pipelines) que ejecute ese motor de forma automática ante cada evento. Esa integración es la "Fase 3" del roadmap, planificada para después de la Fase 2.

5. ¿Cuál modelo uso hoy, en la práctica?

Situación Modelo a usar hoy
Quiero pedirle algo puntual al asistente en Claude Code, sin seguir una receta fija Modelo 1 — simplemente pedíselo en lenguaje natural
Necesito hacer algo que se repite seguido (bootstrap de proyecto, smoke test post-deploy, regresión de un módulo, demo) y quiero que salga siempre igual Modelo 3 — buscá el playbook correspondiente en playbooks/ y seguilo paso a paso
Quiero que un comentario en un PR o un evento ambiguo dispare automáticamente el plan correcto Modelo 2 — en desarrollo, es roadmap
Quiero que cada push o cada noche dispare pruebas automáticas sin que nadie las pida Modelo 4 — en desarrollo, es roadmap

6. Los Modelos 2 y 4 se están desarrollando

Los cuatro modelos usan las mismas skills de base. La diferencia es que los Modelos 2 y 4 necesitan además un componente que hoy está en construcción: un motor (engine) de software que ejecute planes ya escritos de forma exactamente reproducible, sin usar el criterio del asistente de IA para decidir la coreografía.

Ese motor ya está completamente diseñado en el plan técnico del proyecto, y construirlo es un trabajo de desarrollo dividido en dos etapas:

Etapa (roadmap) Qué habilita Estado
Fase 2 — Motor (engine) propio Modelo 2 (híbrido adaptativo) En desarrollo
Fase 3 — Integración con CI/CD (GitHub, GitLab, Bitbucket) Modelo 4 (declarativo puro) En el roadmap, arranca después de la Fase 2

Esto no es un impedimento para trabajar hoy: con los Modelos 1 y 3 ya se puede cubrir tanto el trabajo interactivo del día a día como los workflows repetibles más comunes del equipo de QA.

7. Resumen visual comparativo

                     ¿QUIÉN DECIDE EL FLUJO?
                            │
        ┌───────────────────┼───────────────────┐
        │                   │                   │
   Una persona          El asistente         Una regla fija
   (con anticipación)   de IA                (sin decidir nada
        │                   │                 en el momento)
        ▼                   ▼                   ▼
   MODELO 3            MODELO 1 / 2         MODELO 4
   (playbook)          (improvisado /       (declarativo)
                        híbrido adaptativo)

                     ¿QUIÉN EJECUTA?
        ┌───────────────────┬───────────────────┐
        │                   │
   El asistente         Un motor de software
   de IA                (código, determinístico)
        │                   │
        ▼                   ▼
   MODELO 1 y 3         MODELO 2 y 4
   (disponibles hoy)    (en desarrollo, roadmap)

8. Problemas comunes (y qué hacer)

Lo que ves Por qué puede pasar Qué hacer
Le pedís al asistente algo puntual y dos corridas sobre el mismo pedido no dan exactamente el mismo resultado Estás usando el Modelo 1, que por diseño improvisa el flujo cada vez Si necesitás que el resultado sea siempre igual, usá un playbook (Modelo 3) en vez de un pedido libre
Alguien te pide "que se corra solo cada vez que se sube código" Eso corresponde al Modelo 4, que está en desarrollo Por ahora, correlo manualmente con el Modelo 3 (playbook) o pedíselo puntualmente con el Modelo 1, hasta que el motor esté listo
Buscás un "clasificador automático" que elija el plan según un comentario ambiguo Eso corresponde al Modelo 2, que está en desarrollo Por ahora, una persona interpreta el pedido y elige manualmente el playbook correspondiente (equivalente a Modelo 3)
No encontrás el playbook que necesitás en playbooks/ Puede que ese workflow específico todavía no tenga un playbook escrito Usá el Modelo 1 (pedido puntual al asistente) mientras se escribe el playbook correspondiente