Cómo crear una lista de aceptación a partir de una demostración grabada
Convierte una demostración en una lista de aceptación con condiciones, acciones, resultados esperados y pruebas. Incluye un ejemplo basado en requisitos acordados.
Una demostración satisfactoria solo cubre lo que se mostró
En la llamada pareció que el formulario enviaba la solicitud correctamente. Quizá nadie probó otro rol, un envío repetido o un campo obligatorio vacío. La grabación permite repasar lo que se mostró. Los demás casos requieren pruebas propias.
La lista parte de requisitos acordados de antemano. Una idea nueva del público puede ser útil, pero anótala aparte. Si el alcance cambia durante la aceptación, los participantes terminan discutiendo versiones distintas.
Prepara las comprobaciones con la grabación
Anota la versión y las condiciones
Indica la versión o compilación, quién hizo la demostración y qué rol usó. Describe los datos de prueba y el entorno con detalle suficiente para repetir el escenario. Marca las condiciones desconocidas.
Vincula el punto con un requisito
Toma el comportamiento acordado y localiza el fragmento. Una demostración puede cubrir varios puntos, pero cada uno necesita su resultado esperado. Añade como «sin comprobar» todo requisito obligatorio que no se mostró.
Describe la acción y el resultado esperado
En vez de «revisar el formulario», indica qué datos introducir, dónde pulsar y qué debe ocurrir. Define la reacción esperada a los datos inválidos. Incluye un caso límite nuevo solo si lo cubre el alcance acordado.
Vuelve a comprobar los escenarios
Ejecútalos en la versión acordada, registra el resultado real y adjunta la prueba. Distingue un fallo, una comprobación bloqueada y la falta de datos. Tras corregir un fallo, repite el escenario afectado y registra la nueva fecha.
Aceptar un formulario para pedir una consulta
El ejemplo es ficticio. Nombres, condiciones y resultados solo ilustran el método.
El teléfono es obligatorio. Si se envía correctamente, la solicitud aparece en la lista y el visitante ve una confirmación. Sin teléfono, el formulario no debe enviarse.
Hay tres resultados observables: la validación del campo, la creación de la solicitud y la confirmación al visitante. Una pantalla convincente después de pulsar solo demuestra una parte.
Si quien prueba no puede abrir la lista de solicitudes, la creación queda «bloqueada para comprobar». La palabra de quien hizo la demostración no basta para marcarla como superada.
| Revisión | Resultado esperado | Qué guardar |
|---|---|---|
| Teléfono vacío | Aviso de campo obligatorio y ninguna solicitud creada | Captura y revisión de la lista |
| Datos válidos | Una solicitud con los valores introducidos | Registro en la lista de prueba |
| Envío correcto | Confirmación clara para el visitante | Captura tras el envío |
Plantilla de un punto de aceptación
Cada fila debe indicar qué observación determinará el estado final.
ID de la prueba: Requisito acordado: Versión / rol / entorno: Datos de entrada: Acciones: Resultado esperado: Resultado real: Estado: superado / fallo / sin comprobar / bloqueado Prueba y código de tiempo: Corrección relacionada: Fecha de la nueva prueba:
Revisa la lista antes de empezar
- Los puntos remiten al alcance acordado.
- El resultado esperado se puede observar o medir.
- Se distingue entre lo mostrado y lo comprobado personalmente.
- Las condiciones de los fallos se pueden reproducir.
Veamos los detalles
¿Hay que incluir todos los comentarios de la reunión?
Distingue los defectos frente a los requisitos de las peticiones nuevas. Evalúa y acuerda estas últimas aparte para evitar que la aceptación siga ampliando el proyecto.
¿Se puede aceptar el resultado solo con el vídeo?
Depende de las reglas acordadas. El vídeo puede demostrar el escenario que muestra. Indica en el documento cómo se hizo la comprobación y qué quedó fuera.