/test-automation

el mapa — índice mental del deck

Plan → Code → Review, con sus gates

Cada fase del mapa = una sección de este deck, en el mismo orden.

antes de nada — qué entra y a qué tamaño

Elige el scope primero, una sola vez

Ante la duda, PREGUNTA al usuario. Nunca asumas "module" solo porque aparecen varios IDs de TC en el briefing.

gate 0 · readiness preflight — MANDATORY, corre antes que todo

¿Está todo listo para escribir y correr código?

phase 0 · resume check — inline, <1 minuto

¿Hay una sesión previa? Retómala, no la repitas

phase 1 · plan — lo que se lee, en este orden

El manifest primero; la Story completa, después

• kata-manifest.json (root). Cruza cada TC ID contra los @atc existentes y cada nombre de componente contra el registro. ¿Coincide? Reusa o extiende — NUNCA dupliques. Husky lo refuerza en pre-commit.
• Doctrina KATA. references/kata-architecture.md + typescript-patterns.md — capas, identidad del ATC, fixtures, aliases.
• tests/components/. Las formas Api / Page / Steps que ya existen en disco — naming y patrones a seguir.
• La Story sincronizada. bun run jira:sync-issues get <KEY> --include-comments → lee la carpeta ENTERA: ACs, scope, business rules Y comments.md. NUNCA acli view para customfield_* (devuelve null).
• El ATP, según modalidad. jira-native: campo del Story → acceptance-test-plan.md. jira-xray: description del Test Plan issue → test-plans/…md.
• api/schemas/ + .env. Types de OpenAPI (refresca con bun run api:sync); credenciales vía config.testUser — jamás hardcodear.

phase 1 · plan — lo que se escribe, y el gate humano

Un plan que responde 5 preguntas — y espera tu sí

• 1 · Escenarios: ¿cuáles se vuelven tests, cuáles ATCs, cuáles preconditions compartidas (Steps)?
• 2 · Componentes: ¿qué *Api.ts / *Page.ts ya existen y cuáles se crean?
• 3 · Datos: clasificados Discover / Modify / Generate — nunca asumas que existen en staging.
• 4 · Fixture: {api}, {ui}, {test} o {steps}.
• 5 · Trazabilidad: qué ATC ID del TMS mapea a qué método del componente.

craft del plan · test-design doctrine — binding

Cubrir los ACs es el piso, no la meta

Canon: agentic-qa-core/references/test-design-doctrine.md — carga MANDATORY antes de derivar ATCs desde ACs. Nunca reportes "% de ACs verificados" como completitud.

craft del plan · estrategia de datos — se clasifica al PLANEAR

Discover → Modify → Generate (prioridad estricta)

phase 2 · code — orden de construcción innegociable

Types → componente → fixture → test → verificar

$ bun run test tests/e2e/checkout/processCheckout.test.ts   # ¿pasa? (0 retries)
$ bun run types:check                                       # tsc --noEmit, sin errores
$ bun run lint:check                                        # ESLint, sin errores
$ bun allure:agent                                          # opcional: reporte markdown por bloque @atc

Dispatch Sequential: un subagente de Code por unidad de scope (module: 1 por TC · ticket: 1 total). Cada uno carga /playwright-best-practices junto a esta skill; retorna archivos cambiados + resumen — el orquestador nunca lee diffs.

craft del code · la arquitectura — nunca colapses capas (T3)

Las capas KATA, de abajo hacia arriba

craft del code · selección de fixture — carga estructural

El fixture decide si se abre un browser

craft del code · las reglas que deciden el review

Reglas ATC — los rechazos más comunes

phase 2 · code — la forma de un componente API (L3)

Helper sin decorator, ATC con @atc

export class OrdersApi extends ApiBase {
  private readonly baseEndpoint = '/api/v1/orders';

  @step                                  // helper — read-only, sin @atc
  async getOrderById(id: string): Promise<[APIResponse, Order]> {
    return this.apiGET<Order>(`${this.baseEndpoint}/${id}`);
  }

  @atc('UPEX-411')                        // ATC — muta estado, trazado al TMS
  async createOrderSuccessfully(payload: CreateOrderRequest) {
    const [response, body, sent] = await this.apiPOST(this.baseEndpoint, payload);
    expect(response.status()).toBe(201);   // assertion FIJA — vive en el ATC
    expect(body.id).toBeDefined();
    return [response, body, sent];        // 3-tupla: permite encadenar
  }
}

GET / DELETE retornan 2-tuplas; POST / PUT / PATCH retornan 3-tuplas (comparar lo enviado vs lo recibido). Test files: {verb}{Feature}.test.ts e importan de @TestFixture, nunca de @playwright/test.

phase 3 · review — el gate de merge

Tres Verifiers en paralelo; cero blockers para aceptar

después del accept — git y ciclo de vida del TC

La skill se detiene en un review local limpio

Local gate green. Ready for /git-flow-master:
cut test/UPEX-411-checkout from the integration trunk, push, Sanity-CI, PR, merge --no-ff.

• Nada de git aquí. Branch, push y PR son trabajo de /git-flow-master — la skill solo anuncia el handoff, jamás lo auto-ejecuta.
• Bajo estrategia sdet (suites encadenadas): el gate local debe pasar en local Y staging antes del push; el Git Ledger se apendiza a progress.md tras cada acción de branch.
• Ciclo de vida del TC: → In Review cuando abre el PR del ticket hacia el trunk; → Automated SOLO cuando el PR final trunk → main mergea con CI verde. Mergear al trunk NO es "Automated".
• Transiciones vía /test-documentation + acli; nombres de estado contra .agents/jira-workflows.json.
• Después, en el pipeline: /regression-testing (Stage 6) corre las suites en CI y emite GO / CAUTION / NO-GO.

cierre — cómo invocarlo y qué deja

/test-automation — planéalo, codéalo por capas, pásalo en verde

← → navegar · O resumen · S presentador · N notas · F pantalla completa