Claude Code para Testers
Guía Completa y Recursos Gratuitos

0. ¿Qué es un LLM?

Antes de hablar de Claude Code, necesitás entender qué hay debajo. Un LLM (Large Language Model) es un modelo de inteligencia artificial entrenado con enormes cantidades de texto — código, documentación, libros, artículos, conversaciones — para predecir cuál es la respuesta más útil dado un input en lenguaje natural.

No "piensa" como una persona, pero sí reconoce patrones, entiende contexto y genera respuestas coherentes. Claude (Anthropic), GPT-4 (OpenAI) y Gemini (Google) son todos LLMs. Claude Code es una interfaz especializada que usa Claude como motor.

1. ¿Qué es Claude Code?

Claude Code es el CLI oficial de Anthropic — la empresa detrás de Claude — que convierte el modelo de IA en un agente de ingeniería de software que opera directamente desde tu terminal. No es autocompletado, no es solo un chat: es un agente que puede leer archivos, escribir código, ejecutar comandos, navegar repositorios y completar tareas complejas de forma autónoma.

Fue lanzado en 2025 y desde entonces ha ganado adopción masiva en equipos de ingeniería por su capacidad de trabajar con contexto completo del codebase, no solo con snippets aislados.

npm install -g @anthropic-ai/claude-code

# Verificar instalación
claude --version

# Iniciar en tu proyecto de testing
cd mi-proyecto-tests
claude

2. Claude Code vs otras herramientas IA

Hay múltiples herramientas de IA para desarrollo. Entender la diferencia es crítico para usarlas correctamente en testing.

3. El ecosistema: Skills, Agentes, MCP y Plugins

Cuando empezás a usar Claude Code, escuchás términos que pueden confundir: skill, agente, MCP, plugin. No son sinónimos — cada uno tiene un rol distinto. Acá te explico cada uno con ejemplos concretos de testing.

3. Cursos gratuitos disponibles

El ecosistema de aprendizaje para Claude Code y IA en testing está creciendo rápido. Aquí los recursos gratuitos más valiosos organizados por tipo.

4. Casos de uso en testing

Claude Code tiene aplicaciones concretas en todas las fases del ciclo de testing. Aquí el mapa completo de dónde y cómo usarlo.

6. Pirámide del testing con IA

La pirámide del testing define cuántos tests de cada tipo debería tener tu suite. Claude Code puede ayudarte en todos los niveles, pero el tipo de ayuda varía. Entender esto te dice qué pedirle según la tarea que tenés.

Prompts por nivel de la pirámide

Tengo esta función en TypeScript:

[pegá el código de la función aquí]

Generá tests unitarios con Jest que cubran:
- Happy path con valores válidos
- Valores límite (mínimo, máximo, exacto)
- Casos de error esperados
- Inputs nulos, undefined y string vacío
Usá describe/it, nombres en español y mocks donde corresponda.

Tengo este endpoint REST:
POST /api/users
Body: literal email, name, role literal
Respuesta exitosa: 201 + literal id, email, name, createdAt literal

Generá tests con Supertest que validen:
- 201 con datos válidos
- 400 con email inválido o formato incorrecto
- 409 si el email ya está registrado
- 422 si faltan campos requeridos
- 401 sin token de autenticación
Incluí assertions sobre el body y los headers de respuesta.

Tengo este flujo de usuario:
1. Usuario va a /checkout
2. Completa formulario de envío
3. Ingresa tarjeta de crédito
4. Confirma la compra
5. Ve pantalla de confirmación con número de orden

Generá un test E2E con Playwright que:
- Use Page Object Model (una clase por página)
- Tenga datos de prueba en un archivo fixtures/checkout.json
- Valide mensajes de éxito y número de orden
- Use selectores data-testid (no clases CSS)
- Incluya screenshot en caso de fallo

Necesito un script de k6 para el endpoint:
GET /api/products?category=electronics

Configurar:
- Ramp-up de 2 minutos hasta 100 usuarios virtuales
- Steady state de 5 minutos a 100 VUs
- Ramp-down de 1 minuto
- Thresholds: p95 menor a 500ms, error rate menor a 1%

Incluir:
- Métricas personalizadas (custom trends)
- Checks para status code y tiempo de respuesta
- Datos de categoría parametrizados

7. Leer HUs y generar datos de prueba

Dos tareas que los testers hacen todos los días y que la IA puede acelerar drásticamente: analizar Historias de Usuario para encontrar ambigüedades antes de escribir una línea de código, y generar datos de prueba variados y realistas.

