Vibe Testing: El Nuevo Paradigma de Testing con IA

Si trabajas en QA o desarrollo de software, probablemente lo hayas notado: la forma en que escribimos, mantenemos y pensamos sobre las pruebas está cambiando rápidamente. El término "vibe coding", usar IA para generar código de producción a partir de prompts en lenguaje natural, se popularizó a inicios de 2025. Pero el lado del testing en esa ecuación ha sido ignorado en gran medida.

Ese es el vacío que llena Vibe Testing. Es un framework que desarrollé y documenté en mi libro para formalizar cómo los ingenieros de QA pueden aprovechar los LLMs sin perder control sobre la calidad de las pruebas, la estrategia de cobertura o los estándares de ingeniería.

Este artículo explica los conceptos centrales, muestra patrones reales de implementación con Playwright y aborda los riesgos de frente.

Definiendo Vibe Testing

Vibe Testing es la práctica disciplinada de usar asistentes de IA para generar, refinar y mantener pruebas automatizadas, guiada por criterios de calidad definidos por humanos, modelos de riesgo y restricciones arquitectónicas.

La palabra clave es disciplinada. Esto no es "pedirle a ChatGPT que escriba tus pruebas y hacer commit". Ese enfoque produce pruebas frágiles y sin contexto que se convierten en deuda de mantenimiento en semanas.

Vibe Testing funciona cuando el ingeniero es dueño de la estrategia y la IA maneja la estructura base. Invierte esa relación y obtendrás ruido en lugar de cobertura.

En la práctica, esto significa que el ingeniero de QA define qué probar y por qué, mientras que la IA acelera el cómo: escribiendo boilerplate, sugiriendo casos límite desde contratos de API, generando variaciones de pruebas basadas en datos y proponiendo estrategias de localizadores.

Los Tres Pilares Técnicos

1. Generación de Pruebas Consciente del Contexto

La calidad de las pruebas generadas por IA es directamente proporcional a la calidad del contexto que proporcionas. Un prompt sin contexto arquitectónico produce pruebas genéricas. Un prompt con tu estructura de Page Objects, convenciones de nombres y patrones de fixtures produce pruebas que parecen escritas por tu equipo.

Aquí hay un ejemplo concreto. Considera una prueba de Playwright para un flujo de reserva de citas de telemedicina. El enfoque tradicional:

// Traditional approach: manually authored end-to-end test
import { test, expect } from '@playwright/test';
import { AppointmentPage } from '../pages/AppointmentPage';
import { DashboardPage } from '../pages/DashboardPage';

test.describe('Appointment Booking', () => {
  test('patient completes booking and provider sees it', async ({ page }) => {
    const appointment = new AppointmentPage(page);
    const dashboard = new DashboardPage(page);

    await appointment.navigate();
    await appointment.fillPatientInfo({
      name: 'John Doe',
      state: 'California',
      insuranceId: 'BC-2024-11892'
    });
    await appointment.selectProvider('Dr. Sarah Chen');
    await appointment.selectTimeSlot('next-available');
    await appointment.submit();

    await expect(appointment.confirmationBanner).toBeVisible();
    await expect(appointment.confirmationId).not.toBeEmpty();

    // Verify provider-side visibility
    const confirmId = await appointment.confirmationId.textContent();
    await dashboard.navigateAsProvider('dr-chen');
    await expect(dashboard.findAppointment(confirmId)).toBeVisible();
  });
});

Con Vibe Testing, proporcionas contexto a la IA a través de un prompt estructurado:

