Cómo probar un formulario extenso cuando vence la sesión

Una persona termina una solicitud extensa, pulsa Enviar y descubre que la sesión venció mientras escribía. Aparece el acceso, pero el borrador desapareció. Una prueba de aceptación útil recorre todo el regreso: autenticarse, recuperar el borrador permitido, revisarlo y obtener una única solicitud confirmada.

Este ejemplo ficticio utiliza DRAFT-22 en un entorno de prueba. Trata de un vencimiento inesperado mientras trabaja la misma persona, no de un cierre voluntario de sesión ni un cambio de usuario. Son pasos propuestos, no resultados de un proyecto de cliente.

Acordar qué se recupera

La explicación de W3C del criterio 2.2.5 de WCAG 2.2, de nivel AAA, describe continuar la actividad sin perder datos después de volver a autenticarse. Utilízalo como objetivo concreto de diseño. Superar este ejercicio no demuestra por sí solo conformidad general de accesibilidad.

Enumera campos, adjuntos y paso actual que deben recuperarse. Define dónde se puede conservar el borrador, a quién pertenece y cuándo vence. Si la política elegida impide conservar campos sensibles, muestra esa limitación y revisa el riesgo de pérdida; no presentes una recuperación parcial como cumplimiento del objetivo completo.

Provocar el vencimiento de forma controlada

Utiliza una configuración de prueba documentada o una acción controlada del servidor. Cambiar solo la cuenta atrás de la página no basta: la guía de sesiones de OWASP indica que el vencimiento debe aplicarse en el servidor. Mantén intacta la política de producción.

Introduce valores ficticios reconocibles en varios campos, selecciona una opción, añade un adjunto de prueba si se admite y avanza a un paso posterior. Registra el borrador esperado antes de provocar el vencimiento. Evita datos personales reales y nunca incluyas credenciales de sesión en la evidencia.

Recorrer el regreso al formulario

• Envía después del vencimiento. Comprueba que la interfaz explica la necesidad de autenticarse y no afirma que la solicitud se completó.
• Accede como la misma persona autorizada. Compara campos, selecciones, referencias de adjuntos y paso restaurado con el borrador esperado.
• Cancela el acceso una vez. Revisa que se explique cómo continuar o descartar el borrador sin exponerlo a otro usuario.
• Vuelve con otra cuenta. El borrador original no debe quedar accesible simplemente por utilizar el mismo navegador.
• Edita un valor recuperado y envía. Comprueba que la solicitud guardada contiene la corrección y ofrece una referencia de confirmación estable.

Probar por separado una respuesta final incierta

El vencimiento antes de autenticarse y la pérdida de una respuesta después del envío son situaciones distintas. En una prueba controlada, interrumpe la respuesta final después de que el servidor acepte la solicitud. Consulta su estado mediante la identidad existente y verifica si terminó antes de ofrecer otro envío. El resultado esperado es una solicitud, no dos porque no se vio la primera confirmación.

Pide evidencia del número de registros y de los valores guardados, además del mensaje en pantalla. Deshabilitar un botón no demuestra por sí solo que se evitan duplicados. Incluye navegación por teclado durante el acceso y un punto de regreso claro para no obligar a empezar de nuevo.

Conservar evidencia útil

Registra el mecanismo de vencimiento, la identidad del borrador, el rol, los valores esperados y recuperados, y la referencia final. Considera fallos independientes los adjuntos ausentes, cambios de propietario y solicitudes duplicadas. Repite la prueba al cambiar la autenticación, el almacenamiento de borradores o el envío.

El esfuerzo depende del modelo de borradores, el almacenamiento de adjuntos, las reglas sobre datos sensibles y el mecanismo de confirmación. Consulta con Dynelink la recuperación de sesiones y los criterios de aceptación de formularios.

Ilustración conceptual generada con IA; no es una captura de un cliente.