Las pruebas de aceptación significan al menos tres cosas distintas según quién las hace y cuándo. UAT es que los stakeholders del negocio confirman los requisitos antes del visto bueno, ATDD son tests ejecutables escritos antes de que empiece el desarrollo, y las pruebas de aceptación funcional son QA verificando que la especificación está completamente implementada. Los modos de fallo que importan: probar demasiado tarde, involucrar a las personas equivocadas, y escribir criterios lo suficientemente vagos como para generar debate.

Qué significa realmente "pruebas de aceptación"

El término abarca varios conceptos relacionados:

User Acceptance Testing (UAT)

Los usuarios reales (o stakeholders del negocio) prueban el software en un entorno de staging para confirmar que cumple sus requisitos antes de dar el visto bueno.

Acceptance test-driven development (ATDD)

Los requisitos se escriben como tests ejecutables antes de que empiece el desarrollo. Los tests pasan cuando la funcionalidad está completa.

Pruebas de aceptación funcional

QA verifica que todos los requisitos de la especificación están implementados y funcionan correctamente.

En la práctica, "pruebas de aceptación" suele significar una de dos cosas: UAT hecho por personas del negocio, o pruebas de aceptación funcional hechas por QA contra los requisitos formales.

Criterios de aceptación: la base

Las pruebas de aceptación empiezan con los criterios de aceptación: las condiciones específicas que una funcionalidad debe cumplir para considerarse completa.

Criterios de aceptación malos

La página de login debería funcionar correctamente.

Criterios de aceptación buenos

- Los usuarios pueden iniciar sesión con un email y contraseña válidos y son redirigidos al dashboard
- Si el email o la contraseña son incorrectos, aparece el mensaje de error "Email o contraseña inválidos"
- Después de 5 intentos fallidos en 10 minutos, la cuenta se bloquea y aparece un mensaje de "demasiados intentos"
- Un login exitoso crea una sesión que expira después de 24 horas de inactividad
- El enlace "Olvidé mi contraseña" en la página de login envía un correo de recuperación en menos de 2 minutos

Los buenos criterios son específicos, verificables y sin ambigüedad.

Escribir criterios de aceptación con Gherkin

Gherkin es un lenguaje estructurado para escribir criterios de aceptación en formato Given/When/Then. Lo pueden leer stakeholders no técnicos y herramientas como Cucumber pueden ejecutarlo:

Feature: Login de usuario

  Scenario: Login exitoso con credenciales válidas
    Given estoy en la página de login
    When ingreso "usuario@ejemplo.com" como email
    And ingreso "ClaveValida1" como contraseña
    And hago clic en el botón "Iniciar sesión"
    Then debo ser redirigido al dashboard
    And debo ver "Bienvenido, Usuario de Prueba" en el encabezado

  Scenario: Login con credenciales inválidas
    Given estoy en la página de login
    When ingreso "usuario@ejemplo.com" como email
    And ingreso "ClaveIncorrecta" como contraseña
    And hago clic en el botón "Iniciar sesión"
    Then debo ver "Email o contraseña inválidos"
    And debo permanecer en la página de login

  Scenario: Bloqueo de cuenta después de intentos fallidos
    Given estoy en la página de login
    When ingreso "usuario@ejemplo.com" con contraseña incorrecta 5 veces
    Then debo ver "Demasiados intentos fallidos. Vuelve a intentarlo en 10 minutos."
    And el botón Iniciar sesión debe estar deshabilitado

Proceso de UAT: paso a paso

1. Definir el alcance del testing

¿Qué funcionalidades se incluyen en este ciclo de UAT? Suele estar vinculado a un release o un sprint.

2. Escribir escenarios con los usuarios del negocio

Involucra a los usuarios reales o a los product owners en la escritura de escenarios. Ellos saben cómo se ve "correcto" desde la perspectiva del negocio.

3. Preparar el entorno

El UAT debe ejecutarse en un entorno cercano a producción: mismos datos, mismas integraciones, misma configuración. La computadora de un desarrollador no es un entorno de UAT.

4. Crear datos de prueba

Los usuarios necesitan datos de prueba realistas que representen sus casos de uso reales, no solo "test@test.com" con "test123" como contraseña.

5. Ejecutar los tests

Lo ideal es que los usuarios reales ejecuten los tests. Si no es posible, los ejecuta QA, pero los criterios de aceptación deben definirlos los stakeholders del negocio, no QA.

6. Documentar los resultados

Cada test recibe un estado de aprobado/fallido. Los fallos generan reportes de bugs con pasos para reproducir.

7. Corregir y volver a probar

Los bugs encontrados en UAT vuelven a los desarrolladores. QA vuelve a probar una vez corregidos.

8. Visto bueno

Los stakeholders del negocio aprueban formalmente el release. Sin visto bueno, no se lanza.

UAT vs testing de QA

| Aspecto | Testing de QA | UAT |

|---------|---------------|-----|

| Quién lo hace | Ingenieros QA | Usuarios del negocio / product owners |