7.1 Leer y mejorar Historias de Usuario

Una HU mal escrita produce tests incorrectos y bugs en producción. Claude puede detectar criterios de aceptación ambiguos, casos borde no contemplados y preguntas que deberías hacerle al PO antes de empezar.

Analizá esta Historia de Usuario como un QA Senior:

[pegá la HU completa]

Identificá:
1. Criterios de aceptación incompletos o ambiguos
2. Casos borde no mencionados
3. Flujos alternativos que faltan
4. Preguntas que debería responder el PO antes de desarrollar
5. Dependencias técnicas que podrían afectar el testing

Formateá la respuesta como una lista de observaciones ordenadas por prioridad.

Tengo esta HU con criterios de aceptación vagos:

[pegá la HU]

Reescribí los criterios de aceptación usando el formato:
DADO [contexto inicial]
CUANDO [acción del usuario]
ENTONCES [resultado esperado]

Agregá también criterios para:
- El caso donde algo falla
- Validaciones de campos
- Estados de carga y error en la UI

Con base en esta HU:

[pegá la HU]

Generá una tabla de casos de prueba con estas columnas:
| ID | Nombre | Precondición | Pasos | Resultado esperado | Prioridad |

Incluí casos para:
- Happy path (flujo principal exitoso)
- Validaciones de formulario (campos vacíos, formato inválido)
- Límites (máximo de caracteres, valores extremos)
- Permisos (usuario sin acceso, sesión expirada)
- Concurrencia si aplica

7.2 Generar datos de prueba

Los datos de prueba malos generan falsos positivos. Claude puede generar conjuntos de datos variados, realistas y que cubran casos borde que vos no pensarías en el momento.

Tengo un formulario de registro con estos campos:
- Nombre completo (texto, requerido, 2-100 caracteres)
- Email (formato válido, requerido, único)
- Teléfono (formato argentino, opcional)
- Fecha de nacimiento (mayor de 18 años, requerido)
- Contraseña (mínimo 8 chars, 1 mayúscula, 1 número)

Generá un dataset de 20 registros que incluya:
- 5 casos válidos variados (nombres con acentos, apellidos compuestos)
- 5 casos con email inválido (formatos distintos)
- 3 casos con teléfono en diferentes formatos
- 3 casos con fecha de nacimiento límite (exactamente 18 años)
- 4 casos con contraseña inválida (distintas reglas violadas)

Formateá como JSON array.

Necesito datos de prueba para testear una API de e-commerce.

Endpoint: POST /api/orders
Schema: { userId, items: [{productId, qty, price}], shippingAddress, paymentMethod }

Generá:
1. 3 órdenes válidas con distintas combinaciones de items
2. Órdenes con valores límite (1 item, 50 items, qty = 0, qty = 999)
3. Órdenes con campos faltantes (cada campo faltante en un caso separado)
4. Órdenes con tipos de dato incorrectos (string donde va number, etc.)
5. 2 casos con direcciones de envío en distintos países

Formato: JSON con un comentario por caso indicando qué valida.

Necesito un archivo CSV con datos de usuarios para un test de carga con k6.

Campos necesarios: username, password, email, region
Requisitos:
- 1000 registros únicos
- Usernames sin caracteres especiales
- Passwords que cumplan: 8+ chars, 1 mayúscula, 1 número
- Emails con dominios variados (gmail, hotmail, empresa.com)
- Regiones: distribución realista (40% LATAM, 30% USA, 30% Europa)

Generá los primeros 20 como ejemplo y dame el script de Node.js
para generar los 1000 completos.

5. Generación de test cases con IA

Una de las tareas más tediosas en testing es derivar test cases exhaustivos de un requisito. Claude Code puede hacerlo en segundos, con cobertura de happy paths, edge cases, escenarios negativos y condiciones de frontera.

Lee el archivo src/auth/login.service.ts y genera:
1. Feature file BDD en Gherkin para login
2. Incluye: happy path, contraseña incorrecta,
   usuario no existe, cuenta bloqueada, rate limiting
3. Formato Cucumber compatible con nuestro setup

