Plan de pruebas de Signmethod en producción

1. Objetivo

Comprobar de forma coordinada entre dos compañeros que Signmethod funciona correctamente en producción, desde la web pública hasta el ciclo completo de envío y firma de un acuerdo.

El documento funciona como guion, checklist, registro de evidencias y acta final de aprobación.

2. Datos de la ejecución

3. Reparto del trabajo

Joel López: administración y emisión

• Web pública, DNS y TLS.
• Registro, acceso y recuperación de cuenta.
• Perfiles owner, admin y emisor.
• Empresas, usuarios, permisos y plantillas.
• Creación, envío, reenvío y cancelación de acuerdos.
• API, almacenamiento, correo y monitorización.

Pau Dengra: firma y verificación

• Perfil firmante.
• Recepción del correo y apertura del enlace público.
• Revisión, cumplimentación y firma de documentos.
• Validación del PDF firmado y sus evidencias.
• Pruebas en móvil y navegadores alternativos.
• Accesibilidad y comprobación cruzada del trabajo de Joel López.

Pruebas conjuntas

Joel López y Pau Dengra realizarán juntos los flujos completos, el aislamiento entre empresas, el registro de incidencias, la limpieza y la decisión GO/NO-GO. Uno ejecuta la acción y el otro comprueba el resultado y registra la evidencia.

4. Normas para probar en producción

• Utilizar exclusivamente cuentas y empresas de prueba autorizadas.
• Usar PDF ficticios sin datos personales, confidenciales o reales.
• Identificar los datos con el prefijo QA-PROD-AAAA-MM-DD.
• No activar PLAYWRIGHT_ALLOW_AWS_WRITES=1 contra producción.
• No ejecutar carga masiva, ataques automatizados, restauraciones o borrados masivos.
• No incluir contraseñas, tokens o enlaces de firma en capturas y evidencias.
• Detener las pruebas ante pérdida de datos, acceso entre empresas, exposición de secretos o indisponibilidad general.
• Eliminar o anonimizar los datos de prueba al terminar, respetando la auditoría obligatoria.

5. Estados y severidad

Estados: PENDIENTE, OK, KO, BLOQUEADA o N/A.

Severidad:

• CRÍTICA: pérdida o exposición de datos, firma incorrecta, acceso entre empresas, vulnerabilidad grave o caída general.
• ALTA: una función principal no puede utilizarse y no existe alternativa segura.
• MEDIA: fallo de una función secundaria con alternativa disponible.
• BAJA: defecto visual, de texto o de usabilidad con impacto limitado.

6. Preparación

Evidencias y pendientes de PRE-02

Evidencia disponible: capturas compartidas de la comprobación realizada en AWS y de la relación de trabajos necesarios para completar el control.

Para cambiar PRE-02 a OK deben resolverse todas las carencias anteriores y guardarse como evidencia las capturas de PITR de cada tabla, backups, configuración y versionado de S3, métricas recientes, alarmas, tema SNS y suscriptores confirmados, versiones/alias de Lambda y configuración de CloudFront/DNS. La prueba de notificación debe identificar el canal y confirmar su recepción, sin incluir datos secretos.

7. Pruebas automáticas seguras

La suite privada actual usa estado y API simulados. Valida la interfaz, pero no demuestra por sí sola el funcionamiento real de Cognito, Lambda, DynamoDB, S3 o SES.

8. Web pública, DNS y TLS

Evidencias de PUB-03

La conexión directa al puerto 443 confirma en ambos dominios TLS 1.3 sin errores de política, cadena X.509 válida y un certificado vigente hasta el 13/11/2026. El campo SAN incluye signmethod.com y www.signmethod.com. El resultado técnico completo y la huella del certificado están en docs/evidencias/PUB-03-CERTIFICADO-TLS-2026-08-28.md.

signmethod.com

www.signmethod.com

Rutas SEO mínimas:

• /firma-digital-empresas/
• /firma-digital-recursos-humanos/
• /firma-digital-legal/
• /trazabilidad-documental/
• /firma-contratos-empresas/

Análisis de la observación PUB-06

Se revisaron la portada y las cinco rutas SEO mínimas el 28/08/2026. Todas responden con el mismo HTML inicial: título SignMethod | Firma digital para empresas, descripción Gestiona documentos y procesos de firma digital con SignMethod., sin canonical y sin etiquetas Open Graph.

Después de ejecutar JavaScript, la aplicación sí asigna un título, una descripción y una URL canonical propios a cada landing SEO. Sin embargo, esta configuración solo en cliente no garantiza que los rastreadores y servicios que no ejecutan JavaScript reciban los metadatos específicos. Además, no se implementan og:title, og:description, og:url, og:type ni og:image, por lo que la previsualización al compartir una página no queda definida.

