Correo temporal para pruebas: cómo comprueban los flujos de registro los equipos de desarrollo y QA

Todo producto que envía correo necesita que alguien se registre una y otra vez con una dirección nueva. Los desarrolladores tiran de su propio Gmail con una etiqueta tras el signo más, los testers de QA llevan una hoja de cálculo con cuentas de usar y tirar y los product managers piden prestada la bandeja de un compañero. Para una tarea concreta, una dirección de correo temporal para pruebas es más rápida que todo eso: ver exactamente lo que recibe un usuario nuevo desde tu configuración de correo de producción o de staging.

Gestionamos los servidores de correo de PureTempMail, así que los límites que verás más abajo son nuestra configuración real, no suposiciones. Esta guía explica qué lugar ocupa una bandeja temporal pública en un plan de pruebas, una prueba manual que puedes hacer en cinco minutos, la lista de comprobación que usaríamos con nuestros propios correos de registro y los casos en los que conviene usar otra herramienta.

Qué lugar ocupa una bandeja temporal entre tus opciones de prueba

Hay cinco formas habituales de dar una dirección a una cuenta de prueba. La mayoría de los equipos acaban usando dos o tres de ellas en distintas fases de la misma versión.

Una bandeja temporal se gana su sitio en un hueco que las demás dejan libre: un mensaje real, enviado por tu proveedor de correo real, que llega a un dominio que no controlas y que ves en un navegador en segundos. Es lo más parecido a lo que ve un cliente nuevo, sin crear otra cuenta más en algún sitio.

Una prueba manual con PureTempMail

Esta es la prueba que recomendamos para comprobar a mano un flujo de registro. Cada pasada lleva unos cinco minutos.

1. 1

   Abre un buzón nuevo para cada usuario de prueba

   Abre PureTempMail en otra ventana del navegador. Al cargar se crea una dirección nueva. El buzón se recuerda por navegador, así que pulsa Nueva para cada usuario de prueba, o usa una ventana privada cuando dos testers compartan equipo.

2. 2

   Anota la dirección junto al caso de prueba

   Pega la dirección en tu caso de prueba o ticket antes de usarla. Si más tarde un tester pregunta por qué no llegó nunca el correo de restablecimiento, necesitas saber a qué buzón fue.

3. 3

   Completa el registro y provoca todos los correos que puedas

   Rellena el formulario y después solicita los correos que un usuario nuevo puede generar en su primera sesión: reenviar la verificación, he olvidado mi contraseña, un inicio de sesión con enlace mágico, una solicitud de cambio de correo. Cada uno es una plantilla distinta que puede fallar por su cuenta.

4. 4

   Vigila la bandeja sin recargar

   El correo nuevo llega a la página por una conexión en vivo en cuanto nuestro servidor lo acepta, así que el momento en que aparece un mensaje se acerca mucho a su hora real de entrega. Apunta cuánto tardó cada uno. En Cómo funciona se explica el recorrido de entrega.

5. 5

   Abre cada mensaje en las dos vistas

   Léelo en HTML y luego cambia a Texto plano. La vista de texto plano es la que usan como alternativa algunos clientes y lectores de pantalla, y es donde primero se nota que falta la parte de texto o que un código no se lee. Haz clic en cada enlace y comprueba adónde lleva.

6. 6

   Amplía el tiempo si el flujo es lento

   Las secuencias automáticas, las aprobaciones con retraso y los recordatorios del segundo día necesitan más tiempo. Pulsa +1 h para devolver el temporizador a una hora completa. Puedes repetirlo hasta que pasen 24 horas desde que se creó el buzón.

7. 7

   Deja que caduque y prueba el rebote

   Tras la caducidad, nuestro servidor rechaza el correo a esa dirección en la fase SMTP con un error permanente "No such mailbox". Envíale un correo más y comprueba que tu app o tu proveedor de correo registra un rebote permanente y deja de escribir a ese usuario.

Lista de comprobación para los correos de registro

Estas son las comprobaciones que haríamos con los correos de registro de cualquier producto antes de una versión. Cada una es fácil de ver en una bandeja real y fácil de pasar por alto en una revisión de código.