Feature: User Authentication - Login
  As a registered user
  I want to log in to the platform
  So that I can access my account

  Background:
    Given the application is running
    And the database is seeded with test users

  Scenario: Successful login with valid credentials
    Given I am on the login page
    When I enter valid email "user@test.com"
    And I enter valid password "SecurePass123!"
    And I click the login button
    Then I should be redirected to the dashboard
    And I should see a welcome message

  Scenario: Failed login with incorrect password
    Given I am on the login page
    When I enter valid email "user@test.com"
    And I enter incorrect password "WrongPass"
    And I click the login button
    Then I should see error "Invalid credentials"
    And I should remain on the login page
    And the failed attempt should be logged

  Scenario: Failed login with non-existent user
    Given I am on the login page
    When I enter non-existent email "ghost@test.com"
    And I enter any password "AnyPass123"
    And I click the login button
    Then I should see error "Invalid credentials"
    And the response time should be similar to valid user (anti-enumeration)

  Scenario: Login blocked after 5 failed attempts
    Given I am on the login page
    And I have failed login 4 times with email "user@test.com"
    When I fail a 5th login attempt
    Then I should see error "Account temporarily locked"
    And I should not be able to attempt login for 15 minutes

  Scenario Outline: Rate limiting on login endpoint
    Given I am on the login page
    When I make <attempts> login attempts in <seconds> seconds
    Then I should receive a 429 Too Many Requests response
    Examples:
      | attempts | seconds |
      | 10       | 60      |
      | 5        | 10      |

6. Automatización de scripts de testing

Claude Code puede generar, depurar y refactorizar scripts de automatización — Playwright, Cypress, Selenium — con conocimiento completo de tu proyecto: configuración, helpers existentes, Page Objects, variables de entorno.

Tenemos un flujo de checkout en React. Lee los componentes
en src/pages/checkout/ y genera un test Playwright E2E que:
- Navegue al carrito con 2 productos
- Complete el formulario de envío
- Ingrese datos de tarjeta de prueba (Stripe test mode)
- Verifique confirmación y número de orden
Usa los helpers que ya existen en tests/helpers/

import { test, expect } from '@playwright/test';
import { CartHelper, CheckoutHelper } from '../helpers';
import { TEST_CARDS } from '../fixtures/payment';

test.describe('Checkout Flow - E2E', () => {
  test.beforeEach(async ({ page }) => {
    await page.goto('/');
    await CartHelper.addProducts(page, [
      { sku: 'PROD-001', qty: 1 },
      { sku: 'PROD-002', qty: 2 }
    ]);
  });

  test('complete checkout with Stripe test card', async ({ page }) => {
    // Navigate to checkout
    await page.goto('/checkout');
    await expect(page.getByTestId('checkout-title')).toBeVisible();
    await expect(page.getByTestId('order-items')).toContainText('3 productos');

    // Fill shipping form
    await CheckoutHelper.fillShipping(page, {
      name: 'Test User',
      address: 'Calle Test 123',
      city: 'Buenos Aires',
      zip: '1000',
      country: 'AR'
    });

    // Payment with Stripe test card
    const stripeFrame = page.frameLocator('[name="stripe-card-element"]');
    await stripeFrame.locator('[placeholder="Número de tarjeta"]').fill(TEST_CARDS.visa);
    await stripeFrame.locator('[placeholder="MM / AA"]').fill('12/27');
    await stripeFrame.locator('[placeholder="CVC"]').fill('123');

    // Place order
    await page.getByRole('button', { name: 'Confirmar pedido' }).click();

    // Verify confirmation
    await expect(page).toHaveURL(/\/orders\/\d+\/confirmation/);
    const orderNumber = await page.getByTestId('order-number').textContent();
    expect(orderNumber).toMatch(/^ORD-\d{8}$/);
    await expect(page.getByTestId('success-message')).toBeVisible();
  });
});

7. Performance testing con Claude Code

El performance testing es donde Claude Code brilla especialmente porque los scripts son complejos, la sintaxis varía por herramienta y los patrones de carga (ramp-up, steady state, spike) requieren razonamiento estructurado.

Ejemplo: script k6 generado

Genera un test de k6 para la API /api/search:
- 0 → 100 VU en 2 min (ramp-up)
- Steady state: 100 VU por 5 min
- Ramp-down: 100 → 0 en 1 min
- Threshold: p95 < 500ms, error rate < 1%
- Headers de autenticación JWT del .env

import http from 'k6/http';
import { check, sleep } from 'k6';
import { Trend, Rate } from 'k6/metrics';

const searchDuration = new Trend('search_duration');
const errorRate = new Rate('error_rate');

export const options = {
  stages: [
    { duration: '2m', target: 100 },  // ramp-up
    { duration: '5m', target: 100 },  // steady state
    { duration: '1m', target: 0 },    // ramp-down
  ],
  thresholds: {
    'search_duration': ['p(95)<500'],
    'error_rate': ['rate<0.01'],
    'http_req_duration': ['p(95)<500'],
  },
};

