Volver a Learning
Claude Code para Testers
🤖
Handbook
Claude Code
Recursos Gratuitos
Claude Code para Testers
Guía Completa y Recursos Gratuitos
Claude CodeTestingAIQA AutomationPerformanceGratis
Tabla de contenidos
1. ¿Qué es Claude Code?
🔍
Lectura de contexto completo
⚙️
Ejecución de comandos
🧠
Razonamiento multi-paso
🎯
Skills especializados
Instalación (requiere Node.js 18+)
npm install -g @anthropic-ai/claude-code
# Verificar instalación
claude --version
# Iniciar en tu proyecto de testing
cd mi-proyecto-tests
claude2. Claude Code vs otras herramientas IA
| Herramienta | Tipo | Contexto de codebase | Ejecuta comandos | Ideal para testing |
|---|---|---|---|---|
| Claude Code | Agente CLI | Completo | Sí | Scripts, análisis, refactor |
| GitHub Copilot | Autocompletado IDE | Parcial (archivo abierto) | No | Completar código de tests |
| ChatGPT / Claude.ai | Chat web | Solo lo que pegas | No | Ideas, consultas puntuales |
| Cursor / Windsurf | IDE con IA | Completo | Limitado | Edición con contexto |
| Gemini Code Assist | IDE Plugin | Parcial | No | Sugerencias en IDE |
La ventaja clave para testers
3. Cursos gratuitos disponibles
📚
Documentación Oficial — Claude Code
Gratisdocs.anthropic.com/claude-code → Plataforma: Web
🎓
Prompt Engineering for Developers — Anthropic + DeepLearning.AI
Gratisdeeplearning.ai → Plataforma: Web (100% gratis)
🎯
Generative AI for Everyone — Coursera
Audit gratiscoursera.org → Plataforma: Web (audit = gratis)
▶️
Canal oficial de Anthropic en YouTube
Gratisyoutube.com/@Anthropic → Buscar: "Claude Code"
anthropics/claude-code — Repositorio oficial
Gratisgithub.com/anthropics/claude-code → Issues y Discussions
🌐
Comunidad y blogs técnicos
Gratisdev.to, medium.com, reddit.com/r/ClaudeAI
Resumen de recursos por nivel
Principiante
Intermedio
Avanzado
4. Casos de uso en testing
CLAUDE
CODE
CODE
Generación de Test Cases
Tests Unitarios e Integración
E2E / UI Testing
API Testing
Performance Testing
Análisis y Reportes
📝
Generación de test cases
Análisis de requirements 🤖
Automatización E2E
Playwright / Cypress ⚡
Scripts de carga
Gatling / k6 / JMeter 🔍
Análisis de fallos
Debug automático 📊
Interpretación de reportes
Performance analysis 🧪
Generación de test data
Data generation5. Generación de test cases con IA
PROMPT
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 OUTPUT
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 |Tips para mejores resultados
6. Automatización de scripts de testing
Ejemplo: Playwright E2E desde cero
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();
});
});Playwright
E2E, cross-browser
Cypress
E2E, component tests
Selenium
Legacy, cross-browser
Jest / Vitest
Unit, integration
7. Performance testing con Claude Code
Definir escenario
Generar script
Ejecutar test
Analizar reporte
Fix & iterar
● Todo autónomo
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 .envimport 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);
} ⚡
¿Usas Gatling? Tenemos un skill dedicado
Ver Performance Testing Skills →8. Análisis de resultados con Claude Code
1
Leer el reporte de Gatling
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? 2
Comparar dos ejecuciones
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. 3
Generar bug report automático
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 relevantesEjemplo de análisis generado
🔴
SLA violation detectado
🟡
Pico detectado en minuto 7
🟢
Endpoints dentro de SLA
9. Skills para testing
Estructura de un skill
# 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 🧪
Crea tus propios skills de QA
Template CLAUDE.md para proyectos de testing
# 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 tests10. Workflow práctico diario
🌅
Mañana
Review de nuevas features en desarrollo
💻
Trabajo
Implementación de tests automatizados
🔄
CI/CD
Análisis de fallos en pipeline
📊
Cierre
Análisis de resultados del día
Generar test cases (10 req.)
3 h
15 min
Script load testing Gatling
2 h
10 min
Análisis reporte performance
60 min
5 min
Script Playwright E2E
90 min
12 min
Bug report documentado
30 min
3 min
11. Biblioteca de prompts para testers
Los prompts que realmente funcionan — probados en proyectos reales
La regla de oro del prompting para testing
Análisis de requisitos
De historia de usuario a test cases
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. Análisis de cobertura de tests existentes
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 Automatización E2E
Page Object desde componente React
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. Test E2E completo con fixtures
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) Debug de test flaky
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. Performance Testing
Script de carga desde OpenAPI spec
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 Análisis de regresión de performance
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 API Testing
Contrato de API con validación de esquema
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 Generación de colección Postman
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/ Test Data
Generar datos de prueba realistas
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.sql12. Errores comunes al usar Claude Code en testing
Los anti-patrones que arruinan la calidad de los tests generados
ERROR 01
Tests que siempre pasan (assertions débiles)
Lo que pasa
// ❌ Assertion inútil
expect(response.status).toBeDefined();
expect(response.body).not.toBeNull();
expect(data.length).toBeGreaterThan(-1);Cómo evitarlo
// ✅ 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); ERROR 02
Tests con dependencias ocultas entre sí
# Señales de alerta
• Tests que usan variables globales compartidas
• beforeAll que crea datos que múltiples tests consumen
• Tests que funcionan "solo si se ejecutan juntos"
ERROR 03
Selectores CSS frágiles en tests de UI
Frágil — rompe con cualquier refactor de CSS
// ❌ 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');Robusto — sobrevive a cambios de UI
// ✅ Selector robusto
await page.getByTestId('checkout-btn').click();
await page.getByLabel('Email').fill(email);
await page.getByRole('button', { name: 'Pagar' }).click(); ERROR 04
Scripts de performance sin thresholds explícitos
ERROR 05
Confiar en coverage de código como proxy de calidad
Regla práctica
ERROR 06
No verificar el código generado antes de commitear
# Checklist mínimo antes de commitear tests generados
□ El test compila/parsea sin errores de TypeScript
□ Ejecutar el test al menos una vez (debe poder pasar Y fallar)
□ Las importaciones existen en el proyecto
□ Los selectores/endpoints coinciden con el código real
□ Las assertions tienen valores específicos (no solo existencia)
13. Buenas prácticas
✅ Hacer
❌ Evitar
🧠
Claude Code amplifica, no reemplaza
14. Recursos y referencias
Documentación oficial
Cursos gratuitos
Testing & herramientas
Recursos de este portfolio