Plantilla de criterios de aceptación de software

Lee ejemplos de resultados comprobables y copia una ficha para acordar cómo revisar el software.

Ricardo HuertasRevisado el 23/9/2026

«Funciona bien» no permite distinguir una entrega correcta de una que todavía necesita cambios. Esta plantilla convierte un requisito en una condición que se puede comprobar.

La página muestra una ficha vacía y cinco escenarios ficticios preparados para Cuaderno de equipo: editar, rechazar un cambio sin permiso, informar de un fallo de guardado, exportar y recuperar. Puedes leerlos, copiar la ficha o imprimirla sin descargar archivos. Sus estados son Por comprobar; no representan pruebas ejecutadas.

Un criterio que puedes leer aquí

En el ejemplo ficticio, una lectora intenta cambiar una decisión de Cuaderno de equipo. El resultado esperado es que el cambio se rechace y que la decisión conserve su contenido. Se comprobaría con una acción de prueba y una lectura posterior de los datos. El estado permanece Por comprobar hasta que exista una versión, se ejecute la prueba y la persona responsable revise la evidencia.

SituaciónAcciónResultado esperadoEstado
Lectora con acceso a una decisión de pruebaIntenta modificarla y vuelve a consultar el datoCambio rechazado; el contenido se conservaPor comprobar

La vista completa añade los otros cuatro escenarios, sus condiciones de partida, método, entorno, versión, evidencia esperada y responsable de revisión.

Ficha para copiar o imprimir

La ficha HTML deja espacios para necesidad, situación de partida, persona o rol, acción y resultado esperado. También recoge cómo se comprobará, dónde, en qué versión, qué evidencia se revisará, quién decide y cuál es el estado. Puedes copiarla como texto o imprimirla; las descargas Markdown y JSON mantienen los mismos campos.

Rellena una ficha por resultado

Relaciona el criterio con el alcance; describe dato de partida, rol, acción y resultado esperado. El profesional puede ayudarte a definir cómo se comprobará, en qué entorno y versión, y qué evidencia revisará la persona responsable. La ficha ayuda a acordarlo; no es un requisito previo para conversar sobre la idea.

Una tolerancia solo se escribe cuando ayuda a decidir y tiene una base acordada. Para conservar un identificador puede bastar igualdad exacta; para rendimiento hacen falta contexto, medición y un límite defendible.

Preparado, ejecutado y aceptado

Preparado: el escenario dice qué se quiere comprobar. Ejecutado: se ha realizado y queda un resultado con evidencia. Aceptado: la persona responsable decide que satisface el criterio acordado, o deja explícita una condición pendiente.

No marques un resultado porque exista una captura general de la aplicación. La evidencia debe responder a la acción y condición de esa ficha. Si un cambio afecta al criterio, actualiza su referencia y vuelve a comprobar lo necesario.

De aquí al proyecto

La guía para definir alcance y criterios de aceptación explica los ejemplos. El mapa de alcance relaciona los escenarios con la primera versión; la guía para probar y aceptar la entrega ayuda cuando exista una versión que revisar.

Plantilla y ejemplo completos

La lectura y la impresión están disponibles aquí. Markdown y JSON conservan los campos para editarlos fuera de la web.

Plantilla en blanco

ID
____________________
Resultado del alcance
____________________
Situación de partida
____________________
Persona o rol
____________________
Acción
____________________
Resultado esperado
____________________
Método
____________________
Entorno
____________________
Versión
____________________
Evidencia esperada
____________________
Tolerancia
____________________
Quién revisa
____________________
Estado
Por comprobar
Fecha de comprobación
____________________
Resultado observado
____________________

Ejemplo ficticio: Cuaderno de equipo

Ejemplo ficticio de escenarios preparados. Ninguna fila acredita una prueba ya ejecutada.

EDIT-01 · Corregir una decisión y conservarla

ID
EDIT-01
Resultado del alcance
Corregir una decisión y conservarla
Situación de partida
Proyecto y decisión de prueba existentes; almacenamiento disponible.
Persona o rol
Editora del equipo
Acción
Cambiar el motivo, guardar y volver a abrir la decisión.
Resultado esperado
El nuevo motivo se conserva en la misma decisión y el sistema confirma únicamente el guardado completado.
Método
Prueba funcional y lectura posterior
Entorno
Entorno de prueba por identificar
Versión
Pendiente
Evidencia esperada
Contenido anterior/nuevo, confirmación y lectura posterior de un dato ficticio.
Tolerancia
Coincidencia exacta de identificador y contenido guardado.
Quién revisa
Responsable de revisión del cliente con evidencia del equipo técnico
Estado
Por comprobar
Fecha de comprobación
Pendiente
Resultado observado
Pendiente