const BASE_URL = __ENV.API_BASE_URL || 'https://api.example.com';
const JWT_TOKEN = __ENV.JWT_TOKEN;

const searchTerms = ['laptop', 'smartphone', 'tablet', 'headphones'];

export default function () {
  const term = searchTerms[Math.floor(Math.random() * searchTerms.length)];

  const res = http.get(`${BASE_URL}/api/search?q=${term}&limit=20`, {
    headers: {
      'Authorization': `Bearer ${JWT_TOKEN}`,
      'Content-Type': 'application/json',
    },
  });

  const success = check(res, {
    'status is 200': (r) => r.status === 200,
    'has results': (r) => JSON.parse(r.body).results?.length > 0,
    'response time OK': (r) => r.timings.duration < 500,
  });

  searchDuration.add(res.timings.duration);
  errorRate.add(!success);

  sleep(1);
}

8. Análisis de resultados con Claude Code

Los reportes de testing (Gatling HTML, JUnit XML, JSON de k6, logs de Playwright) contienen información valiosa pero difícil de interpretar rápidamente. Claude Code puede leerlos, identificar patrones y generar resúmenes ejecutivos.

Lee el archivo target/gatling/simulation-20260309/simulation.log
y dime:
1. ¿Cuáles requests superaron el SLA de 800ms p95?
2. ¿Hay errores > 1% en algún endpoint?
3. ¿En qué minuto se observó el pico de latencia?

Tengo dos reportes: baseline.json y after-deploy.json
Compara p50, p95, p99 y error rate entre ambos.
¿Hay regresión de performance en el deploy?
Genera tabla comparativa y recomendación.

Este es el stack trace del test que falló en CI.
Lee también el código en src/services/payment.service.ts
Genera un bug report Markdown listo para Jira con:
- Descripción, pasos para reproducir, logs relevantes

9. Skills para testing

Los Claude Code Skills son archivos Markdown que instalas una vez en ~/.claude/skills/ o en .claude/skills/ del proyecto. Contienen instrucciones especializadas que el agente aplica automáticamente cuando el contexto lo requiere.