• Código o enlace de verificación. Llega, el código se lee en texto plano, el enlace funciona una vez y un segundo clic muestra un mensaje claro en lugar de una página de error.
• Enlaces mágicos y códigos de un solo uso. Un enlace nuevo invalida el anterior, un enlace caducado explica qué hacer a continuación y abrir el enlace en otro navegador se comporta como pretendes.
• Restablecimiento de contraseña. El correo indica para qué cuenta es, el enlace caduca y pedir un restablecimiento para una dirección no registrada no revela si esa dirección tiene cuenta.
• Correos de bienvenida y secuencias. El primero llega después de la verificación, no antes, y los pasos siguientes no se disparan para usuarios que nunca confirmaron.
• Partes HTML y de texto plano. Existen las dos, dicen lo mismo y nada importante está solo en una imagen. Las imágenes remotas se cargan en nuestra vista HTML, así que puedes comprobarlas ahí y usar Texto plano para ver el mensaje sin ellas.
• Adjuntos. Las facturas y los PDF llegan con nombres de archivo y tipos de contenido razonables. Mantén los archivos de prueba por debajo de 1 MB por mensaje, o envía un enlace de descarga, que de todos modos es más amable con los usuarios reales.
• Destino de los enlaces. Ningún enlace de un correo de producción apunta a localhost, a un nombre de host interno ni a un dominio de staging, y las redirecciones de seguimiento llevan a la página correcta.
• Cabeceras de baja. Los correos de marketing y de secuencias llevan un enlace de baja que funciona y, en el caso de los remitentes masivos, la cabecera de un clic List-Unsubscribe descrita en la RFC 8058, que las directrices para remitentes de Google exigen a los remitentes masivos. Los correos transaccionales, como los de restablecimiento, no deberían bloquearse por una baja.
• Tiempo de entrega. Los correos de verificación que tardan más de un par de minutos hacen perder usuarios. Si uno va lento, mira si tu app pone el correo en cola detrás de otras tareas o si el proveedor limita a los remitentes nuevos.
• Tus propios límites de frecuencia. Machaca el botón de reenviar. La app debería limitarlo y pedir al usuario que espere, en lugar de enviar diez códigos o fallar sin avisar.
• Reutilizar una dirección. Regístrate dos veces con la misma dirección en una misma sesión y revisa el segundo intento: un camino claro de "ya registrado" y ninguna segunda cuenta.
• Tu regla contra dominios desechables. Si tu producto bloquea direcciones temporales, confirma que el mensaje de error es claro y que no bloquea también por error a proveedores reales. Más sobre esto abajo.

Nuestros límites y lo que suponen para una prueba

Esta es la configuración real de nuestros servidores. Planifica las pruebas teniéndola en cuenta.

Duración

Una hora desde la creación. +1 h la devuelve a una hora completa, hasta 24 horas después de la creación. Suficiente para una sesión, no para una cuenta de prueba que vayas a reutilizar el próximo sprint.

Mensajes

Hasta 50 mensajes y 5 MB por buzón. En cuanto se alcanza cualquiera de los dos límites se rechaza el correo nuevo, así que una prueba de carga dirigida a una sola dirección deja de contar enseguida. Abre un buzón nuevo por usuario de prueba.

Tamaño del mensaje

Hasta 1 MB por correo, adjuntos incluidos. Solo se conservan los 10 primeros adjuntos.

Solo recepción

La dirección no puede enviar ni responder. Los flujos en los que el usuario tiene que responder por correo, como los hilos de tickets de soporte, no se pueden probar aquí de principio a fin.

Dominio

Un único dominio para todas las direcciones. Si tu producto bloquea dominios temporales conocidos, bloqueará el nuestro, lo cual es útil cuando ese es justo el comportamiento que quieres probar.

Buzones nuevos

Cinco buzones nuevos por minuto desde una misma dirección IP. Un equipo de QA que sale por la misma conexión de la oficina comparte ese cupo.

Eliminación