PERM-02 · La lectora no modifica decisiones

ID
PERM-02
Resultado del alcance
La lectora no modifica decisiones
Situación de partida
Proyecto y decisión de prueba existentes; sesión de lectora.
Persona o rol
Lectora del equipo
Acción
Intentar una modificación mediante la acción que recibe el servidor y volver a consultar el dato.
Resultado esperado
Cambio rechazado por permiso; ningún campo de la decisión cambia y no se revela contenido ajeno.
Método
Prueba de autorización de la acción y lectura posterior
Entorno
Entorno de prueba por identificar
Versión
Pendiente
Evidencia esperada
Resultado de la acción y comprobación del dato, sin tokens ni credenciales.
Tolerancia
Ninguna mutación de la decisión.
Quién revisa
Responsable de revisión del cliente con explicación técnica
Estado
Por comprobar
Fecha de comprobación
Pendiente
Resultado observado
Pendiente

SAVE-03 · Un fallo de guardado no se presenta como éxito

ID
SAVE-03
Resultado del alcance
Un fallo de guardado no se presenta como éxito
Situación de partida
Una editora ha escrito una corrección; se prepara un fallo controlado del guardado.
Persona o rol
Editora del equipo
Acción
Intentar guardar durante el fallo y revisar el mensaje y el texto pendiente.
Resultado esperado
Aviso de fallo comprensible, sin confirmación de guardado; el texto pendiente se conserva para corregir o reintentar.
Método
Prueba funcional con fallo controlado
Entorno
Entorno aislado con fallo preparado
Versión
Pendiente
Evidencia esperada
Mensaje y contenido pendiente antes/después, identificando el fallo provocado.
Tolerancia
No perder el texto introducido en ese intento ni afirmar persistencia inexistente.
Quién revisa
Responsable de revisión del cliente
Estado
Por comprobar
Fecha de comprobación
Pendiente
Resultado observado
Pendiente

EXPORT-04 · Exportar campos y relaciones acordados

ID
EXPORT-04
Resultado del alcance
Exportar campos y relaciones acordados
Situación de partida
Conjunto ficticio conocido de dos proyectos y tres decisiones con identificadores, motivos y estados.
Persona o rol
Rol con exportación permitida
Acción
Exportar JSON y revisar su contenido contra el conjunto de partida.
Resultado esperado
Se conservan campos acordados, identificadores y relación de cada decisión con su proyecto; no se exportan secretos.
Método
Inspección de datos y comparación estructurada
Entorno
Entorno de prueba por identificar
Versión
Pendiente
Evidencia esperada
Archivo de prueba y comparación de campos/relaciones, con su versión de esquema.
Tolerancia
Sin pérdidas ni reasignación entre proyectos en el conjunto acordado.
Quién revisa
Responsable de datos y persona que acepta la entrega
Estado
Por comprobar
Fecha de comprobación
Pendiente
Resultado observado
Pendiente

RESTORE-05 · Recuperar una copia y continuar el trabajo

ID
RESTORE-05
Resultado del alcance
Recuperar una copia y continuar el trabajo
Situación de partida
Copia del conjunto ficticio y entorno aislado sin datos reales.
Persona o rol
Responsable técnico con permiso de recuperación
Acción
Restaurar siguiendo las instrucciones, abrir una decisión conocida y comprobar sus campos y relación.
Resultado esperado
La copia puede recuperarse en la versión y condiciones acordadas, con datos y relaciones conservados.
Método
Demostración de recuperación y comprobación de datos
Entorno
Entorno aislado de restauración
Versión
Pendiente
Evidencia esperada
Pasos realizados, versión, copia utilizada y dato recuperado; registrar dependencias que faltaron.
Tolerancia
Criterio exacto del conjunto de prueba. Tiempo máximo de recuperación, si fuera necesario, pendiente de acordar con fundamento.
Quién revisa
Responsable operativo y persona que acepta la entrega
Estado
Por comprobar
Fecha de comprobación
Pendiente
Resultado observado
Pendiente