1) Preparación de pruebas (antes de picarle “Registrar”)

• Ambientes: valida en staging y en prod-like (mismas reglas de correo, SPF/DKIM/DMARC, throttling, proveedores SMTP).
• Datos de prueba: define un set de emails: reales, desechables, dominios comunes, dominios “edge” (subdominios, TLD raros).
• Parámetros visibles: confirma dónde se configuran TTL del OTP, número de intentos, ventana de reenvío y rate limits.
• Observabilidad: asegúrate de tener logs/trace para: email send request, provider response, OTP created, OTP verified, OTP failed.
• Requisitos legales/privacidad: revisa qué se guarda del email y por cuánto tiempo, y qué se enmascara en logs.

Tip práctico: si el equipo no puede ver claramente los tiempos de expiración, reintentos y límites, lo más probable es que haya inconsistencias entre frontend y backend. Ese desalineo termina en tickets tipo “no me llega el código”.

2) Casos base del flujo de registro

2.1 Validación de email (cliente y servidor)

• Formato válido: nombre@dominio.tld con casos normales y variantes (puntos, guiones, subdominios).
• Formato inválido: sin @, doble @, espacios, caracteres raros, dominio incompleto, TLD faltante.
• Normalización: manejo de mayúsculas/minúsculas, trimming, espacios invisibles, unicode confusable (si aplica).
• Mensajes de error: claros, consistentes, sin “culpar” al usuario, y con foco en el siguiente paso.

2.2 Creación de cuenta y estado intermedio

• Al enviar el email: se crea un “registro pendiente” o no, según diseño, pero debe ser consistente y auditable.
• Si el usuario abandona el flujo: estado “pendiente” expira correctamente y no bloquea futuros intentos.
• Si el usuario vuelve y reintenta: el sistema ofrece una ruta clara (reenviar OTP, cambiar email, continuar).

3) Checklist de OTP: entrega, expiración y reintentos

3.1 Entrega del correo (deliverability)

• El correo llega en un tiempo razonable en distintos proveedores (no asumas que todos entregan igual).
• Asunto y remitente consistentes (evita que parezca phishing).
• El contenido del correo muestra claramente el código y/o un botón alterno (link mágico si lo usan).
• En correos desechables: valida que la bandeja reciba el mensaje y que el HTML se renderice legible.
• Fallback: si el HTML falla, el texto plano debe contener el OTP y la instrucción principal.

3.2 Expiración (TTL) del OTP

• El OTP expira exactamente como se promete en la UI (si la UI dice 10 min, backend no puede ser 5 o 15).
• Al expirar, el error es explícito: “código expirado” y ofrece reenviar sin fricción.
• Los OTP previos quedan invalidados cuando se genera uno nuevo (si esa es la regla).
• Prueba “al borde”: ingresar el código justo antes del TTL y justo después, para ver consistencia.

3.3 Reenvío (resend) y ventanas de espera

• El botón de “Reenviar código” respeta un cooldown (por ejemplo, 30–60s) y muestra un contador claro.
• Si el usuario pide reenvío múltiple: el sistema no manda 10 correos seguidos sin control.
• El último código enviado es el que vale (si se invalida el anterior, la UI lo debe reflejar).
• Al reenviar, el usuario entiende que debe usar el código más reciente.

3.4 Intentos fallidos y bloqueo

• Número de intentos erróneos permitido: consistente y comunicable (sin revelar demasiado para seguridad).
• Al exceder intentos: se bloquea el OTP actual y se ofrece reenviar o reiniciar el flujo.
• La app no permite brute force: rate limit por IP, por email y/o por sesión según riesgo.
• Los mensajes de error no filtran información (no confirmar si un email existe si no corresponde).

4) Disposable email: escenarios específicos que rompen flujos

4.1 Bloqueo de dominios desechables

• Si bloquean dominios desechables: el mensaje debe ser claro y ofrecer alternativa (usar email real o dominio permitido).
• Evita bloquear por error dominios corporativos o educativos que parezcan “temporales” (falsos positivos).
• Si se permite desechable: confirma que no haya tratamiento diferente silencioso (por ejemplo, envío lento o filtrado).

Aquí se comete un clásico: el frontend permite continuar, pero el backend rechaza al enviar OTP. Resultado: usuario atorado con un error genérico. Si se va a bloquear, bloquea temprano y con mensaje entendible.

4.2 Expiración del inbox (10 minutos de verdad)

• Simula que el inbox del correo desechable “muere” antes de completar el flujo y valida el camino de recuperación.
• Si el usuario cambia de email en medio del flujo: ¿se limpia el estado anterior? ¿se invalida OTP previo?
• Si el usuario intenta recuperar cuenta con email desechable: ¿qué experiencia le das (y qué riesgos acepta el producto)?

4.3 Duplicados y race conditions

• Reenvíos rápidos pueden generar múltiples OTP. Confirma cuál queda activo y cómo se comunica al usuario.
• Prueba doble click / taps repetidos en “Enviar código” con red lenta (debe ser idempotente).
• Prueba refrescar página o cerrar app justo después de pedir OTP y reabrir: el estado debe ser recuperable.

5) UX: microcopys, estados y fricción (lo que sí afecta conversión)