| Objetivo | Encontrar bugs | Confirmar que se cumplen los requisitos |

| Enfoque | Corrección técnica | Valor para el negocio |

| Cuándo | Durante el desarrollo | Antes del release |

| Criterio | Casos de prueba | Criterios de aceptación |

| Visto bueno | QA lead | Stakeholder del negocio |

Ambos son necesarios. QA detecta los bugs antes del UAT para que los usuarios del negocio no pierdan tiempo en verificaciones básicas.

Modos de fallo comunes en pruebas de aceptación

Probar demasiado tarde

UAT programado 2 días antes del release sin margen para correcciones. Cada bug encontrado se convierte en una crisis.

Participantes equivocados

Hacer que los desarrolladores hagan UAT anula el propósito. Saben cómo funciona el código y no van a probarlo como un usuario.

Criterios de aceptación vagos

"El checkout debería ser fluido" genera discusiones sobre qué significa "fluido" cuando se encuentran bugs.

Testing en el entorno equivocado

UAT en un servidor de desarrollo con datos que no reflejan volúmenes reales o integraciones reales deja pasar bugs reales.

Sin regresión después de las correcciones

Se encuentra un bug en UAT, se corrige, se despliega, pero nadie verifica si la corrección rompió algo más.

Pruebas de aceptación automatizadas

Se pueden automatizar los tests de aceptación con Playwright:

// acceptance/login.spec.ts
import { test, expect } from '@playwright/test';

test.describe('Login: Criterios de Aceptación', () => {
  test('CA1: Credenciales válidas redirigen al dashboard', async ({ page }) => {
    await page.goto('/login');
    await page.fill('[data-testid="email"]', 'usuario@test.com');
    await page.fill('[data-testid="password"]', 'ClaveValida1');
    await page.click('[data-testid="submit"]');

    await expect(page).toHaveURL('/dashboard');
    await expect(page.getByTestId('welcome')).toContainText('Bienvenido');
  });

  test('CA2: Credenciales inválidas muestran mensaje de error', async ({ page }) => {
    await page.goto('/login');
    await page.fill('[data-testid="email"]', 'usuario@test.com');
    await page.fill('[data-testid="password"]', 'ClaveIncorrecta');
    await page.click('[data-testid="submit"]');

    await expect(page.getByTestId('error-message')).toHaveText('Email o contraseña inválidos');
    await expect(page).toHaveURL('/login');
  });

  test('CA3: La sesión expira después de 24h de inactividad', async ({ page }) => {
    // Normalmente se prueba con tiempo simulado o manipulación de la API
    await page.goto('/login');
    await page.fill('[data-testid="email"]', 'usuario@test.com');
    await page.fill('[data-testid="password"]', 'ClaveValida1');
    await page.click('[data-testid="submit"]');

    // Simular expiración de sesión vía API
    await page.request.post('/api/auth/expire-session');
    await page.reload();

    await expect(page).toHaveURL('/login');
  });
});

Lista de verificación para pruebas de aceptación

Antes de iniciar el UAT:

  • [ ] Criterios de aceptación escritos y revisados por el negocio
  • [ ] Funcionalidad desplegada en el entorno de UAT (no en dev ni staging)
  • [ ] Datos de prueba preparados (realistas, no triviales)
  • [ ] Usuarios del negocio informados sobre qué probar
  • [ ] Proceso de seguimiento de bugs establecido
  • [ ] El cronograma incluye tiempo para correcciones y re-testing
  • [ ] Identificada la persona con autoridad para dar el visto bueno

Durante el UAT:

  • [ ] Tests ejecutados contra los criterios de aceptación
  • [ ] Todos los fallos documentados con pasos para reproducir
  • [ ] Capturas de pantalla o grabaciones para problemas complejos
  • [ ] Severidad asignada a cada hallazgo

Después del UAT:

  • [ ] Todos los bugs P1/P2 corregidos y re-testeados
  • [ ] Visto bueno del negocio recibido por escrito
  • [ ] Notas del release actualizadas con los issues P3/P4 conocidos

Resumen

Las pruebas de aceptación confirman que el software entrega el valor de negocio para el que fue construido. Puntos clave:

  • Basado en criterios de aceptación escritos por los stakeholders del negocio, no por QA
  • UAT involucra usuarios reales; las pruebas de aceptación funcional las hace QA contra los requisitos
  • Gherkin (Given/When/Then) hace los criterios legibles tanto para perfiles técnicos como no técnicos
  • Se ejecuta en un entorno similar a producción con datos realistas
  • Requiere visto bueno formal antes del release
  • Se puede automatizar con Playwright, especialmente útil para regresión en cambios futuros

La diferencia entre el visto bueno de QA y el del negocio importa: QA dice que el código funciona; el negocio dice que la funcionalidad resuelve su problema.

→ See also: Verificación vs Validación en Testing de Software: ¿Cuál es la Diferencia? | Cómo Escribir un Plan de Pruebas: Plantilla y Ejemplos Reales | Testing Basado en Riesgos: Priorizar Qué Testear Cuando No Puedes Testar Todo