Comprobar aprobaciones con criterios de aceptación claros

Describa resultado y estado inicial

Defina para cada flujo importante quién puede actuar, con qué condiciones y qué estado debe poder demostrarse después. GOV.UK describe criterios de aceptación como resultados para comprobar la necesidad del usuario. Una promesa general como «la aprobación funciona» se vuelve comprobable con esas condiciones.

Ejemplo: aprobar una solicitud interna de cambio

El plan es completamente ficticio. La solicitud CH-27 empieza en draft, pasa a pending con justificación completa y la persona revisora asignada puede ponerla en approved. Use datos sintéticos y cuentas adecuadas en pruebas controladas. La tabla contiene resultados esperados, no tests ejecutados.

La última fila supone rechazo inequívoco antes del cambio. Si solo falta respuesta, el estado guardado es inicialmente incierto; planifique un caso aparte para comprobar el estado realmente guardado.

Compruebe estado, permisos y respuesta visible

Ocultar un botón no demuestra control de acceso. OWASP exige verificar permisos adecuadamente en cada petición. Incluya llamadas directas y estado realmente guardado. Un mensaje de éxito no basta.

Prepare cada caso con estado inicial definido. Playwright recomienda tests independientes con datos y sesiones controlados. El rol o estado anterior no debe determinar inadvertidamente el siguiente resultado. Acuerde con el equipo qué comprobaciones de componentes y flujos completos automatizar.

Registre versión, entorno, rol y datos usados. Separe resultados y hallazgos reales de expectativas; un caso no ejecutado queda abierto. El responsable de negocio debe valorar desviaciones y repetir los casos afectados tras corregir.

Fuentes

• GOV.UK: Writing user stories

• OWASP: Authorization checks

• Playwright: Best practices