# Instalar skill desde GitHub
git clone https://github.com/rcampos09/performance-testing-skills
cp performance-testing-skills/.claude/skills/* ~/.claude/skills/

# O crear tu propio skill
mkdir -p ~/.claude/skills
cat > ~/.claude/skills/qa-testing.md << 'EOF'
# QA Testing Expert
Trigger: cuando el usuario mencione "test", "QA", "testing", "automatización"
...instrucciones especializadas...
EOF

# CLAUDE.md — Proyecto de Testing

## Stack de testing
- Framework: Playwright + TypeScript
- Unit tests: Jest + Testing Library
- Performance: Gatling (Java DSL)
- Reports: Allure + HTML reports en /reports/

## Convenciones
- Page Objects en tests/pages/
- Fixtures en tests/fixtures/
- Helpers en tests/helpers/
- Nunca generar datos hardcodeados, usar faker

## SLAs de performance
- p95 < 500ms para APIs
- p95 < 2000ms para flujos E2E
- Error rate < 0.5%

## Comandos
- npm test → Jest unit tests
- npm run e2e → Playwright
- mvn gatling:test → Performance tests

10. Workflow práctico diario

Así luce un día típico de un tester que integra Claude Code en su workflow. El objetivo no es reemplazar criterio profesional — es eliminar el trabajo mecánico y enfocarse en lo que realmente importa.

11. Biblioteca de prompts para testers

Los prompts que realmente funcionan — probados en proyectos reales

La diferencia entre un tester que "prueba" Claude Code y uno que lo integra como herramienta profesional está en la calidad del prompt. Aquí los patrones que producen resultados de alta calidad, organizados por contexto. Cópialos, adáptalos a tu stack.

Lee el archivo docs/stories/US-142-checkout.md.
Genera test cases en Gherkin cubriendo:
- Happy path completo
- Validaciones de formulario (campos vacíos, formatos inválidos)
- Casos de borde (carrito vacío, stock insuficiente, producto discontinuado)
- Escenarios de error de red y timeout
Formato: un Feature file por módulo funcional.
Idioma: español.

Lee todos los archivos en tests/e2e/ y tests/unit/.
Compara contra los requisitos en docs/requirements.md.
Genera un reporte de coverage cualitativo que identifique:
1. Funcionalidades no cubiertas o parcialmente cubiertas
2. Test cases redundantes (mismo escenario en varios tests)
3. Prioridad de qué implementar primero según riesgo de negocio

Lee el componente src/pages/LoginPage.tsx.
Crea un Page Object para Playwright en TypeScript siguiendo el patrón
de los Page Objects existentes en tests/pages/.
Incluye métodos para:
- navigate(), fillEmail(), fillPassword(), submit(), getErrorMessage()
- waitForNavigation() post-login exitoso
No uses selectores CSS frágiles; prioriza data-testid > role > text.

Usando el Page Object en tests/pages/CheckoutPage.ts,
genera un test Playwright completo para el flujo de compra.
Usa los fixtures de usuario en tests/fixtures/users.json.
El test debe:
- Ser independiente (no depender de estado previo)
- Limpiar datos después de ejecutarse
- Tener assertions en cada paso crítico
- Seguir el patrón AAA (Arrange, Act, Assert)

Este test falla intermitentemente en CI pero pasa en local.
Aquí el log de la última falla: [pega el log]
Aquí el test: [pega el código]
Analiza causas posibles de flakiness:
- Race conditions / timing issues
- Dependencias de estado externo
- Selectores no estables
Propone el fix y explica el trade-off de cada opción.

Lee el archivo docs/api/openapi.yaml.
Genera un test de Gatling en Java DSL para los endpoints del módulo /api/orders.
Patrón de carga: ramp 0→200 VU en 3 min, steady 5 min, ramp-down 2 min.
Thresholds definidos en CLAUDE.md.
Incluye:
- Feeders con datos de prueba realistas (CSV)
- Checks de status code y tiempo de respuesta
- Autenticación JWT usando variable de entorno PERF_TOKEN

Tengo dos archivos JSON de resultados de k6:
- baseline.json (antes del deploy)
- current.json (después del deploy)
Compara p50, p95, p99 y error rate para cada endpoint.
Genera:
1. Tabla comparativa Markdown
2. Lista de endpoints con regresión > 20%
3. Recomendación: ¿bloquear el deploy o permitirlo con monitoreo?
Basa la recomendación en los SLAs de CLAUDE.md

Lee el archivo src/api/routes/payments.ts.
Genera tests de contrato usando Pact (consumer-driven) para el endpoint POST /api/payments.
Incluye:
- Casos de pago exitoso, fondos insuficientes, tarjeta inválida
- Validación de esquema JSON de respuesta
- Headers requeridos (Content-Type, X-Request-ID)
Guarda el contrato en tests/contracts/payments.pact.json

Lee el OpenAPI spec en docs/api/openapi.yaml.
Genera una colección Postman v2.1 con:
- Variables de entorno para baseUrl, token, userId
- Pre-request scripts para generar tokens JWT de prueba
- Tests de validación en cada request (status, schema, tiempo)
- Orden lógico de ejecución para el flujo completo de órdenes
Exporta como orders-collection.json en docs/postman/

Lee el schema de base de datos en src/db/schema.sql,
específicamente las tablas users, orders y products.
Genera un script SQL de seed con:
- 500 usuarios con datos demográficos realistas para Argentina
- 2000 órdenes distribuidas en los últimos 6 meses
- Incluir casos edge: usuarios sin órdenes, órdenes sin items, estados en conflicto
- Respetar todas las constraints de FK del schema
Guarda en tests/fixtures/seed-perf.sql

12. Errores comunes al usar Claude Code en testing

Los anti-patrones que arruinan la calidad de los tests generados

Después de usar Claude Code en proyectos reales de testing, estos son los errores que se repiten. No son fallas de la IA — son fallas en la forma de usarla. Identificarlos temprano te ahorra horas de deuda técnica de tests.

// ❌ Assertion inútil
expect(response.status).toBeDefined();
expect(response.body).not.toBeNull();
expect(data.length).toBeGreaterThan(-1);

// ✅ Assertions con valor
expect(response.status).toBe(201);
expect(data.orderId).toMatch(/^ORD-\d{8}$/);
expect(data.total).toBe(199.99);
expect(data.items).toHaveLength(2);

// ❌ Selector frágil
await page.click('.btn.btn-primary.checkout');
await page.fill('input:nth-child(3)', email);
await page.click('#app > div > main > form > button');

// ✅ Selector robusto
await page.getByTestId('checkout-btn').click();
await page.getByLabel('Email').fill(email);
await page.getByRole('button', { name: 'Pagar' }).click();

13. Buenas prácticas

14. Recursos y referencias