Plan de pruebas de software: plantilla en español y ejemplo real

Respuesta corta: qué es un plan de pruebas de software

Un plan de pruebas es el documento que acuerda, antes de probar, qué se va a revisar, con qué tipo de pruebas, en qué entorno, con qué datos y qué condiciones tiene que cumplir el sistema para salir a producción. No es una lista de casos: es el mapa que dice por qué existe cada caso.

El que mejor me ha funcionado parte de los criterios de aceptación del contrato y los liga, uno por uno, con las pruebas que los demuestran. Así, cuando alguien pregunta «¿esto ya está probado?», la respuesta está en una tabla y no en la memoria de alguien.

Plan de pruebas, caso de prueba y guion de aceptación: diferencias

Son tres documentos distintos que se suelen confundir:

Plantilla de plan de pruebas (para copiar)

Copia esta estructura en un documento o en un archivo Markdown del repositorio. Lo que está entre corchetes son ejemplos del proyecto que uso más abajo; reemplázalos con lo tuyo.

# Plan de pruebas — [Nombre del sistema] · [Versión o fase]

## 1. Alcance
Qué se prueba: [módulos, flujos, integraciones].
Qué NO se prueba en esta fase: [y por qué].

## 2. Criterios de aceptación
| ID | Criterio (se puede responder sí o no) | Prioridad |
| AC-01 | [Un visitante sin cuenta no ve ningún precio] | Alta |

## 3. Riesgos
| Riesgo | Impacto | Cómo se cubre |
| [Dos clientes apartan la última unidad al mismo tiempo] | Alto | Prueba de concurrencia en la API |

## 4. Estrategia por capa
- Unitarias: reglas de negocio puras (cálculos, validaciones, permisos).
- Base de datos: restricciones, transacciones y permisos por fila.
- API: contratos, errores y casos de concurrencia.
- Interfaz (E2E): flujos completos en escritorio, tableta y celular.
- Aceptación (UAT): el cliente recorre los flujos con datos reales de su operación.

## 5. Entornos y datos de prueba
Entorno: [staging, con base de datos que se reinicia antes de cada corrida].
Usuarios de prueba: [uno por papel: rechazado, aprobado, temporal, admin].
Contenido mínimo: [productos, existencias, una llegada programada, un descuento vigente].
Dispositivos: [un celular y una computadora].

## 6. Criterios de entrada y salida
Entrada: [build publicado en staging y prueba de humo en verde].
Salida: [todas las pruebas automáticas en verde y la UAT aprobada o con observaciones acordadas por escrito].

## 7. Matriz de trazabilidad
| AC | Capa | Prueba |
| AC-01 | API, BD, UI | identity-matrix.test.ts, catalogo.spec.ts |

## 8. Reporte de defectos
Cada observación se clasifica como defecto (no cumple lo acordado) o cambio (algo nuevo).

## 9. Responsables y calendario
| Actividad | Responsable | Fecha |
| UAT | [Equipo del cliente] | [17 al 19 de octubre] |

Paso 1: escribe criterios de aceptación que se puedan comprobar

El plan entero se apoya en esta parte. Un criterio sirve si una prueba puede responder sí o no, sin interpretar. «El sistema debe ser seguro» no se puede probar; «un visitante sin cuenta no recibe ningún campo de precio» sí.

Estos son criterios reales del portal mayorista de De La Rocha + Vera Home, un proyecto que hice en 2026. El contrato tenía 29 y cada uno quedó cubierto por al menos una prueba automática:

• AC-01: un visitante anónimo no recibe ningún campo de precio.
• AC-04: un acceso temporal vigente ve precios; al vencer, deja de verlos y se le muestran sus opciones.
• AC-17: si dos clientes envían una cotización al mismo tiempo por la última unidad, solo uno la obtiene.
• AC-18: si la misma cotización se reintenta con la misma clave, el sistema devuelve la misma cotización y no crea otra.
• AC-21: un descuento solo se ve dentro de sus fechas, en hora de Ciudad de México.
• AC-27: los flujos funcionan a 390, 768 y 1440 píxeles de ancho.

Paso 2: elige en qué capa se prueba cada criterio

No todo se prueba en el navegador. La regla que sigo: cada criterio se prueba en la capa más baja que pueda demostrarlo, porque ahí la prueba es más rápida y falla por una sola causa. El navegador se reserva para lo que solo se ve en pantalla.

Paso 3: arma la matriz de trazabilidad

La matriz es una tabla con una fila por criterio: qué capas lo cubren y qué archivos de prueba lo demuestran. Es lo primero que reviso cuando cambia un requisito, porque dice qué pruebas hay que actualizar. Un fragmento de la del portal:

Paso 4: dedica más pruebas a lo que más duele si falla

Un plan de pruebas no reparte el esfuerzo por igual. En un sistema que maneja precios e inventario, estas fueron las zonas con más pruebas, y son las que recomiendo revisar en cualquier sistema parecido:

• Quién ve qué: precios visibles solo para cuentas aprobadas o accesos temporales vigentes, comprobado en la base de datos y no solo en la pantalla.
• Dinero e inventario en la misma transacción: si la cotización se guarda, las unidades se apartan; si falla una cosa, no pasa ninguna.
• Concurrencia e idempotencia: dos personas por la última pieza, o el mismo envío repetido por una mala conexión.
• Fechas y zonas horarias: descuentos y accesos que vencen a una hora exacta de Ciudad de México.
• Estados que no se pueden saltar: una cotización cancelada o cerrada ya no se edita.
• Lo que nadie pide pero todos notan: accesibilidad con axe, cabeceras de seguridad, qué ve el usuario si el servidor se cae.