• Estados claros: “Enviamos un código a…” con el email parcialmente enmascarado.
• Edición: opción visible para cambiar email sin tener que “volver al inicio” de manera confusa.
• Autofocus: cursor en el primer input del OTP; avanzar automáticamente al siguiente dígito.
• Pegar el código: si pegas 6 dígitos, se distribuyen en los campos sin romperse.
• Loading y latencia: spinners con timeout y fallback (“Si no llega, revisa spam o reenvía”).
• Mensajes MX-friendly: directos y sin tecnicismos: “El código expiró, pide uno nuevo”.

Si tu UI obliga a esperar sin explicación o castiga al usuario por reintentar, la gente se va. QA no solo valida “funciona”, valida “funciona con estrés y con humanos”.

6) Accesibilidad (A11y) y compatibilidad

• Inputs del OTP con labels accesibles, navegación con teclado y lectura correcta con screen readers.
• Contraste suficiente en botones, contador de reenvío y mensajes de error.
• Soporte en mobile: teclado numérico, autocorrect desactivado, no romper con paste.
• Mensajes de error anunciados (aria-live o equivalente) para que no “desaparezcan” para usuarios con lector.

7) Seguridad y anti-abuso (sin romper la experiencia)

• Rate limiting en endpoints de enviar OTP y verificar OTP (por IP, por email, por device, según riesgo).
• Protección contra enumeración: no revelar si un email ya existe (o hacerlo solo si el producto lo exige).
• Idempotencia: mismo request repetido no debe crear múltiples cuentas ni múltiples OTP sin control.
• Auditoría: registro de eventos clave, con datos enmascarados, para investigar incidentes.
• Expiración de sesión: si el OTP se valida, la sesión o token resultante se emite correctamente y se rota si aplica.

Lo ideal es que seguridad sea “invisible” cuando el usuario es legítimo, y muy efectiva cuando detecta patrones de abuso. Una mala configuración de límites puede tumbar conversiones en horas pico.

8) Observabilidad: qué medir y qué registrar

8.1 Métricas de producto / funnel

• Signup started → OTP requested → OTP delivered (proxy) → OTP verified → signup completed.
• Tiempo promedio entre OTP requested y OTP verified.
• Tasa de reenvíos por usuario y por sesión.
• Tasa de fallos: código incorrecto, expirado, rate-limited, dominio bloqueado.
• Drop-off en pantalla OTP (el “hoyo negro” típico del onboarding).

8.2 Logs técnicos útiles

• ID de correlación por intento de OTP para seguir el flujo end-to-end.
• Estado de envío del proveedor (accepted, bounced, deferred) cuando sea posible.
• Razón de rechazo (bloqueo por dominio, rate limit, intentos excedidos), con códigos internos estandarizados.
• Enmascarado correcto de email en logs y dashboards.

9) Checklist de pruebas negativas (las que sí encuentran bugs)

• Ingresar OTP con dígitos faltantes, letras, espacios, caracteres especiales.
• Ingresar un OTP viejo después de pedir reenvío.
• Ingresar OTP válido después de expiración.
• Reenviar OTP muchas veces (con y sin cooldown) para validar límites y mensajes.
• Cambiar email después de pedir OTP y luego intentar validar con el código del email anterior.
• Probar con red lenta, modo avión intermitente, refresh del navegador, cierre de app.
• Probar desde múltiples dispositivos para el mismo email (si tu producto lo permite).

10) Checklist de automatización (smoke + regresión)

Si vas a automatizar, intenta dividir en dos capas: una que valide el flujo lógico (API) y otra que valide la experiencia (UI). Para correo desechable, suele ser más estable automatizar el backend con un “email sink” interno en staging, y dejar los desechables públicos para pruebas manuales periódicas.

• API tests: crear intento OTP, verificar OTP correcto, incorrecto, expirado, reenviado.
• UI smoke: happy path completo (email → OTP → cuenta creada) con inputs y paste.
• Resilience tests: reintentos, doble submit, refresh, pérdida de red.
• Rate limit tests: validar códigos de respuesta consistentes y mensajes UX amigables.

11) Plantilla de ejecución rápida (para el día a día de QA)

1. Registrar con correo desechable y validar que el OTP llegue y se vea bien.
2. Confirmar que el contador de expiración y cooldown de reenvío coinciden con el backend.
3. Reenviar OTP y validar que el código anterior ya no funcione (si esa es la regla).
4. Forzar expiración y validar el mensaje + ruta de recuperación (reenviar / cambiar email).
5. Probar intentos fallidos hasta límite y validar bloqueo + UX.
6. Repetir con otro dominio y validar que no haya bloqueos falsos positivos.
7. Revisar métricas/logs: correlación end-to-end, errores clasificados y sin datos sensibles expuestos.

Si este mini-recorrido pasa sin sorpresas, normalmente tu flujo de signup + OTP está en buena forma. Si falla, casi siempre cae en una de tres: desalineo de tiempos, reenvíos mal gestionados o reglas anti-abuso demasiado agresivas.

Cierre

Los correos desechables son una lupa perfecta para encontrar fragilidad en onboarding: hacen visibles los problemas de entrega, los “race conditions” de reenvío, y las decisiones de producto sobre bloqueo o permisividad. Con esta checklist puedes convertir un flujo que “funciona a veces” en un flujo confiable, medible y resistente.

Si tu meta es mejorar conversión, trata la pantalla de OTP como una pantalla de pago: todo debe ser claro, rápido, consistente y recuperable. Ahí se gana (o se pierde) la confianza del usuario.