Testing Automatizado: Dormir Tranquilo Mientras El Bot Testea

El Pesadilla Del QA Manual

Un equipo en San Isidro lanzaba features cada viernes.

Cada viernes, 1 QA manual hacía click en 47 escenarios diferentes:

• Crear usuario
• Login correcto/incorrecto
• Actualizar perfil
• (y 44 más)

Tiempo: 4 horas. Resultado: 3 bugs se escapaban a producción de todos modos.

Al mes: $12K en developer time arreglando bugs que QA manual no encontró.

Después de implementar testing automatizado:

• Mismos 47 escenarios en 2 minutos (sin humano)
• 90% de bugs encontrados ANTES de producción
• QA manual solo para escenarios complejos (10% del tiempo)

Resultado: $12K en costos de bugs → $2K.

Eso es testing automatizado.

Tres Tipos De Tests (De Menos a Más Complejo)

1. Unit Tests (Lo Más Fácil)

Testea una función en aislamiento.

// función a testear
function sumTax(price) {
  return price * 1.21; // 21% IVA Argentina
}

// test
test('sumTax agrega 21%', () => {
  expect(sumTax(100)).toBe(121);
});

Ventajas:

• Rápido de escribir
• Rápido de ejecutar
• Fácil de mantener

Desventajas:

• No testea interacción real

Tool recomendada: Jest (gratis, simple)

2. Integration Tests (Intermedio)

Testea que componentes funcionen juntos.

// ¿Login + Crear Producto funcionan juntos?
test('Usuario logueado puede crear producto', async () => {
  const user = await login('user@test.com', 'password');
  const product = await createProduct('Iphone', 999);
  expect(product.seller).toBe(user.id);
});

Ventajas:

• Más realista que unit tests
• Atrapan bugs de integración

Desventajas:

• Más lento (accede a DB, APIs)
• Más complejo de mantener

Tool recomendada: Jest + Supertest

3. E2E Tests (Más Realista)

Testea toda la app como usuario real.

// Usuario entra a sitio, compra producto, recibe email
test('Flujo de compra completo', async () => {
  await page.goto('https://mitienda.com');
  await page.fill('input[type="email"]', 'user@test.com');
  await page.fill('input[type="password"]', 'password');
  await page.click('button:has-text("Login")');
  await page.click('button:has-text("Comprar")');
  await expect(page).toContainText('Compra completada');
  // Email fue enviado (verificar en inbox)
});

Ventajas:

• Totalmente realista (navegador real)
• Atrapa bugs de UX
• Usuario real interactuando

Desventajas:

• Lento (5-10s por test)
• Frágil (si cambias HTML, se rompe)
• Caro de mantener

Tool recomendada: Playwright o Cypress

La Pirámide De Testing

        /\
       /  \    E2E (Pocos, lentos)
      /____\
     /      \
    /  I.T.  \  Integration (Moderados, medios)
   /________  \
  /          \
 / Unit Tests \  Muchos, rápidos
/____________\

Regla de oro:

• 70% unit tests
• 20% integration tests
• 10% E2E tests

¿Por qué? Porque unit tests son baratos. E2E tests son caros.

Implementación Rápida (Jest)

Paso 1: Instalar

npm install jest --save-dev
npx jest --init

Paso 2: Escribir Test

// math.test.js
const sum = require('./math');

test('suma 1 + 2 = 3', () => {
  expect(sum(1, 2)).toBe(3);
});

Paso 3: Correr

npm test

Paso 4: Celebrar

✓ test passed.

Caso Real: E-commerce Argentino

Antes:

• QA manual: 8 horas semana
• Bugs en producción: 5-7 por sprint
• Hotfixes: 3-4 por sprint

Después de implementar testing:

Semana 1-2: "Escribir tests es tiempo wasted."

Semana 3: Primeros tests catching bugs.

Mes 1: Bugs en producción = 1-2 (bajó 80%).

Mes 2: QA manual solo hace casos complejos (2 horas semana). Ahorro: 6 horas.

Mes 3+: Confianza al deployar. Sin miedo a romper algo viejo.

ROI: 10 horas de setup → 6 horas ahorradas/semana → recupera en 2 semanas.

Errores Comunes

Error 1: Testear UI Internals (Frágil)

// MAL: Testear elemento específico
expect(document.querySelector('.button-123')).toExist();

// BIEN: Testear comportamiento
expect(screen.getByRole('button', {name: /click me/i})).toBeVisible();

Primero es frágil. Si cambias clase, se rompe.

Error 2: No Testear Happy Path

// MAL
test('login falla con password incorrecto', () => { ... });
test('login falla sin email', () => { ... });

// BIEN
test('login exitoso con credenciales correctas', () => { ... });
test('login falla con password incorrecto', () => { ... });

Necesitas validar que funciona primero.

Error 3: Tests Acoplados

// MAL: Test 1 crea usuario, Test 2 asume que usuario existe
test('crear usuario', () => { ... });
test('actualizar usuario', () => { ... }); // asume test 1 pasó

// BIEN: Cada test es independiente
test('crear usuario', () => { ... });
test('actualizar usuario', () => {
  // setup su propio usuario
});

Tests independientes = confiables.

FAQ

¿Cuánto código necesito testear?

Mínimo 70% coverage. Pero más importa qué % de bugs atrapa (usualmente 50%+ si haces bien).

¿Qué testing framework usar?

• Unit: Jest
• Integration: Jest + Supertest
• E2E: Playwright o Cypress

¿Es más caro escribir tests?

Upfront sí (20-30% más tiempo inicial).

Pero a largo plazo no: menos bugs, menos hotfixes.

¿Testing reemplaza QA manual?

No. Manual está para casos complejos, UX, casos edge.

Tests automatizan casos comunes + repetitivos.

Siguiente Paso: Comienza Con Unit Tests

Empieza testing una función crítica.

Veras que es simple. Luego expande.

Nosotros entrenamos equipos en testing automatizado. Desde unit tests hasta E2E.

¿Necesitás implementar testing?

📱 WhatsApp: +549113903722 📧 Email: beersechconsultas@gmail.com

O exploá desarrollo web profesional y sistemas web a medida.

---

Última actualización: Diciembre 2024 Tiempo de lectura: 10 minutos Dificultad: Avanzada