Tras la caducidad, una limpieza que se ejecuta cada cinco minutos elimina el buzón, sus mensajes y sus adjuntos. Haz capturas de pantalla antes de que se acabe el tiempo si necesitas pruebas para un informe de error.

Automatización

No hay una API pública para acceder a los buzones mediante scripts. PureTempMail está pensado para una persona delante de un navegador, y por eso las suites automatizadas deben usar las herramientas que se mencionan más abajo.

Comprobar SPF, DKIM y DMARC en tus correos de prueba

Un mensaje que se ve bien puede no superar la autenticación y acabar en spam para los usuarios reales. Para comprobarlo, envía el mismo correo a un buzón que muestre el código fuente sin procesar, como la opción Mostrar original de Gmail, y pega las cabeceras en nuestro analizador de cabeceras de correo. Te muestra si SPF, DKIM y DMARC se superaron, avisa de un Reply-To en otro dominio y señala dónde se retrasó la entrega. El análisis se hace en tu navegador, así que las cabeceras no se nos envían.

Probar tu propio bloqueo de dominios desechables

Muchos equipos añaden a su formulario de registro una comprobación contra el correo desechable y nunca la prueban con una dirección temporal real. Una bandeja temporal es la entrada de prueba evidente.

• Revisa el texto. El rechazo debería decir qué usar en su lugar, por ejemplo "Usa una dirección personal o del trabajo". Un simple "Correo no válido" manda a los usuarios honrados a buscar una errata que no existe.
• Busca falsos positivos. Prueba direcciones de pequeños proveedores regionales y de dominios propios de empresas. Las listas de bloqueo que funcionan por patrones a veces las atrapan.
• Revisa todos los puntos de entrada. La misma regla debería aplicarse al formulario de registro, al ajuste para cambiar el correo, a las invitaciones y a la API; si no, la gente usará sin más el camino que se te olvidó.
• Decide si de verdad necesitas el bloqueo. Nuestro artículo sobre por qué las webs bloquean el correo desechable repasa los costes que lo justifican y los casos en los que solo te hace perder usuarios honrados.

Cuándo una bandeja temporal pública no es la herramienta adecuada

En estos casos, usa otra cosa.

• Cualquier cosa con secretos reales o datos de clientes. Tokens de producción, facturas reales, invitaciones de administrador. Usa un sandbox que solo pueda leer tu equipo.
• Pruebas automatizadas y CI. Apunta la app a un capturador local como Mailpit en desarrollo y CI, y a un sandbox alojado como Mailtrap o Mailosaur cuando las pruebas deban ejecutarse contra un entorno desplegado. MailHog, el capturador local más antiguo, ya no se mantiene, y Mailpit es su sustituto habitual.
• Entornos de staging con copias de datos reales de usuarios. Ahí el fallo son los datos copiados. Anonimízalos y dirige el correo de staging a un capturador para que ninguna prueba escriba nunca a un cliente real.
• Cuentas de prueba que necesitas conservar. Una cuenta de demostración para ventas o una cuenta de revisión para una tienda de apps necesita una dirección que funcione el mes que viene. Usa direcciones con signo más en un buzón del equipo o un catch-all en un dominio de pruebas propio.
• Datos de prueba que nunca deben entregarse. Para datos semilla y pruebas unitarias, usa los dominios reservados como example.com y el dominio de nivel superior .test reservado en la RFC 2606. El correo dirigido a ellos no llega a ninguna parte, por diseño.

Fuentes

• Mailpit en GitHub, la herramienta y API de pruebas de correo para desarrolladores, y sus notas sobre cómo sustituir MailHog.
• Documentación de Mailtrap Email Sandbox.
• Bibliotecas cliente de Mailosaur en GitHub.
• RFC 8058, Signaling One-Click Functionality for List Email Headers.
• Google, directrices para remitentes de correo.
• RFC 2606, Reserved Top Level DNS Names.
• La duración de los buzones, los límites de tamaño y número, los límites de frecuencia, el rechazo SMTP tras la caducidad y la frecuencia de limpieza proceden de la configuración de los propios servidores de PureTempMail, también resumida en las preguntas frecuentes.