Cuaderno de pruebas de recepción: definición, contenido y método de redacción
Un cuaderno de pruebas de aceptación (« cahier de recette » en francés) es el documento que enumera todos los casos de prueba que hay que ejecutar antes de aceptar un software: para cada caso, los pasos a seguir, los datos a utilizar y el resultado esperado. Comprueba que la entrega se ajusta a la especificación, y sus resultados alimentan el acta de aceptación que deja constancia de la aceptación. También se conoce como plan de pruebas UAT o guion de pruebas UAT.
¿Para qué sirve un cuaderno de pruebas de aceptación?
El cuaderno de pruebas convierte una especificación, escrita por fuerza en lenguaje corriente, en comprobaciones concretas que cualquier probador puede repetir. Cumple cuatro funciones:
- Verificar la conformidad: cada requisito de la especificación está cubierto por al menos un caso de prueba.
- Compartir una referencia: antes de empezar a probar, proveedor y cliente acuerdan qué se va a comprobar y qué se espera de cada función.
- Dejar trazabilidad de los resultados: cada ejecución queda registrada (OK, KO, bloqueado o no aplicable), con sus comentarios y defectos.
- Decidir sobre la entrega: el resumen de resultados respalda el veredicto del acta de aceptación (aceptada, aceptada con reservas o rechazada).
¿Quién redacta y quién ejecuta el cuaderno de pruebas de aceptación?
El reparto depende del contrato. Lo más habitual es que el proveedor (el contratista, llamado MOE en los proyectos franceses) redacte el cuaderno a partir de la especificación y lo someta a la revisión del cliente (la propiedad del proyecto, MOA). El cliente también puede redactarlo. La ejecución corresponde a los usuarios de negocio del cliente, a veces con el apoyo de un probador del proveedor, bajo la dirección de un jefe de proyecto.
En las consultoras informáticas y las agencias, el cuaderno suele redactarlo el proveedor y lo ejecutan después probadores del lado del cliente: deben poder leerlo e introducir sus resultados sin una herramienta pesada. Consulte Spec2Sign para consultoras y agencias.
¿Qué contiene un cuaderno de pruebas de aceptación?
Un cuaderno de pruebas de aceptación suele ser una tabla en la que cada fila es un caso de prueba. Las columnas más habituales son:
| Columna | Utilidad |
|---|---|
| Identificador | Referencia única del caso (por ejemplo CT-012), que se reutiliza en los defectos y en el acta. |
| Requisito de origen | Apartado o requisito de la especificación que verifica el caso: es lo que demuestra la cobertura. |
| Lote o módulo | Agrupación funcional, útil para repartir la ejecución entre varios probadores. |
| Título | Lo que verifica el caso, en una frase. |
| Precondiciones y datos de prueba | Estado inicial, cuentas a utilizar, valores de prueba. |
| Pasos | Acciones a realizar, una por línea, en orden. |
| Resultado esperado | Comportamiento observable que valida el caso. |
| Prioridad | Peso del caso en la decisión de aceptación. |
| Estado | OK, KO, bloqueado o no aplicable, que se rellena durante la ejecución. |
| Comentario y defecto | La observación del probador y un enlace al defecto abierto si se detecta una desviación. |
Cómo redactar un cuaderno de pruebas de aceptación en 6 pasos
- Extraiga los requisitos comprobables de la especificación. Un requisito vago (« el sitio debe ser rápido ») debe aclararse con el cliente antes de escribir cualquier caso.
- Organice en lotes y módulos que reflejen la aplicación (autenticación, pedido, facturación…), para poder repartir y seguir la ejecución.
- Redacte los casos: una sola intención de prueba por caso, pasos cortos en imperativo y un resultado esperado que pueda observarse sin interpretación.
- Prevea los datos de prueba y los requisitos previos: cuentas, permisos, estados iniciales. Un caso que no se puede repetir por falta de datos acaba « bloqueado ».
- Priorice: si falta tiempo, los casos críticos deben ejecutarse primero. Indique también qué bloquea la entrega y qué puede convertirse en una reserva.
- Haga que el cliente lo revise y versione después el cuaderno junto con la especificación que verifica. Un cuaderno que no sigue la versión de la especificación ya no demuestra nada.
Ejemplo de caso de prueba
| Campo | Contenido |
|---|---|
| Identificador | CT-012 |
| Requisito de origen | Autenticación, § 2.3: se rechaza una contraseña incorrecta. |
| Título | Inicio de sesión con una contraseña incorrecta |
| Precondiciones | Existe una cuenta activa con la dirección [email protected]. |
| Pasos | 1. Abrir la página de inicio de sesión. 2. Introducir [email protected] y una contraseña incorrecta. 3. Hacer clic en « Iniciar sesión ». |
| Resultado esperado | Se muestra un mensaje de error claro, el usuario permanece en la página de inicio de sesión y no obtiene acceso a ningún dato. |
| Prioridad | Alta |
Estados de ejecución de un caso de prueba
| Estado | Significado |
|---|---|
| OK | El resultado observado coincide con el resultado esperado. |
| KO | Se observa una desviación: se abre un defecto y se vincula al caso. |
| Bloqueado | El caso no se puede ejecutar (falta un requisito previo o hay un defecto bloqueante aguas arriba). |
| N/A | El caso no se aplica a esta versión o a este alcance. |
Al final de la campaña, el número de casos por estado y la gravedad de los defectos restantes son la base del veredicto del acta de aceptación.
Aceptación, VABF, VSR: ¿cuál es la diferencia?
La aceptación (« recette » en francés) es toda la fase de verificación que conduce a aceptar el software. En algunos contratos, en particular los contratos informáticos públicos franceses, se divide en dos etapas: la VABF (verificación de aptitud para el buen funcionamiento), que comprueba que el sistema entregado funciona como se espera, y después la VSR (verificación de servicio regular), que observa su funcionamiento a lo largo del tiempo en condiciones reales de producción. El contrato fija su duración y sus criterios.
El cuaderno de pruebas describe lo que se verifica; estas siglas designan el momento y el marco contractual de la verificación. Encontrará estas definiciones en el glosario de la aceptación de software.
Errores frecuentes
- Redactar el cuaderno al final del proyecto, cuando ya no queda tiempo para corregir la especificación ambigua que pone de manifiesto.
- Casos sin un resultado esperado medible (« la página se muestra correctamente »): dos probadores llegarán a conclusiones distintas.
- Sin vínculo con los requisitos: es imposible saber qué no está cubierto.
- Una especificación que cambia y un cuaderno que no la sigue: los casos prueban una versión que ya no existe.
- Varias versiones del mismo archivo Excel circulando por correo, con resultados introducidos en varios sitios.
¿Excel o una herramienta específica?
Para un proyecto pequeño con un solo probador, una hoja de cálculo basta. En cuanto la aceptación implica a varios probadores, versiones sucesivas de la especificación y seguimiento de defectos, una herramienta específica evita duplicados y mantiene la trazabilidad. La comparativa entre Excel, herramientas de gestión de pruebas y Spec2Sign detalla los criterios de elección.
Genere su cuaderno de pruebas de aceptación con Spec2Sign
Spec2Sign produce el cuaderno de pruebas de aceptación a partir de sus especificaciones:
- usted sube la especificación (PDF, Word, Excel o Markdown);
- la IA extrae los requisitos, citados textualmente con su origen, y propone un plan en lotes y módulos;
- para cada requisito redacta casos de prueba con pasos, resultado esperado, prioridad y datos de prueba, y señala los puntos por aclarar que la especificación deja abiertos;
- una matriz de cobertura muestra los requisitos que no tienen caso de prueba;
- cuando la especificación cambia, un análisis de impacto propone los casos que añadir, modificar o dejar obsoletos, que usted acepta línea por línea.
El cuaderno generado es una propuesta: revíselo y valídelo antes de cualquier uso contractual.
Preguntas frecuentes
¿Cuál es la diferencia entre un cuaderno de pruebas de aceptación y un plan de pruebas?
El plan de pruebas describe la estrategia: alcance, tipos de pruebas, entornos, recursos y calendario. El cuaderno de pruebas de aceptación es su parte operativa: la lista de casos de prueba precisos que se ejecutan, con su resultado esperado. En muchos proyectos de consultoras y agencias, el cuaderno se produce directamente, precedido de unas pocas líneas de encuadre.
¿Cuándo hay que redactar el cuaderno de pruebas de aceptación?
En cuanto la especificación es estable, no al final del desarrollo. Redactar los casos en paralelo hace aflorar pronto las ambigüedades de la especificación, cuando todavía es barato resolverlas.
¿Cuántos casos de prueba hacen falta?
No existe una cifra universal. El objetivo mínimo es que cada requisito esté cubierto por al menos un caso; después se añaden casos límite y de error sobre las funciones críticas. Priorizar los casos permite ejecutar lo esencial si falta tiempo.
¿Se puede generar un cuaderno de pruebas de aceptación con IA?
Sí. Spec2Sign extrae los requisitos de una especificación y redacta los casos de prueba correspondientes, cada uno vinculado a su apartado de origen. El resultado sigue siendo una propuesta que una persona debe revisar y validar antes de usarla para la aceptación.