Paso 5: prepara entornos y datos de prueba

La mitad de las pruebas fallidas que he visto no eran errores del sistema, sino datos de prueba incompletos. Por eso el plan dice exactamente con qué se prueba:

• Un entorno de staging con la base de datos que se reinicia limpia antes de cada corrida automática.
• Una prueba de humo en verde antes de empezar: si el entorno no arranca, no tiene caso probar lo demás.
• Un usuario de prueba por cada papel. En el portal fueron cuatro correos: un solicitante rechazado, un cliente aprobado, un prospecto con acceso temporal y un administrador invitado.
• Contenido mínimo cargado: dos productos por marca, uno tapizado con telas de dos líneas, existencias en las dos sucursales, una llegada programada, un producto sobre pedido y un descuento vigente.
• Un celular y una computadora reales para la aceptación, además de los tres anchos automáticos.

Paso 6: escribe el guion de aceptación (UAT) para el cliente

El guion de aceptación lo usa el equipo del cliente, no el técnico. Cada escenario dice qué hacer, qué debe pasar y deja un espacio para marcar el resultado. Entre paréntesis lleva los criterios del contrato que cubre, para que cada aprobación sea trazable. Este es un escenario real del portal:

### C2 · Carrito y cotización (AC-15, AC-16, AC-25)

1. Agrega al carrito un producto en existencia, uno de una llegada (preorden) y uno sobre pedido.
2. Revisa el carrito y envía la cotización.
3. Abre «Mis cotizaciones».

Debe pasar:
- El carrito agrupa por modalidad (existencia, preorden, sobre pedido) y muestra los avisos.
- Al enviar aparecen un folio y los avisos de confirmación.
- Al correo de cotizaciones configurado llega el aviso.
- La cotización aparece como «Enviada» y las unidades quedan apartadas.

Resultado: ☐ Aprobado  ☐ Con observaciones — Notas:

• El guion se organiza por papel (visitante, solicitante, cliente, vendedor, administrador), no por pantalla: así cada persona del cliente prueba lo que hace en su día.
• Cada observación se clasifica como defecto (no cumple el guion o el contrato, se corrige antes de producción) o cambio (algo nuevo, se decide por escrito si entra ahora o en otra fase). Esa sola regla evita la mayoría de las discusiones al final del proyecto.
• Al cierre hay una tabla con las observaciones y su estado, y una línea de firma: con todo aprobado o acordado, el cliente autoriza la salida.

Cómo reportar un defecto para que se corrija a la primera

Un reporte útil permite reproducir el problema sin preguntar nada. Este ejemplo es ilustrativo, armado con el formato que uso:

Título: El descuento sigue visible después de su fecha de fin
Escenario: C1 · Precios por línea y descuento (AC-21)
Entorno: staging · celular Android, Chrome · 18/10/2026 23:30 (hora de Ciudad de México)
Pasos:
  1. Entrar con la cuenta del cliente aprobado.
  2. Abrir el producto con descuento que vence el 18/10 a las 23:59.
  3. Esperar a las 00:01 del 19/10 y recargar.
Resultado esperado: a las 00:01 ya no aparece el descuento.
Resultado obtenido: el descuento sigue visible hasta las 06:00.
Tipo: defecto (no cumple AC-21)
Evidencia: captura de pantalla con la hora del celular.

Criterios de entrada y salida: cuándo empezar y cuándo terminar

Sin estos criterios, las pruebas nunca empiezan a tiempo o nunca terminan. En el portal, la entrada a la aceptación era el staging publicado con la prueba de humo en verde, el administrador principal creado con verificación en dos pasos y el contenido mínimo cargado. La salida a producción exigía dos cosas: el script de verificación completo en verde (formato, lint, tipos, unitarias, base de datos, API, build y navegador) y la aceptación firmada.

Errores comunes en un plan de pruebas

• Escribirlo al final, cuando ya no cambia nada. Se escribe con los criterios de aceptación, antes de programar.
• Casos sin resultado esperado: «revisar el carrito» no es una prueba; «el carrito agrupa por modalidad» sí.
• Probar solo el camino feliz: los errores caros están en la concurrencia, los permisos y las fechas límite.
• Probar todo en el navegador: lento, frágil y difícil de diagnosticar cuando falla.
• Probar solo en escritorio cuando el cliente usa el celular.
• No separar defectos de cambios en la aceptación, y terminar discutiendo qué estaba incluido.

El plan en un proyecto real: lo que quedó

En el portal mayorista de De La Rocha + Vera Home, el plan terminó así: 29 criterios de aceptación, todos con al menos una prueba automática; 41 archivos de pruebas de base de datos con 416 comprobaciones de pgTAP; pruebas de API y unitarias con Vitest; 82 escenarios de navegador con Playwright que corren en tres anchos de pantalla, con revisión de accesibilidad; y un guion de aceptación de 19 escenarios para el equipo del cliente. Todo corre en un solo comando de verificación, que es la definición de terminado del proyecto.

Si tu sistema no tiene nada de esto, no hace falta empezar por todo. Empieza por escribir los criterios de aceptación y una matriz con una sola columna: qué criterio tiene prueba y cuál no. Esa tabla ya te dice dónde está el riesgo.