Estrategia QA, Testing y CI/CD MVP

Paraguas QA sobre toda la cadena operativa FARO

FARO Connect no es una landing. Es una cadena operativa que va de datos a Score a reportes pasando por reglas, tensiones, acciones, evidencia, workflow, timeline, alertas e IA. La estrategia QA del MVP cubre cada eslabón y todos los eslabones funcionando juntos.

Distribución 35 / 30 / 20 / 10 / 5

Una pirámide práctica, no aspiracional. No conviene arrancar con 200 tests E2E lentos: queda muy lindo hasta que el pipeline tarda 45 minutos y todos lo saltean. La herramienta de calidad no debe volverse enemiga de la calidad.

Cada capa cubre un eslabón de la cadena

Cualquier release del MVP debe ejecutar las 12 capas. No están ordenadas por prioridad sino por orden lógico de ejecución dentro del pipeline: lo rápido y barato primero (typecheck, lint, unit) y lo lento o frágil al final (smoke pre-demo).

Lo que bloquea merge a main

Cada gate es una condición binaria: pasa o no pasa. Los 11 bloqueantes impiden merge si fallan; los 2 de advertencia son ruido controlado que se revisa por humano. Política sin excepciones: main no recibe código que rompa gates críticos.

Cinco ambientes, una matriz clara

Cada ambiente tiene un propósito específico y un subconjunto de capas que corre. Lo que se muestra a un socio técnico debe correr en staging o local reproducible. Screenshots sirven; sistema corriendo convence.

Base QA reproducible y deterministic

Sin dataset demo controlado no hay QA serio. Datos sueltos no alcanzan: hace falta datos con resultado esperado. Cuyo S.A. cumple ese papel para todo el MVP.

{
  "company_code": "EMP-DEMO-CUYO",
  "company_name": "Empresa Demo Cuyo S.A.",
  "period": "2026-05",
  "score": {
    "current": 66,
    "previous": 74,
    "delta": -8,
    "status": "warning",
    "confidence_min": 80
  },
  "components": {
    "kpi_health": 20,
    "tension_health": 14,
    "execution_health": 12,
    "evidence_health": 10,
    "governance_health": 10
  },
  "required_drivers": [
    "TNS-001",
    "TNS-004",
    "ACTION_EXPIRED",
    "EVIDENCE_MISSING"
  ]
}

GitHub Actions · cuatro workflows en cadena

El pipeline se divide en cuatro workflows: lint, test, build y deploy. En cada PR corre el bloque hasta build; en merge a main se suma integration + E2E + deploy a staging; en release production se ejecuta el flujo completo con backup pre-release y monitoreo post-deploy.

7.1 · Workflow CI principal

name: FARO CI

on:
  pull_request:
    branches: [main]
  push:
    branches: [main]

jobs:
  quality:
    runs-on: ubuntu-latest

    services:
      postgres:
        image: postgres:16
        env:
          POSTGRES_USER: faro
          POSTGRES_PASSWORD: faro
          POSTGRES_DB: faro_test
        ports:
          - 5432:5432
        options: >-
          --health-cmd pg_isready
          --health-interval 10s
          --health-timeout 5s
          --health-retries 5

      redis:
        image: redis:7
        ports:
          - 6379:6379

    env:
      DATABASE_URL: postgresql://faro:faro@localhost:5432/faro_test
      REDIS_URL: redis://localhost:6379
      NODE_ENV: test

    steps:
      - name: Checkout
        uses: actions/checkout@v4

      - name: Setup Node
        uses: actions/setup-node@v4
        with:
          node-version: 20

      - name: Enable pnpm
        run: corepack enable

      - name: Install dependencies
        run: pnpm install --frozen-lockfile

      - name: Lint
        run: pnpm lint

      - name: Typecheck
        run: pnpm typecheck

      - name: Run migrations
        run: pnpm db:migrate:test

      - name: Seed Cuyo S.A.
        run: pnpm db:seed:test

      - name: Unit tests
        run: pnpm test:unit

      - name: SQL and RLS tests
        run: pnpm test:sql

      - name: API tests
        run: pnpm test:api

      - name: UI tests
        run: pnpm test:ui

      - name: Build
        run: pnpm build

