Hay un patrón que se repite en casi todos los proyectos de firma electrónica: el equipo prueba a mano con un documento, funciona, se despliega y el problema aparece tres semanas después con un archivo que trae una tilde en el nombre, con un certificado que venció o con un PDF que ya venía firmado por otra persona. Ninguno de esos casos estaba cubierto, porque las pruebas manuales solo cubren el camino feliz.
La firma electrónica es un componente con una característica incómoda: sus fallos son silenciosos. Un documento mal firmado se ve igual que uno bien firmado hasta que alguien intenta validarlo, y eso puede pasar meses después. Este artículo propone una estrategia de pruebas automatizadas para equipos que integran firma en sus sistemas.
Qué se puede probar sin un certificado real
La objeción habitual para no automatizar es que hace falta el certificado de producción. Es falsa: la mayor parte de la lógica se prueba sin él. Para las pruebas se generan certificados propios, emitidos por una autoridad de prueba creada por el equipo, que permiten ejercitar todo el circuito sin comprometer la identidad de la empresa.
| Nivel | Qué valida | Qué necesita |
|---|---|---|
| Unitario | Armado del documento, mapeo de datos, manejo de errores | Nada externo |
| Integración | Firma y validación completas del archivo | Certificados de prueba propios |
| Contrato | Que la interfaz del proveedor sigue comportándose como se espera | Ambiente de pruebas del proveedor, si existe |
| Extremo a extremo | El circuito completo, desde la solicitud hasta el archivo almacenado | Ambiente equivalente al productivo |
| Humo en producción | Que la operación real funciona tras un despliegue | Un documento de prueba acotado y controlado |
Los certificados de prueba nunca deben ser aceptados por el sistema en producción. Ese control —que la cadena de confianza aceptada dependa del ambiente— es en sí mismo un caso de prueba.
Las pruebas negativas son las que importan
Verificar que un documento se firma bien es la parte fácil. El valor real está en probar lo que debe fallar:
- Documento alterado después de firmar. Modificar un byte y confirmar que la validación lo detecta. Si no lo detecta, la implementación está rota.
- Certificado vencido. Un certificado de prueba con vigencia pasada debe producir un rechazo claro, no un error genérico.
- Certificado revocado. El comportamiento cuando la consulta de revocación indica que el certificado ya no es válido.
- Cadena de confianza incompleta. El error más frecuente en producción y el peor documentado: falta un certificado intermedio y la validación falla sin explicar por qué.
- Contraseña incorrecta. Debe fallar de forma explícita, sin dejar el proceso a medias ni escribir el valor en el log.
- Archivo corrupto o vacío. Rechazo temprano, antes de involucrar al proveedor.
- Documento ya firmado por otra persona. Debe agregar la firma sin invalidar la anterior; es el caso que rompe las implementaciones apuradas.
Cada uno de estos casos debe producir un error identificable y registrado. Cómo se detectan estas condiciones al validar está en cómo validar firmas electrónicas de forma programática, y el caso puntual del vencimiento en cómo verificar un certificado caducado.
Datos de prueba: el detalle que trae problemas legales
Copiar documentos reales al ambiente de pruebas es cómodo y es un error. Un contrato laboral real en un ambiente de QA es un tratamiento de datos personales sin base legal, en un entorno con menos controles que producción. Las opciones correctas son generar documentos sintéticos o anonimizar de verdad, no solo tapar el nombre. Las obligaciones aplicables están en las obligaciones de la LOPDP al firmar y almacenar documentos.
Los certificados y credenciales que usa la suite tampoco deben quedar en el repositorio, ni siquiera los de prueba: acostumbrarse a comitear una clave es como se termina comiteando la de producción. El criterio está en manejo de secretos y rotación de claves.
Pruebas de contrato con el proveedor
Tu integración depende de un servicio externo que puede cambiar. Las pruebas de contrato detectan esos cambios antes que un usuario:
- Que los campos que consumes sigan presentes y con el mismo significado.
- Que los códigos de error sigan siendo los mismos y tu mapeo interno los cubra.
- Que las notificaciones automáticas conserven su estructura y su mecanismo de verificación de origen, como se describe en webhooks de firma electrónica.
Qué ofrece cada proveedor en materia de ambiente de pruebas, documentación y avisos de cambio varía mucho, y conviene preguntarlo antes de contratar. No es un detalle menor: determina cuánto vas a poder automatizar.
Qué corre en cada etapa del pipeline
Automatizar todo en cada cambio suena bien y no funciona: las pruebas lentas terminan desactivadas. Un reparto que se sostiene en el tiempo:
- En cada cambio de código: pruebas unitarias y de integración con certificados de prueba. Deben correr en minutos.
- Antes de desplegar: pruebas extremo a extremo en un ambiente equivalente al productivo.
- Después de desplegar: una prueba de humo con un documento controlado, que confirme que la credencial real está accesible y vigente.
- De forma periódica: pruebas de contrato y verificación de la vigencia de todos los certificados en uso, para que el vencimiento no se descubra en medio de un cierre.
La prueba de humo posterior al despliegue es la que más incidentes evita: detecta el secreto mal inyectado, el permiso faltante y el certificado que venció el fin de semana.
Rendimiento y volumen
Si el sistema firma por lotes, hay que probarlo con lotes. Las preguntas que la prueba debe responder son concretas: cuántos documentos por unidad de tiempo sostiene el circuito, qué pasa cuando el proveedor responde lento, si los reintentos generan duplicados y si un fallo a mitad del lote deja documentos en un estado intermedio del que nadie los saca. El comportamiento esperado bajo carga está tratado en la arquitectura de un servicio de firma interno.
Estas pruebas deben ejecutarse contra el ambiente de pruebas del proveedor o con límites acordados. Lanzar una prueba de carga contra el servicio productivo de un tercero, sin avisar, es una forma rápida de quedarse sin servicio.
Para conocer valores de certificados corporativos, incluidos los que necesitas para ambientes separados, revisa la página de precios o pide una cotización corporativa.
El equipo que mantiene todo esto
Una suite de pruebas de firma envejece rápido si nadie la cuida: los certificados de prueba vencen, el proveedor cambia y los casos negativos dejan de ejecutarse. Conviene asignar un responsable explícito, igual que con el certificado productivo. Las bases conceptuales para quien recién se incorpora al equipo están en la guía técnica de firma electrónica para desarrolladores.
Cuando la prueba falla y hay que avisar
El grupo también desarrolla Omnifox, una plataforma omnicanal que unifica WhatsApp, correo, redes sociales y llamadas en una bandeja compartida. Sirve para el momento en que la prueba de humo falla en producción y hay que coordinar entre desarrollo, el responsable del certificado y el proveedor: el hilo completo queda en un solo lugar, asignado y con historial. Más información en omnifox.io.
Preguntas frecuentes
¿Se puede automatizar sin tener el certificado de producción?
Sí, y es lo recomendable. Con certificados de prueba generados por el equipo se cubre el armado del documento, la firma, la validación y todos los casos negativos. El certificado real solo hace falta para la prueba de humo posterior al despliegue.
¿Cómo se prueba un certificado vencido sin esperar a que venza?
Emitiendo certificados de prueba con vigencias definidas a propósito: uno ya vencido, uno por vencer y uno vigente. Es un caso clásico que conviene tener resuelto como parte de los datos de prueba de la suite.
¿Hace falta probar contra el ambiente del proveedor en cada cambio?
No, y no conviene. Depender de un servicio externo en cada ejecución vuelve la suite lenta e inestable. Las pruebas de contrato se ejecutan de forma periódica y antes de desplegar; el resto del tiempo alcanza con simular las respuestas conocidas.
¿Qué se prueba después de renovar un certificado?
Que el nuevo esté accesible desde el servicio, que la cadena de confianza se resuelva completa, que un documento firmado con él valide correctamente y que los sistemas que consumen el servicio no hayan quedado apuntando al anterior. Una prueba de humo controlada cubre las cuatro cosas.
¿Conviene usar documentos reales en el ambiente de pruebas?
No. Además del riesgo de seguridad, implica tratar datos personales fuera de la finalidad para la que se recolectaron. Lo correcto es trabajar con documentos sintéticos que reproduzcan la estructura y los casos límite, sin contener información de personas reales.
Si necesitas certificados corporativos para producción y ambientes separados de prueba, conversa con un asesor de Firmas.com.ec. Solicita tu cotización corporativa.