how-it-works · agentic-qa · sprint-testing

La Trifuerza — Probar Features por Capas

UI · API · DB. Pruebes lo que pruebes en una feature o historia de usuario, piensas SIEMPRE en las tres capas: una pantalla verde puede esconder una API rota y un trigger que falla en silencio. Smoke primero, luego las tres capas, con sondas de seguridad e integridad.

qué cubriremos

Probar Toda Feature, por Capas

3 quizzes interactivos a lo largo del recorrido — haz clic en las respuestas.

el modelo

Tres Capas, Tres Verdades

tres ejes, no uno

Capas · Niveles · Tipos

La Trifuerza es UN eje: las capas — dónde sondeas (UI · API · DB). Es ortogonal a otros dos ejes que el tester decide en cada prueba. No compiten: se combinan.

en orden, ≤10 min

El Checklist de Smoke

el veredicto y sus reglas

Go / No-Go

dos preguntas distintas

Smoke ≠ Testing Profundo de la Feature

el loop por cada AC

Navega → Observa → Captura

el checklist por input / interacción

Edge Cases de la Capa UI

donde se esconden los defectos

Transiciones Inválidas — el Punto Ciego

Para cualquier entidad con estado (draft→submitted→approved, cart→paid→shipped): dispara cada transición válida, luego dispara una que el estado actual debería rechazar.

cuándo bajar una capa

Cuándo Escalar a API / DB

descubrir + autenticar

Preparar el Testing de la Capa API

# credenciales SIEMPRE desde .env — nunca hardcodear
POST /auth/v1/token
  body: { email: {{env.STAGING_USER_EMAIL}}, password: {{env.STAGING_USER_PASSWORD}} }
  store: access_token, refresh_token, user.id

# registra los endpoints del ticket en una tabla en memory:
# | Method | Endpoint | Purpose | AC |

cada status PRUEBA algo

La Matriz de Status Codes

la sonda de seguridad que casi nadie corre

Sonda de RLS / Autorización — A/B

Crítica para apps multi-tenant. Dos usuarios (A, B), el mismo rol. La pregunta: ¿puede A tocar lo de B?

1. A lista recursos              → solo las filas de A
2. A lee resource?user_id=eq.B   → array vacío o 403
3. A hace PATCH a la fila de B    → 0 filas afectadas o 403

# resultado por sonda:  VERIFIED  o  VULNERABLE

el handoff cross-layer

Un 201 No Prueba la DB

quiz · smoke + UI + API

Las Capas de Arriba

después de una acción API / UI

Verificación de Estado

la lógica invertida

Sondas de Constraints — el Éxito es el Bug

barridos de integridad

Cazar Datos Corruptos

-- huérfanos: hijos sin padre
SELECT c.* FROM child c LEFT JOIN parent p ON c.fk=p.id WHERE p.id IS NULL;

-- calc mismatch: total guardado ≠ suma real
SELECT o.id, o.total, COALESCE(SUM(i.qty*i.unit_price),0) AS calc
FROM orders o LEFT JOIN order_items i ON o.id=i.order_id
GROUP BY o.id, o.total HAVING o.total != calc;

-- estados de dominio imposibles
SELECT * FROM orders WHERE status='delivered' AND payment_status!='completed';

RLS real + cascadas

RLS a Nivel SQL y Limpieza

BEGIN;
SET LOCAL request.jwt.claim.sub = '{user-a}';
SELECT * FROM {table}; -- solo filas de A
ROLLBACK;

quiz · capa DB

La Verdad Persistida

la pausa graduada

Bloqueante vs No-Bloqueante

Un FAIL durante el testing de la feature no es automáticamente Critical y no detiene la pasada por sí solo. Triagea primero, luego decide.

probar el tiempo sin esperar

Casos Dependientes del Tiempo (TTL)

Magic links, OTPs, tokens, sesiones, caches: "a las 14:59 funciona, a las 15:01 no". No se prueban haciendo clic más rápido — necesitas controlar el tiempo. Elige la opción más alta que el stack permita.

cerrar la pasada con rigor

Sin NOT RUN · Evidencia que Sirve

quiz · disciplina

El Oficio de la Pasada

todo junto

La Pasada Completa de Testing de una Feature

• Smoke primero — Go/No-Go del ambiente, ≤10 min, siempre revisa la red.
• Capas por tipo de feature — el orden lo decide qué cambió; cada capa prueba su verdad.
• Triagea cada finding — bloqueante detiene, no-bloqueante registra y sigue.
• Cierra con rigor — sin NOT RUN, evidencia en el estado de fallo, Findings al handoff de Stage 3.

el checklist del tester

Cómo Hacerlo Bien

para llevar

Tres Ideas que se Quedan