Desarrollo Guiado por Tests: La Guía del Ingeniero QA

En un equipo que practica TDD, los desarrolladores escriben tests antes del código. Eso plantea una pregunta concreta: ¿qué queda para QA? Los tests unitarios no reemplazan los tests de integración, la verificación E2E ni los casos extremos que el desarrollador no pensó en especificar. Este artículo cubre cómo encaja QA en flujos de trabajo TDD, qué significa el desarrollo guiado por tests de aceptación (ATDD) en la práctica, y por qué TDD requiere que QA se mueva antes, no que desaparezca.

Qué es TDD

El ciclo TDD tiene tres pasos:

1. Rojo: escribir un test que falle para el comportamiento que quieres

2. Verde: escribir el código mínimo para que el test pase

3. Refactor: limpiar el código sin romper el test

Repetir para el siguiente comportamiento.

La palabra clave es "mínimo". Escribes exactamente el código suficiente para pasar el test, nada más. Eso obliga a que la implementación la dicte la especificación (el test), no al revés.

Qué cambia en el código con TDD

TDD produce código que es:

Testeable por diseño

El código difícil de probar casi siempre refleja un diseño con problemas: acoplamiento excesivo, dependencias ocultas, demasiadas responsabilidades. TDD fuerza la testeabilidad en el momento de escribir, no como corrección posterior.

Cubierto por definición

Cada comportamiento tiene un test porque tuviste que escribir el test para poder escribir el comportamiento.

Incremental

Las funcionalidades se construyen en pasos pequeños y verificados. No existe el "escribo todo y después pruebo".

Documentado

La suite de tests es una especificación ejecutable. Leer los tests te dice qué se supone que hace el código.

Dónde encajan los QA engineers en equipos con TDD

Los QA engineers en equipos TDD enfrentan una paradoja: los desarrolladores ya escriben tests. ¿Qué queda?

Testing de nivel superior

Los desarrolladores escriben tests unitarios. Los QA engineers escriben tests de integración y E2E. TDD a nivel unitario no reemplaza la verificación E2E.

Desarrollo guiado por tests de aceptación (ATDD)

El QA engineer escribe los tests de aceptación antes de que el desarrollador escriba una sola línea. El desarrollador hace que esos tests pasen. Es TDD a nivel de funcionalidad. Requiere que QA participe al inicio del desarrollo, no al final.

Testing exploratorio y de casos extremos

Los tests TDD los escribe quien construyó el sistema y sabe cómo funciona. Los QA engineers prueban lo que el desarrollador no pensó en especificar: casos extremos, entradas inusuales, puntos de integración, comportamiento bajo carga.

Revisión de la calidad de los tests

¿Los tests del desarrollador realmente verifican lo correcto? ¿Están probando comportamiento o implementación? ¿Van a detectar los bugs que importan? Los QA engineers pueden revisar código de tests, no solo código de producto.

Desarrollo guiado por tests de aceptación (ATDD)

ATDD es la versión de TDD relevante para QA. El flujo:

1. El stakeholder de negocio describe una funcionalidad en términos de usuario

2. El QA engineer traduce eso en criterios de aceptación y tests de aceptación

3. Los desarrolladores implementan hasta que los tests de aceptación pasan

4. QA verifica tanto los tests como la implementación

Los tests de aceptación se convierten en la fuente de verdad para qué significa "terminado". Una funcionalidad está terminada cuando sus tests de aceptación pasan.

En términos de Playwright:

// Escrito antes de que exista la implementación
test('el usuario puede resetear la contraseña por email', async ({ page }) => {
  // Dado un usuario con email registrado
  const userEmail = 'testuser@example.com';
  
  // Cuando solicita un reseteo de contraseña
  await page.goto('/forgot-password');
  await page.getByLabel('Dirección de email').fill(userEmail);
  await page.getByRole('button', { name: 'Enviar enlace de reseteo' }).click();
  
  // Entonces ve un mensaje de confirmación
  await expect(page.getByRole('alert')).toHaveText(
    'Si ese email está registrado, el enlace está en camino.'
  );
  
  // Y recibe un email de reseteo (verificado via API de email de prueba)
  const inbox = await testEmailAPI.getInbox(userEmail);
  expect(inbox.some(m => m.subject.includes('Resetea tu contraseña'))).toBe(true);
});

Este test se escribe antes de que se construya la funcionalidad. El trabajo del desarrollador es hacerlo pasar.

Desarrollo guiado por comportamiento (BDD)

BDD es una evolución de ATDD que añade un lenguaje compartido (generalmente Gherkin) para escribir tests que personas no técnicas pueden leer:

Feature: Reseteo de contraseña

  Scenario: El usuario resetea la contraseña por email
    Given un usuario con email "testuser@example.com" está registrado
    When envía el formulario de contraseña olvidada con ese email
    Then ve "Si ese email está registrado, el enlace está en camino."
    And recibe un email de reseteo en menos de 1 minuto

Estos escenarios Gherkin se conectan con código de Playwright a través de una capa de definición de pasos (con herramientas como Cucumber.js o los plugins BDD para Playwright).

BDD tiene más valor cuando los stakeholders no técnicos escriben o revisan los escenarios. Para equipos donde todos pueden leer código, añade complejidad sin beneficio real.

¿Deberían los QA engineers practicar TDD?

Para código de automatización de tests: en general no. TDD está diseñado para código de producción, donde estás diseñando un sistema. El código de tests debería ser directo de escribir y verificar. Escribir tests para tus propios tests genera complejidad innecesaria.

La excepción: los QA engineers que construyen frameworks de testing o utilidades (helpers de page objects, utilidades de fixtures, integraciones de reporting) sí pueden beneficiarse de TDD al construir esas herramientas.

Lo que cambia en la práctica para QA en equipos TDD

1. Participa antes de que se escriba el código. Revisa las historias de usuario para verificar testeabilidad. Escribe criterios de aceptación. Define los casos extremos.

2. Escribe los tests de aceptación temprano. Aunque el equipo no haga ATDD formal, tener tests de aceptación escritos antes de que empiece el desarrollo da forma a la implementación.

3. Mueve el testing exploratorio antes. En equipos TDD, el testing exploratorio gana importancia porque es lo que encuentra lo que los tests no especificaron.

4. Revisa los tests del desarrollador. No para verificar números de cobertura, sino para evaluar si los tests realmente verifican el comportamiento que importa.

TDD no elimina la necesidad de QA engineers. Cambia dónde ocurre el trabajo de QA: de después del código a junto con él.