7.2 · Workflow staging + E2E

name: FARO Staging E2E

on:
  workflow_dispatch:
  push:
    branches: [main]

jobs:
  e2e:
    runs-on: ubuntu-latest

    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: 20

      - run: corepack enable
      - run: pnpm install --frozen-lockfile

      - name: Install Playwright
        run: pnpm playwright install --with-deps

      - name: Run E2E smoke (10 flujos críticos)
        env:
          BASE_URL: https://staging.faro-connect.example
        run: pnpm test:e2e:smoke

      - name: Demo-check sobre Cuyo
        env:
          DATABASE_URL: ${{ secrets.STAGING_DATABASE_URL }}
        run: pnpm qa:demo-check

7.3 · Scripts package.json

{
  "scripts": {
    "lint": "eslint .",
    "typecheck": "tsc --noEmit",
    "test": "vitest run",
    "test:unit": "vitest run tests/unit",
    "test:sql": "vitest run tests/sql",
    "test:api": "vitest run tests/api",
    "test:integration": "vitest run tests/integration",
    "test:ui": "vitest run tests/ui",
    "test:e2e": "playwright test",
    "test:e2e:smoke": "playwright test tests/e2e/smoke",
    "test:ci": "pnpm lint && pnpm typecheck && pnpm test:unit && pnpm test:sql && pnpm test:api && pnpm test:ui && pnpm build",
    "db:migrate:test": "node scripts/db/migrate-test.ts",
    "db:seed:test": "node scripts/db/seed-test.ts",
    "db:reset:test": "node scripts/db/reset-test.ts",
    "qa:demo-check": "node scripts/qa/demo-check.ts"
  }
}

30 items que valen oro

Antes de mostrar FARO a Horacio, socio técnico, inversor o director, recorrer este checklist completo. La demo siempre falla donde uno dijo “eso no hace falta probarlo”. Ley de Murphy, pero con JavaScript.

Cinco niveles con respuesta y resolución medibles

Cada bug tiene severidad asignada en el momento del triage. La severidad determina SLA de respuesta y SLA de resolución objetivo. No es burocracia: es lo que evita que un P0 quede en el backlog mientras se discute un P3.

9.1 · Workflow de bug fix

Casos que nunca se pueden romper

La regression suite ejecuta automáticamente en cada release. Es la red de seguridad: si un cambio rompe alguno de estos casos, el release se cancela. Son los casos cuya rotura humilla en una demo.

Pre-release · release · post-release

Tres bloques secuenciales que protegen cada publicación. Las casillas se completan en orden; ningún bloque arranca hasta que el anterior está en verde.

{
  "release": "0.3.0-mvp",
  "commit": "abc123def456",
  "migrations": "V001-V109",
  "seed_version": "EMP-DEMO-CUYO v1.2",
  "score_model": "FARO_SCORE_MVP v1",
  "ai_prompts": [
    "AI-EXPLAIN-SCORE v1",
    "AI-EXPLAIN-TENSION v1",
    "AI-EXPLAIN-ACTION v1"
  ],
  "demo_dataset": "EMP-DEMO-CUYO v1",
  "rollback_to": "0.2.7-mvp",
  "released_at": "2026-05-31T18:00:00-03:00"
}

Qué cubre cada documento del paraguas

Tres documentos componen la estrategia QA del MVP. Saber qué cubre cada uno evita duplicar cobertura y evita huecos donde nadie probó nada.

Dónde se cruza esta estrategia con el resto del pack

La estrategia QA no vive sola. Consume catálogos canónicos, valida motores y se apoya en piezas de gobierno, observabilidad y deploy. Las marcadas PENDIENTE aún están en construcción.