## Context
- Framework: Playwright + TypeScript
- Pattern: Page Object Model (see /pages/*.ts for conventions)
- Fixtures: use test.extend for authenticated sessions
- Naming: describe blocks use feature name, tests use user action

## Generate tests for: Appointment Booking
- Happy path: patient books, provider confirms visibility
- Edge case: expired insurance triggers validation
- Edge case: no available slots shows waitlist option
- Boundary: booking at 11:59 PM crosses to next day
- Negative: duplicate booking within 24h is rejected

La IA genera cinco estructuras de prueba que siguen exactamente tus patrones. Revisas, ajustas las aserciones y haces commit. Tiempo ahorrado: ~60% en la estructura inicial. Pero lo más importante, los casos límite que sugiere la IA, como el límite de medianoche, son escenarios que los equipos frecuentemente omiten bajo presión de entrega.

2. Priorización de Pruebas Basada en Riesgo

No todas las pruebas tienen el mismo valor en cada ciclo de ejecución. Un git diff que toca el módulo de pagos debería activar primero las pruebas relacionadas con pagos, no toda la suite de regresión.

Los modelos de IA pueden analizar conjuntos de cambios contra datos históricos de defectos para producir un orden de ejecución ponderado por riesgo:

# risk-config.yml — AI-driven test prioritization
prioritization:
  strategy: risk-weighted
  inputs:
    - source: git-diff
      weight: 0.4
    - source: defect-history
      weight: 0.3
      lookback: 90d
    - source: code-complexity
      weight: 0.2
      metric: cyclomatic
    - source: last-failure
      weight: 0.1

  thresholds:
    critical:  0.8   # always run
    high:      0.6   # run on PR
    medium:    0.4   # run nightly
    low:       0.2   # run weekly

El resultado práctico: retroalimentación de regresión en 12 minutos en lugar de 45, porque la suite ejecuta primero las pruebas de mayor riesgo. Si pasan, la confianza es suficiente para hacer merge. La suite completa sigue ejecutándose nocturnamente para cobertura completa.

3. Mantenimiento Automatizado de Pruebas

Según el syllabus de ISTQB Test Automation Engineering, el mantenimiento de pruebas representa el 40-60% del costo total de automatización durante la vida de un proyecto. La mayor parte de ese costo proviene de la rotura de localizadores cuando cambia la UI.

El mantenimiento asistido por IA funciona así:

1. Detección: El pipeline de CI falla, la IA analiza la traza del error y el diff reciente de la UI
2. Clasificación: ¿Es un bug real o un cambio de localizador? La IA compara el DOM antes/después
3. Propuesta: Si es un cambio de localizador, la IA genera un PR de corrección con selectores actualizados
4. Validación: El ingeniero revisa el PR. Una aprobación, cero depuración manual

Esto no elimina al ingeniero del ciclo, elimina la parte tediosa del ciclo.

Implementación a Escala

En entornos de alto riesgo (salud, fintech, industrias reguladas) una falla de prueba en producción puede tener consecuencias graves para los usuarios finales. Esa restricción define cómo debe adoptarse Vibe Testing en la práctica:

• Biblioteca de prompts estructurados: Mantén un repositorio compartido de plantillas de prompts alineadas con tu arquitectura de Playwright. Cada ingeniero usa los mismos patrones, así el output de la IA es consistente en todo el equipo.
• Puerta de revisión humana: Ninguna prueba generada por IA llega a main sin revisión de código. La IA propone, el ingeniero valida la lógica de negocio, condiciones límite y calidad de las aserciones.
• Ciclo de retroalimentación: Las pruebas que detectan defectos reales en producción deben etiquetarse como de alto valor. Estos datos entrenan tu modelo de riesgo, mejorando la precisión de la priorización con el tiempo.
• Barreras de protección: Prohíbe explícitamente las pruebas generadas por IA para flujos sensibles al cumplimiento sin revisión de un ingeniero senior. Las rutas críticas regulatorias requieren autoría manual.

Conceptos Erróneos Comunes

Después de presentar este framework en conferencias y en mis cursos de QA en UPC, estas son las objeciones más frecuentes que escucho, y las respuestas honestas:

"La IA reemplazará a los ingenieros de QA."
No. La IA reemplaza la parte mecánica de escribir pruebas. La parte estratégica (decidir qué riesgos cubrir, qué nivel de testing es apropiado, cómo estructurar una puerta de calidad) requiere juicio humano, conocimiento del dominio y contexto organizacional que los LLMs no tienen.

"Las pruebas generadas por IA no son confiables."
No confiables sin revisión, sí. Por eso Vibe Testing exige un paso de validación humana. El output de la IA es un primer borrador, no un artefacto final. Trátalo como tratarías el PR de un ingeniero junior: revísalo a fondo.

"Esto solo funciona con apps CRUD simples."
Lo he aplicado en entornos con máquinas de estado complejas, flujos de trabajo de múltiples pasos y restricciones regulatorias. La clave es proporcionar suficiente contexto en tus prompts. Prompts simples producen pruebas simples.

Primeros Pasos: Lista de Verificación Práctica

Si quieres adoptar Vibe Testing de manera incremental, empieza aquí:

1. Documenta tu arquitectura de pruebas: convenciones de Page Objects, patrones de fixtures, estándares de nombres. Esto se convierte en tu contexto para la IA.
2. Elige una funcionalidad estable: selecciona un módulo bien entendido con cobertura de pruebas existente. Genera pruebas con IA y compáralas con las manuales.
3. Establece la puerta de revisión: define criterios explícitos sobre qué hace aceptable una prueba generada por IA. Codifícalo en tu plantilla de PR.
4. Mide la diferencia: rastrea tiempo de escritura, defectos detectados, tasa de falsos positivos, costo de mantenimiento. Compara pruebas asistidas por IA vs. escritas manualmente durante 2-3 sprints.
5. Expande con barreras de protección: a medida que crece la confianza, extiende a más módulos. Mantén las áreas críticas de cumplimiento y seguridad bajo autoría manual.

El framework completo, incluyendo plantillas de prompts listas para usar con Playwright, Cypress y testing de APIs, está documentado en detalle en mi libro Quality Assurance: De Fundamentos a Automatización con IA (Amazon, Kindle y Paperback).

---

Vibe Testing no se trata de reemplazar la disciplina de ingeniería con la conveniencia de la IA. Se trata de aplicar IA donde genuinamente reduce el trabajo tedioso: estructura de pruebas, mantenimiento de localizadores, descubrimiento de casos límite, mientras las decisiones estratégicas se mantienen donde pertenecen: con el ingeniero. Los equipos que logren este equilibrio entregarán más rápido sin entregar de forma irresponsable.