Corrección requerida:

• Servir desde el HTML inicial un título, una descripción y un canonical específicos para cada ruta pública indexable.
• Añadir og:title, og:description, og:url, og:type y og:image coherentes con cada página.
• Usar URLs absolutas HTTPS del dominio de producción tanto en canonical como en Open Graph.
• Comprobar que og:image sea pública, estable y tenga unas dimensiones adecuadas para compartir.
• Evitar valores de preproducción, localhost, dominios antiguos y metadatos duplicados.
• Repetir la prueba sobre el HTML inicial y sobre el DOM renderizado.

Análisis de la observación PUB-08

Se revisaron los enlaces del pie público el 28/08/2026:

Corrección requerida:

• Crear y mostrar el contenido correspondiente en las tres rutas legales, evitando que rutas desconocidas se presenten como una portada válida con estado 200.
• Confirmar si LinkedIn debe dirigir a una página propia de SignMethod o anunciar claramente que enlaza a Softradis.
• Repetir la navegación desde el pie en escritorio y móvil después de la corrección.

Análisis de la observación PUB-10

El 28/08/2026 se abrió el formulario público de solicitud de demo y se realizó un único intento controlado con datos ficticios identificados mediante QA-PROD-2026-08-28.

Resultado observado:

1. El formulario permite completar nombre, apellidos, teléfono, email y empresa.
2. Al pulsar Solicitar una demo, la aplicación intenta obtener un token reCAPTCHA para la acción demo_request.
3. Google rechaza la inicialización con el mensaje Invalid site key or not loaded in api.js: 6LfQhYUtAAAAAACH8SvLSFTbEmJPKpUiHQgmEnX6r.
4. No se envía ninguna petición HTTP al endpoint /demo-requests.
5. Al no alcanzar el backend, no se solicita a SES ningún correo y no procede comprobar duplicados en el buzón.

Corrección requerida:

• Verificar que VITE_RECAPTCHA_SITE_KEY contenga la clave pública correcta para la versión de reCAPTCHA utilizada y esté autorizada para signmethod.com y www.signmethod.com.
• Confirmar que la clave pública del frontend corresponda al secreto almacenado en producción.
• Desplegar de nuevo el frontend si la variable se inyectó incorrectamente durante el build.
• Repetir un único envío controlado y comprobar que /demo-requests responde correctamente.
• Confirmar en asistente@softradis.com que llega exactamente un mensaje, con asunto, remitente, Reply-To, datos y fecha correctos.

9. Registro, autenticación y sesión

10. Roles, empresas y aislamiento

Análisis de la observación ROL-04

La observación es válida. El rol firmante debe poder consultar los acuerdos en los que participa y completar su firma, pero no debe crear borradores, iniciar acuerdos ni enviarlos.

Comportamiento observado:

1. Pau Dengra accede con rol firmante al Panel Firmante.
2. Pulsa Pendientes y accede al listado de acuerdos pendientes.
3. El listado muestra la acción Nuevo acuerdo.
4. La acción abre el formulario Enviar acuerdo, aunque ese rol no tiene permiso de emisión.
5. El mismo botón aparece al acceder desde Próximos a vencer y Completados recientemente, porque las tres tarjetas reutilizan el mismo listado.
6. El resumen inferior muestra la categoría Enviados. Para un firmante esos registros son acuerdos recibidos como destinatario, por lo que la denominación es incorrecta y presenta una acción propia del contexto emisor.

Análisis técnico:

• La cabecera principal oculta correctamente Enviar acuerdo mediante el permiso canSendAgreement.
• Las tarjetas Pendientes, Próximos a vencer y Completados recientemente abren el mismo listado de acuerdos.
• La acción Nuevo acuerdo de ese listado se renderiza sin comprobar canSendAgreement y abre directamente el formulario, evitando la función de navegación que sí contiene la protección.
• El conjunto de acuerdos sí se filtra para que el firmante vea aquellos en los que figura como destinatario, pero después se presenta bajo la etiqueta Enviados. No se ha detectado en este punto una fuga de acuerdos ajenos; sí existe un error de semántica, rol y experiencia de usuario.
• La protección no puede depender solo de ocultar el botón. Los endpoints de creación de solicitudes, guardado de borradores y envío comprueban la pertenencia a la empresa, pero no restringen explícitamente la operación a owner, admin o emisor.
• En consecuencia, el problema debe considerarse de autorización y no únicamente visual.

Corrección requerida:

