Las pruebas de verificación por correo suelen reducirse a un caso feliz: se envía el mensaje, se pulsa el enlace y la cuenta queda confirmada. El problema es que ese camino representa una fracción pequeña del comportamiento real. Entre medias hay enlaces caducados, clics repetidos, cambios de navegador y mensajes que no llegan nunca, y cada uno de esos escenarios tiene su propia forma de fallar.
Qué comprueba de verdad una verificación por correo
El objetivo del mecanismo es demostrar que quien se está registrando controla esa dirección. Para lograrlo, el sistema genera un enlace o un código único, lo envía y espera a que vuelva. Si vuelve, la hipótesis se confirma; si no, el alta queda en un estado intermedio que hay que gestionar con cuidado.
Ese estado intermedio es la parte interesante del diseño. Casi todos los fallos graves aparecen ahí: cuentas que quedan a medio crear, direcciones que se marcan como verificadas sin que nadie lo haya hecho y usuarios que no entienden por qué no pueden entrar.
Antes de escribir pruebas conviene tener claro qué se promete en cada momento. ¿Se puede iniciar sesión sin verificar? ¿Se puede volver a pedir el mensaje? ¿Cuánto tarda el enlace en dejar de servir? Sin esas respuestas, las pruebas no comprueban el producto, comprueban la imaginación de quien las escribió.
¿Qué caminos hay que probar además del caso feliz?
Estos son los que aparecen una y otra vez en producción.
- El enlace correcto, abierto en el navegador donde se inició el registro.
- El mismo enlace abierto una segunda vez, para comprobar que no se puede reutilizar.
- Un enlace antiguo, de un envío anterior, que debe dejar de funcionar.
- El cambio de navegador o de dispositivo entre el registro y la confirmación.
- Dos altas distintas con la misma dirección, para ver cuál sobrevive.
- El caso incómodo: el mensaje nunca llega y el usuario insiste.
Cada uno de esos caminos debería terminar en un estado definido y explicable. Si el sistema responde a un enlace caducado con un error genérico, el usuario no sabrá si debe pedir otro mensaje o abandonar.
Enlaces caducados y enlaces reutilizados
Un enlace de verificación suele ser de un solo uso y de duración corta. Esas dos propiedades no son caprichos: evitan que un enlace filtrado sirva meses después y que dos personas confirmen la misma operación con la misma prueba.
Para comprobarlas hace falta provocar la caducidad de forma deliberada y verificar que el sistema la detecta. Esperar a que pase el tiempo real es una opción lenta y frágil; casi siempre existe una manera de preparar el escenario sin aguardar.
El caso del enlace reutilizado merece atención aparte. Si la segunda visita muestra la pantalla de éxito otra vez, la prueba está mintiendo: alguien podría creer que acaba de confirmar algo que ya estaba confirmado, o peor, que acaba de confirmar algo distinto.
Dos cuentas con la misma dirección
Es un escenario más habitual de lo que parece, sobre todo en equipos donde varias personas comparten una dirección de soporte o de administración. El sistema tiene que decidir si la dirección es única por cuenta, qué ocurre con la segunda y cómo se informa al usuario.
La decisión importa porque afecta a la recuperación de contraseña. Si dos cuentas comparten dirección, el enlace de restablecimiento tendrá que distinguir a cuál de ellas se refiere, y ese detalle se olvida con facilidad.
Una forma útil de tratarlo es escribir el resultado esperado como una frase antes de programar la prueba: con esta dirección ya registrada, el segundo intento debe responder de esta manera concreta. La frase obliga a decidir el comportamiento en lugar de descubrirlo cuando falla.
¿Cómo se prueba el caso en que el mensaje nunca llega?
Simulando el silencio. La prueba consiste en provocar el envío, no recibir nada y comprobar que la interfaz ofrece una salida razonable: volver a pedir el mensaje, cambiar de dirección o contactar con soporte. Lo que no puede pasar es que la pantalla se quede esperando para siempre sin explicar nada.
También conviene medir el efecto secundario del reenvío: si el usuario pulsa varias veces el botón de reenviar, el sistema debe limitar la frecuencia sin dejar la cuenta en un estado ambiguo. El límite es una protección, y la prueba debe confirmar que existe, no desactivarlo para que el caso pase.
Recibir el mensaje en un buzón de pruebas
Para automatizar estos escenarios, la dirección de destino no puede ser la de una persona. En el buzón de correo temporal de este sitio se genera una dirección nueva para cada caso, se usa en el formulario y el mensaje aparece en la bandeja de la propia página, listo para copiar el enlace o el código.
Si el flujo que se está probando depende de un mercado concreto, la página de México resume los formatos locales de direcciones y teléfonos, un detalle que evita falsos negativos cuando el formulario valida por región.
Notas para quien programa
- Modela el estado de la cuenta con nombres explícitos, por ejemplo pendiente, verificada y en cambio de dirección. Los estados implícitos son el origen de la mitad de los fallos.
- Haz que el enlace sea de un solo uso y comprueba la segunda visita, no solo la primera.
- Prueba el clic concurrente: dos peticiones a la vez sobre el mismo enlace no deberían producir dos confirmaciones.
- No bases la prueba en esperar un tiempo fijo a que llegue el mensaje; sondea hasta que aparezca con un límite claro.
- Deja siempre una ruta de salida visible para quien no recibe el correo. Es el caso más frecuente y el que peor se suele tratar.
Siguientes pasos
Elige el flujo de verificación de tu producto y escribe los seis caminos de la lista anterior como casos concretos, con el resultado esperado en una frase cada uno. Los que no sepas describir son los que todavía no están diseñados.
Para los casos en que el código se lee dentro de una prueba de extremo a extremo, la guía sobre códigos de un solo uso en pruebas automáticas explica cómo extraerlo sin intervención humana.
La dirección que se usa aquí existe para validar un flujo, jamás para representar a una persona ante un tercero.