Un flujo de registro y de recuperación de acceso no se puede dar por probado hasta que se ejecuta con un correo real y un código o enlace reales: un simulador en lugar del correo solo valida el formulario, pero no toda la cadena de entrega, la lectura del código y el paso por el enlace. Para eso, el tester no necesita un único buzón universal, sino direcciones elegidas para cada escenario y cada sitio concretos. Veamos para qué sirve esto, por qué el correo personal y el de trabajo no son adecuados aquí, cómo elegir entre una dirección de uso único y un alquiler, y qué conviene registrar en la documentación de pruebas.

Por qué el tester necesita direcciones de correo independientes

Un flujo de registro de extremo a extremo no consiste solo en llenar un formulario: el sitio debe enviar el correo, el tester debe recibirlo, extraer el código o abrir el enlace y cerrar la cadena entrando a la cuenta. Un simulador que simplemente inserta un código fijo en la base de datos se salta todo lo que ocurre entre el envío del correo y su recepción: el retraso en la entrega, el formato del correo de cada sitio, el comportamiento al abrir el enlace desde otro cliente. Descubrir que la entrega real falla (el correo cae en spam, tarda horas o llega con el enlace cortado) solo es posible con una dirección real que efectivamente reciba correo.

Por qué el correo personal y el corporativo no sirven para esto

Usar un buzón personal para los registros de prueba parece una solución rápida, pero llena el correo de mensajes de decenas de cuentas de prueba y dificulta después encontrar los correos importantes en la bandeja personal. El correo corporativo añade un riesgo de otro tipo: una cuenta de prueba registrada con una dirección de trabajo puede terminar mezclada por accidente con procesos reales de la empresa, como entrar en una lista de correo o acceder a integraciones configuradas por dominio. Una dirección de prueba independiente elimina ambos riesgos a la vez: existe para una sola tarea y no se cruza ni con la correspondencia personal ni con los datos reales de la empresa.

Activación única o alquiler: qué elegir según el escenario

La elección depende de cuántos correos se esperan dentro del escenario. Si la prueba verifica un solo paso (el registro y la confirmación con un único correo), basta con una activación única: un buzón temporal para un sitio concreto que vive 20 minutos y se cierra por tiempo de espera con devolución automática del dinero si el correo no llegó. Si el escenario es más complejo y requiere correos repetidos a la misma dirección (por ejemplo, registro, luego recuperación de contraseña y luego un nuevo inicio de sesión con confirmación por correo), la activación única no alcanza, porque la dirección se cierra justo después del primer correo. Aquí hace falta un alquiler de buzón por un período de 12 horas a 60 días con opción de prórroga: hay presets de 12, 24 y 48 horas, una semana, un mes y 60 días, lo que cubre tanto una ejecución corta de regresión como unas pruebas de varios días de una versión.

El aislamiento de los datos de prueba frente a los reales como regla

La regla es simple: los datos de prueba no deben cruzarse con los reales ni en direcciones, ni en cuentas, ni en canales de notificación. El buzón alquilado ayuda aquí desde la arquitectura: recibe correos solo de los sitios indicados al hacer el pedido, es decir, esa misma dirección de prueba físicamente no puede recibir por accidente un correo de un servicio ajeno y confundir el escenario. Esto es especialmente importante cuando se prueban en paralelo varias versiones de un mismo producto o varios entornos: cada escenario debe tener su propia dirección, para que los correos de distintas ejecuciones no se mezclen en un mismo buzón ni confundan el resultado de la verificación.

Qué registrar en la documentación de pruebas

Para que una ejecución de pruebas se pueda reproducir y explicar a un colega sin preguntas, en la documentación del escenario conviene registrar tres cosas: qué dirección exacta se usó, para qué sitio o servicio se pidió y cuál es su período de vida, es decir, si expiró justo después del correo o sigue activa para una verificación posterior. Sin este registro, una semana después es difícil entender por qué no se puede repetir la ejecución: la dirección se cerró automáticamente según las reglas del formato, y no porque algo se haya roto en el escenario.

Cuándo bastan las herramientas gratuitas y cuándo conviene alquilar

Si ya tienes un dominio propio y un hosting de correo que admite muchas direcciones, y el volumen de registros de prueba es pequeño, para verificaciones aisladas puedes arreglártelas con eso: no todas las tareas requieren una dirección de pago. Pero en cuanto las pruebas se multiplican y los escenarios exigen aislamiento entre ejecuciones y la garantía de que a un buzón no llegará el correo de otra prueba, resulta más sencillo alquilar un buzón para una tarea o un sitio concreto: así te ahorras la administración y mantienes cada escenario por separado. Una lógica similar para elegir entre un simulador y un código real en ejecuciones automatizadas se explica en el artículo sobre pruebas automatizadas con códigos reales en CI.

Preguntas frecuentes

¿Sirve la activación única para probar el escenario de recuperación de contraseña?

Solo si la recuperación se prueba en una ejecución aparte, justo después de obtener la dirección. Si el escenario prevé primero el registro y la recuperación como un paso posterior, la activación única no alcanza: la dirección ya estará cerrada. Para una cadena así se necesita un alquiler de buzón por un período.

¿Qué hacer si el escenario de prueba requiere correos de varios servicios en una misma dirección?

Al contratar el alquiler hay que indicar desde el principio todos los sitios de los que se esperan correos: el filtro del buzón aceptará correo solo de la lista declarada, y no será posible añadir un sitio después.

¿Y si hay muchas pruebas y crear una dirección para cada una a mano resulta incómodo?

Si el alquiler y la activación única están disponibles mediante API, el pedido de la dirección se puede integrar en la preparación del entorno de pruebas y obtener la dirección de forma programática antes de cada ejecución, sin hacerlo a mano desde la interfaz.

Puedes contratar una activación única para el sitio que estás probando o alquilar un buzón por el período de tu escenario de extremo a extremo en la sección email-OTP.