• Ocultar Nuevo acuerdo en todos los listados cuando canSendAgreement sea falso.
• Centralizar la apertura del formulario mediante la función que comprueba permisos.
• Adaptar el resumen del firmante para mostrar Recibidos, Pendientes de firma y Completados, evitando la denominación Enviados.
• Rechazar en backend con 403 la creación, modificación o envío cuando el rol sea firmante.
• Añadir pruebas automáticas de interfaz y API para impedir la regresión.

11. Usuarios, perfil y administración

12. Plantillas, carpetas y archivos

Análisis de la observación PLA-07

El formulario no debe considerar preparado un documento que no pueda analizarse. Mantener un PDF vacío o dañado en el listado mientras se muestra Paso completo puede permitir que el usuario continúe con un acuerdo inválido o crea erróneamente que el archivo está listo para enviar.

Mejoras requeridas:

• Validar que el archivo tenga contenido y un tamaño mayor que cero antes de añadirlo.
• Comprobar tipo MIME, extensión y firma interna de PDF; no confiar únicamente en el nombre.
• Analizar el PDF y exigir al menos una página válida.
• Eliminar automáticamente del listado cualquier archivo cuya lectura o previsualización falle.
• Mantener el paso Documentos como incompleto cuando no quede ningún PDF válido.
• Mostrar un único mensaje claro que identifique el archivo rechazado y la causa.
• Repetir la validación en backend antes de aceptar o enviar definitivamente el documento, evitando que pueda eludirse la comprobación del navegador.
• Añadir pruebas automáticas para PDF vacío, truncado, dañado, sin páginas, con extensión falsa y superior a 50 MB.

13. Flujo completo de acuerdo y firma

Joel López actúa como emisor y Pau Dengra como firmante.

14. Persistencia, almacenamiento y correo

Requiere acceso técnico autorizado.

15. Seguridad funcional

No ejecutar escaneos agresivos o denegación de servicio en producción.

16. Navegadores, móvil y accesibilidad

Joel López usa Chrome y Edge de escritorio. Pau Dengra usa Firefox, Safari/WebKit y un móvil real.

17. Rendimiento y resiliencia

18. Monitorización durante las primeras dos horas

Joel López y Pau Dengra alternarán un control cada 15 minutos.

Revisar en cada control:

• 4xx/5xx de CloudFront y API Gateway;
• errores, duración y throttling de Lambda;
• fallos de registro, login y MFA en Cognito;
• errores y throttling de DynamoDB;
• errores de acceso a S3;
• entregas y rebotes de SES;
• alarmas activas y cambios anómalos de latencia.

Las carencias de observabilidad que impiden que el control quede completamente en OK se registran en INC-046.

19. Registro de incidencias

Las incidencias repetidas o con la misma causa se han consolidado. La numeración actual es correlativa y todas las referencias del plan apuntan al ID vigente.

Propuesta de solución para INC-004

• Centrar el logotipo en la plantilla HTML mediante una celda de tabla de ancho completo con align="center" y estilos inline compatibles con clientes de correo.
• Aplicar a la imagen display: block; margin: 0 auto; y definir explícitamente su ancho y texto alternativo.
• Evitar que el logotipo dependa únicamente de flex, clases CSS externas o propiedades que algunos clientes de correo ignoran.
• Enviar correos de prueba y verificar el centrado en los clientes soportados, como Gmail, Outlook y las vistas móvil y escritorio, antes de cambiar ADM-03 a OK.

20. Limpieza

21. Criterios GO/NO-GO

La producción se aprueba únicamente si:

• NO CUMPLE — No hay incidencias críticas o altas abiertas. Permanecen abiertas 3 incidencias críticas (INC-001, INC-030 e INC-031) y 19 altas; cualquiera de ellas impide el GO sin resolución o aceptación formal aplicable.
• NO CUMPLE — Web, DNS, TLS y rutas públicas funcionan. HTTP/HTTPS, TLS y las rutas SPA básicas están acreditadas por PUB-02, PUB-03 y PUB-05, pero PUB-01, PUB-04 y PUB-08 siguen en KO por el dominio www no canónico, navegación pública incompleta y páginas legales que renderizan la portada.
• NO CUMPLE — Registro, email, login, recuperación y cierre de sesión funcionan. El registro y el login básico tienen evidencia positiva, pero la recuperación no está disponible (ID-08/INC-012), el MFA administrativo no es utilizable desde la interfaz (ID-07/INC-015) y la caducidad/recuperación de sesión no está validada (ID-10/INC-016).
• NO CUMPLE — Roles y aislamiento entre empresas están validados en interfaz y backend. Existen fallos críticos de autorización y aislamiento en ROL-04, FIR-22 y SEG-08, registrados en INC-001, INC-030 e INC-031.
• NO CUMPLE — Se completa el flujo real de crear, enviar, recibir, firmar y descargar. El control +15 acredita creación, envío, recepción y firma, pero no existe una descarga utilizable del PDF firmado (FIR-12/INC-024).
• NO CUMPLE — Cognito, API/Lambda, persistencia, S3 y SES se comprueban con el flujo real. API/Lambda quedó OK, pero Cognito y DynamoDB están en KO de observabilidad y S3/SES permanece PARCIAL; véanse MON-15, PRE-02 e INC-046.
• NO CUMPLE — El PDF firmado y sus evidencias son correctos. La firma y finalización están acreditadas en FIR-10, pero FIR-12 y FIR-13 siguen en KO: no se pudo descargar el artefacto firmado ni verificar su contenido, hash y tamaño.
• PARCIAL — No hay referencias a preproducción ni exposición de secretos. PUB-09 no encontró referencias de preproducción y las revisiones disponibles no detectaron secretos visibles, pero TEC-07 no puede certificar los logs completos y SEG-07 mantiene permisos excesivos y carencias de trazabilidad (INC-032 e INC-038).
• NO CUMPLE — Los navegadores y dispositivos acordados superan los flujos críticos. AUT-01, AUT-02, UX-01 y UX-03 siguen en KO; además permanecen fallos de teclado, lector de pantalla y objetivos táctiles en UX-04, UX-06 y UX-07.
• NO CUMPLE — Backups, métricas, alarmas y rollback están disponibles. PRE-02 continúa en KO y INC-046 confirma que faltan alarmas, métricas de S3/SES/Cognito, tráfico representativo de DynamoDB y una prueba de notificación.
• PARCIAL — Las incidencias menores restantes están documentadas y aceptadas. El registro de incidencias está actualizado, pero no consta aceptación formal de las desviaciones abiertas y todavía existen incidencias críticas y altas, no solo menores.
• CUMPLE — Ambos compañeros aprueban la decisión. Joel López y Pau Dengra confirman el NO-GO provisional el 03/09/2026 a las 13:30 CEST. Esta confirmación aprueba la decisión de no autorizar producción en el estado evaluado; deberá renovarse después de corregir las incidencias para emitir un GO definitivo.

Resultado actual: NO-GO. Evaluación actualizada el 04/09/2026 después de completar PRE-06 y los cinco controles de limpieza (LIM-01 a LIM-05). El recuento total queda en 50 pruebas OK, 66 pruebas KO y 4 pruebas PENDIENTE. Los bloqueos determinantes siguen siendo las 3 incidencias críticas, las 19 incidencias altas, la imposibilidad de descargar y auditar el PDF firmado, las brechas de autorización/aislamiento y la falta de observabilidad y recuperación completas. La limpieza completada reduce el riesgo residual de los datos QA, pero no corrige esos bloqueos. No se necesita una nueva comprobación con Playwright para emitir este resultado: los defectos y ausencias de evidencia ya registrados son suficientes y deben corregirse antes de repetir los controles afectados.

Una incidencia crítica implica NO-GO y valoración inmediata de rollback. Una incidencia alta también implica NO-GO, salvo aceptación formal técnica y de negocio con una alternativa segura documentada.

22. Acta final

Esta acta es provisional y refleja el estado documentado a 04/09/2026, incluida la finalización de PRE-06 y de LIM-01 a LIM-05. Joel López y Pau Dengra han confirmado expresamente el NO-GO provisional; esta confirmación no autoriza producción y deberá renovarse tras resolver los bloqueos para adoptar una decisión final. Los recuentos de OK, KO y PENDIENTE incluyen las 120 pruebas con una única columna Estado, incluidos los controles de limpieza del punto 20; los 9 controles temporales del punto 18 se informan por separado porque cada fila contiene resultados independientes por componente.

23. Evidencias que deben guardarse

• Versión, commit y artefacto desplegado.
• Reporte Playwright, trazas y capturas relevantes.
• Resultados de DNS, TLS y cabeceras.
• Identificadores QA de usuarios, empresas, plantillas y acuerdos.
• Hashes del PDF original y firmado.
• Registro de correos enviados, entregados y rebotados.
• Métricas y alarmas de las dos primeras horas.
• Incidencias, decisiones y rollback, si lo hubiera.
• Acta final aprobada por ambos compañeros.

24. Documentación relacionada

• docs/RUNBOOK_PREPRODUCCION_A_PRODUCCION.md
• docs/PLAYWRIGHT_QA.md
• docs/MANUAL_USUARIO_SIGNMETHOD.md