Un código OTP en pruebas automáticas obliga a resolver un problema que el navegador no puede resolver solo: la cifra llega por correo, fuera de la aplicación que se está probando. La prueba tiene que ir a buscarla, quedarse con la correcta y devolverla al formulario. Cuando ese circuito se rompe, el fallo aparece en el peor sitio posible: como un error intermitente que nadie sabe explicar.
Qué se está probando cuando se prueba un código OTP
No se está probando solo que el correo llegue. Se está probando que el sistema genere un código válido, que lo asocie al intento correcto, que lo envíe al destinatario adecuado, que lo acepte una vez y que lo rechace cuando corresponde. Ese conjunto de promesas es mucho más amplio que el mensaje en sí.
Conviene separar dos niveles. Por un lado está la prueba de integración, rápida y sin navegador, que comprueba el ciclo de vida del código: se emite, se consume, caduca. Por otro está la prueba de extremo a extremo, lenta y con interfaz, que confirma que una persona puede completar el recorrido.
Si todo se concentra en el nivel lento, cualquier problema del correo se convierte en una suite que falla a diario y que nadie se atreve a tocar.
¿Por qué falla la prueba aunque el código haya llegado?
Casi siempre por una de estas cuatro razones.
- La prueba busca el mensaje antes de que llegue. Basta un retraso normal para que la búsqueda devuelva la bandeja vacía.
- Encuentra un mensaje antiguo, de una ejecución anterior, y extrae un código que ya no sirve.
- Hay más de un código en el mismo cuerpo, y el patrón de búsqueda elige el equivocado.
- El código se ha extraído bien, pero se ha escrito en el campo equivocado o con un espacio de más.
Ninguna de esas causas tiene que ver con la funcionalidad que se quería probar. Esa es la razón por la que merece la pena invertir en hacer robusta la lectura, en lugar de subir el tiempo de espera cada vez que algo falla.
Elegir el mensaje correcto entre varios
El primer criterio debe ser identificar el mensaje, no adivinar. El asunto, el remitente y el destinatario son tres señales que suelen estar disponibles y que permiten descartar todo lo que no pertenece a esta ejecución.
El segundo criterio es la dirección. Si cada caso de prueba usa una dirección propia, la búsqueda se reduce a un único buzón y desaparece casi toda la ambigüedad. Compartir un buzón entre pruebas es la causa más común de que se lea el mensaje de otro.
El tercero es quedarse con el mensaje más reciente que cumpla los criterios, y no con el primero que aparezca. La bandeja puede contener varios envíos del mismo flujo, y el orden no siempre refleja el momento real de llegada.
Un detalle que ayuda mucho es registrar, cuando la prueba falla, el asunto y la fecha del mensaje que se usó. Con ese dato, un fallo intermitente se explica en un minuto en lugar de en una tarde.
Reenvíos y límites de frecuencia
Los sistemas limitan la frecuencia con la que se puede pedir un código nuevo, y ese límite es una protección, no un obstáculo. Una prueba que necesita diez intentos seguidos está provocando el límite y luego quejándose de él.
La forma correcta de convivir con esa restricción es preparar el escenario para que el código llegue al primer intento y reservar los reenvíos para el caso que los estudia de verdad. Si el flujo que se prueba incluye el reenvío, conviene comprobar dos cosas: que el código anterior deja de ser válido y que el nuevo funciona.
Hay además una cuestión de limpieza. Cada intento deja un mensaje en la bandeja, y esos mensajes acumulados son la materia prima de los falsos positivos de la siguiente ejecución. Que el buzón se vacíe entre pruebas, o que cada caso use una dirección nueva, evita la mayor parte del problema.
¿Cuándo hay que dejar a una persona en el circuito?
Siempre que el coste de un falso negativo sea alto. Una comprobación de seguridad, un cambio de contraseña o una operación que mueve dinero merecen una revisión humana antes de publicar, aunque la prueba automática ya pase.
También hace falta una persona cuando el propio sistema de correo está en duda: si los mensajes empiezan a tardar o a llegar a la carpeta de correo no deseado, ninguna automatización puede decidir si el problema está en el producto o en la infraestructura.
Y conviene mantener una comprobación manual mínima para las cadenas de texto. Una prueba automática verifica que el código se extrae, no que la redacción del mensaje siga teniendo sentido.
Un buzón de pruebas para el flujo completo
Para las pruebas manuales y para las exploraciones antes de automatizar, el buzón de correo temporal de este sitio ofrece una dirección nueva en segundos y muestra el código detectado aparte del cuerpo del mensaje, lo que ahorra copiarlo a mano. Es útil para ver con qué aspecto llega el correo antes de escribir el analizador que lo leerá.
Si el flujo que se prueba es el registro, la guía sobre pruebas de verificación por correo cubre los caminos alrededor de esa confirmación. Y para entender por qué el mensaje puede tardar, el artículo sobre cómo funciona el correo temporal repasa el recorrido completo.
Notas para quien programa
- Sondea hasta que aparezca el mensaje, con un límite explícito de tiempo y un error claro al agotarlo.
- Filtra por destinatario y por asunto antes de extraer la cifra. Cuanto más estrecho sea el filtro, menos falsos positivos.
- Normaliza lo que extraigas. Quita espacios, guiones y cualquier carácter que el campo del formulario no acepte.
- No desactives el límite de reenvíos para que la prueba pase. Si el límite estorba, la prueba está mal planteada.
- Guarda el cuerpo original del mensaje cuando el análisis falle. Es la única forma rápida de saber si el formato cambió.
- Deja un caso que compruebe que un código caducado se rechaza. Es tan importante como el camino feliz.
Siguientes pasos
Escribe primero el analizador y pruébalo con mensajes guardados de ejecuciones anteriores; solo después conéctalo a la prueba completa. Separar esas dos fases ahorra la mitad de las horas perdidas en este tipo de test.
Para los mensajes que no llevan código sino un enlace, la lista de comprobaciones de correo transaccional repasa lo que conviene verificar en cada plantilla.
El código que se lee en una prueba pertenece a un flujo simulado: nunca debe reutilizarse como acceso real ni como identidad de nadie.