Las pruebas de correo transaccional son las que más se posponen, porque el correo parece una parte secundaria del producto. Hasta que un usuario no recibe su factura, no puede recuperar la contraseña o abre un enlace roto, y entonces el problema deja de ser secundario. Esta lista reúne lo que conviene verificar antes de publicar, ordenado por lo que suele fallar primero.
Qué entra en el correo transaccional
Se llama así al mensaje que el sistema envía como consecuencia de una acción concreta del usuario o de un evento de su cuenta. Confirmaciones de registro, recuperación de contraseña, avisos de cambio de datos, recibos de compra, facturas y notificaciones de estado entran en esta categoría.
La diferencia con el correo promocional es el motivo del envío. Un mensaje transaccional responde a algo que ha pasado y que el destinatario necesita conocer; uno promocional busca convencer. Esa distinción no es solo de vocabulario: las reglas aplicables son distintas, y por eso los mensajes promocionales suelen incluir una forma de darse de baja y los transaccionales no siempre la necesitan.
Conviene que el equipo tenga clara la frontera. Muchos problemas empiezan cuando un mensaje nacido como transaccional empieza a llevar recomendaciones y ofertas, y su naturaleza cambia sin que nadie lo decida.
¿Qué hay que comprobar en cada plantilla?
Estos son los puntos que aparecen en casi todas las revisiones.
- Que el mensaje se dispare en el momento correcto y una sola vez por evento.
- Que todos los datos variables se hayan sustituido por un valor real, sin huecos ni marcas visibles.
- Que los enlaces funcionen y lleven al destino correcto, incluso desde un dispositivo móvil.
- Que el texto se lea bien en las dos versiones habituales, la de texto sencillo y la de formato enriquecido.
- Que el asunto describa el contenido, porque es lo que decide si el mensaje se abre.
- Que el remitente sea reconocible y coherente con el dominio del servicio.
Una plantilla que pasa estas seis comprobaciones rara vez da problemas graves. Las que fallan suelen hacerlo por un detalle tonto, como un nombre vacío o un enlace construido con una parte de la dirección que no estaba disponible.
Variables, enlaces y datos que no deben aparecer
Cuando un dato variable no tiene valor, el mensaje no debería enseñar el hueco. Un saludo que empieza con la palabra hola y nada más, o una frase con dos puntos seguidos de un espacio vacío, delata de inmediato que el sistema no previó el caso.
Los enlaces merecen una comprobación aparte. Cada enlace de cada plantilla debería abrirse al menos una vez, porque un identificador mal montado no rompe el envío, solo el destino. Los enlaces que caducan necesitan además una prueba con un enlace viejo, para confirmar que el sistema explica la situación en lugar de mostrar un error crudo.
Finalmente está lo que no debe aparecer. Direcciones completas de tarjeta, contraseñas, identificadores internos o datos de otras personas no tienen sitio en un mensaje que puede acabar reenviado a cualquiera. Conviene revisar el contenido de los registros de envío con el mismo criterio, porque a menudo el mensaje está limpio y el archivo donde se guarda no lo está.
Repeticiones: el mismo aviso dos veces
Un sistema con reintentos puede enviar dos veces el mismo aviso. Si el usuario recibe dos recibos de la misma compra, la reacción natural es preguntarse si le han cobrado dos veces, aunque no sea el caso.
La manera de evitarlo es que el envío tenga una clave propia ligada al evento que lo provoca. Si el evento ya generó su mensaje, el reintento no debería producir otro. Esa misma clave sirve para auditar después cuántos mensajes se enviaron por cada operación.
Una comprobación sencilla consiste en provocar el mismo evento dos veces seguidas y contar los mensajes que llegan. Si el contador sube cuando no debería, el problema está en el sistema y no en la plantilla.
¿Cómo se prueba el correo que nunca llega?
Provocando el fallo a propósito. Si el servicio de envío no responde, el producto debería comportarse de forma previsible: registrar el error, ofrecer al usuario una forma de reintentar y no dejar la operación a medias.
El caso opuesto también necesita cobertura. Un correo que sale correctamente pero nunca llega al destinatario es indistinguible, desde el sistema, de uno entregado. Por eso conviene registrar el momento del envío y el identificador que devuelve el servicio, y disponer de una forma de consultar qué pasó con un mensaje concreto.
Ninguna de estas comprobaciones exige conocer los detalles internos del proveedor. Basta con tratar la entrega como lo que es: un proceso asíncrono que puede salir bien, tardar o fallar.
Revisar los mensajes en un buzón de pruebas
Antes de publicar una plantilla, conviene verla llegar tal como la verá el usuario. En el buzón de correo temporal de este sitio se genera una dirección nueva, se provoca el envío y el mensaje aparece en la bandeja con los enlaces y los códigos a la vista.
Para comprobar los datos que alimentan esas plantillas, el artículo sobre direcciones y códigos postales que no cuadran ayuda a detectar incoherencias entre campos antes de que se cuelen en un mensaje.
Si el flujo incluye un código de un solo uso, la guía sobre códigos OTP en pruebas automáticas explica cómo leerlo dentro de una prueba.
Notas para quien programa
- Da a cada envío una clave ligada a su evento, para que un reintento no produzca un segundo mensaje.
- Prevé el caso del valor ausente en cada variable y decide qué se muestra. Un texto genérico siempre es mejor que un hueco.
- Separa el envío del resto de la operación. Que el correo falle no debería deshacer una compra ni impedir un registro.
- No guardes datos sensibles en el cuerpo ni en los registros de envío, y revisa ambos con el mismo criterio.
- Comprueba el asunto y el remitente, no solo el cuerpo. Son los dos elementos que deciden si el mensaje se abre.
- Prueba cada plantilla en texto sencillo y en formato enriquecido, porque no todos los clientes muestran lo mismo.
Siguientes pasos
Toma la última plantilla que hayas publicado y pásala por la lista de arriba, anotando qué comprobación no habías hecho nunca. Con ese resultado es fácil decidir cuál merece convertirse en una prueba automática.
Para el recorrido completo desde el registro hasta la confirmación, la guía sobre pruebas de verificación por correo cubre los caminos que rodean a esa primera plantilla.
La lista sirve para verificar el producto, y las direcciones que aparecen en ella son de prueba, nunca una identidad real.