1) Preparación de entorno y datos de prueba

• Entorno: confirma si estás en staging, preprod o prod; revisa feature flags de signup/OTP.
• Plantillas: identifica la plantilla exacta de “verificación” y “OTP” (título, remitente, cuerpo, enlaces).
• Proveedor: ten a mano al menos 2–3 correos desechables de proveedores distintos para comparar comportamiento.
• Variables: define país/idioma, zona horaria, tipo de usuario (nuevo vs existente), y canal (web/iOS/Android).
• Observabilidad: habilita logs con IDs correlacionables (request_id, user_id hash, otp_id) sin exponer PII.

Consejo de QA: antes de iniciar, acuerda con backend cómo se rastrea una solicitud OTP de extremo a extremo (API → cola → proveedor email → entrega → verificación). Sin esa trazabilidad, los bugs se vuelven “fantasmas”.

2) Validaciones del formulario de registro

Entrada de email

• Formato correcto: dominios con subdominios, plus addressing, mayúsculas, espacios al inicio/fin, caracteres unicode.
• Normalización: trim, lowercasing cuando aplique, y comparación consistente para evitar duplicados.
• Mensajes de error claros: no revelar si un email existe (evitar enumeración de cuentas).
• Autocompletado: en móvil, teclado tipo email, autocorrección desactivada, accesibilidad del label.

Contraseña y políticas

• Reglas: longitud, complejidad, listas de contraseñas comunes, y feedback en tiempo real sin bloquear el flujo.
• Mostrar/ocultar: botón accesible, no rompe foco, no cambia el layout.
• Copiar/pegar: permitido (mejor UX) y no rompe validación.

Aceptación de términos

• Checkbox obligatorio: errores visibles y accesibles.
• Links a política/terms: abren correctamente (webview externa/in-app según plataforma) y vuelven al flujo sin perder estado.

3) Envío del email de verificación: entrega y contenido

Con correo desechable, lo más frecuente es fallar en la entrega o en el tiempo. Tu QA debe medir y verificar: ¿se envía?, ¿se entrega?, ¿se ve?, ¿se entiende?, ¿se puede usar?

Deliverability básica

• Remitente coherente: nombre y dirección; evita remitentes genéricos que disparan filtros.
• Asunto útil: identifica producto y acción (“Verifica tu cuenta”, “Tu código de acceso”).
• Tiempo de llegada: prueba en red rápida y lenta; mide retrasos; verifica reintentos de la cola.
• Duplicados: al pedir reenvío, llega un email nuevo (no se recicla el anterior de forma confusa).

Contenido del email

• Enlaces: abren en el navegador correcto, y redirigen a una página final con confirmación clara.
• Fallback: si hay link y código, ambos funcionan; si el link expira, el código sigue un flujo consistente.
• HTML vs texto: el email se entiende en ambos; imágenes no son requisito.
• Localización: idioma correcto según selección del usuario; formatos de fecha/hora coherentes.

Seguridad del enlace

• Token: longitud suficiente, no predecible, y con expiración.
• Uso único: el mismo link no debe verificar dos veces de forma peligrosa; manejo de “ya verificado”.
• No filtrar datos: el link no debe incluir PII en claro (email, nombre, etc.).

4) OTP: generación, expiración y reintentos

Generación y formato

• Longitud y tipo: 6 dígitos o lo que defina el producto; consistente en UI, email y backend.
• Caracteres ambiguos: si es alfanumérico, evita confusión (O/0, I/1) o usa dígitos.
• Vinculación: OTP ligado a propósito (login/signup/reset) y a un identificador (sesión o intento).

Expiración

• Expira en el tiempo esperado: UI muestra un contador real o un mensaje no engañoso.
• Uso tras expiración: error claro y opción de solicitar uno nuevo.
• Tiempo del servidor: no depende del reloj del dispositivo; prueba con hora del móvil alterada.

Reenvíos y límites

• Botón “Reenviar”: deshabilitado el tiempo correcto; evita spamming accidental.
• Rate limit: después de N intentos, bloqueo temporal; mensajes no revelan demasiado.
• Invalidación: al generar un OTP nuevo, el anterior debería invalidarse (según política) y esto debe ser consistente.

Intentos de verificación

• Intentos fallidos: cuenta atrás, bloqueo o captcha (si existe); logs de seguridad registran el patrón.
• Brute force: verifica que el backend corta intentos repetidos incluso si el UI no lo impide.
• Errores de red: si la verificación falla por timeout, la app no debe marcar el OTP como “usado” sin confirmación.

5) Experiencia de usuario: el flujo debe sentirse “fluido”

Un usuario con correo desechable suele estar en modo “rápido”: quiere entrar, copiar el código y seguir. Tu QA debería asegurarse de que el flujo no castiga ese comportamiento.

• Copiar OTP: el email muestra el código claramente; la app permite pegar; no bloquea por formato.
• Autofill: en iOS/Android, prueba sugerencias de código (si existen) y que no rompan el foco.
• Estados de carga: botones con spinner, sin dobles envíos; errores recuperables.
• Volver atrás: navegar atrás no debería “romper” la sesión ni duplicar intentos.
• Mensajes: evita textos técnicos (“token inválido”); usa “código incorrecto o caducado”.

6) Casos límite que rompen releases (pruébalos siempre)

Email llega tarde

• OTP caduca antes de llegar: el sistema debe soportar pedir uno nuevo sin confusión.
• El usuario recibe dos OTP: la UI debe explicar cuál usar (idealmente el más reciente).

El correo desechable caduca

• El buzón desaparece a mitad del flujo: la app debe permitir cambiar email o reiniciar registro sin quedar bloqueado.
• El usuario intenta recuperar: el producto no debe sugerir “revisa tu bandeja” si ya no existe; ofrece alternativas.

Cuenta ya existente

• Registro con email ya usado: mensaje que no confirma existencia (seguridad) pero guía el siguiente paso.
• Si el usuario elige “iniciar sesión”, el flujo se redirige sin perder contexto.

Verificación repetida

• Click en link dos veces: “ya verificado” sin error 500.
• OTP ya usado: respuesta consistente; no se permite reutilización.

7) Antiabuso y detección de correos desechables

Algunas empresas deciden bloquear dominios temporales. Otras los permiten, pero aplican controles. Sea cual sea tu política, QA debe validar que el comportamiento es coherente y no genera falsos positivos masivos.

• Si bloqueas: el error debe aparecer en el momento correcto (idealmente en el campo email), con explicación no agresiva.
• Si permitís: revisa límites extra para OTP, captcha adaptativo o throttling en intentos sospechosos.
• Listas: si hay “allowlist/denylist” de dominios, prueba un dominio nuevo y uno conocido para confirmar la lógica.
• Telemetry: registra “dominio temporal detectado” como evento sin almacenar el email en claro.

8) iOS y apps: puntos que suelen fallar

Deep links y navegación

• Link de verificación abre la app (si corresponde) y aterriza en pantalla correcta.
• Si la app no está instalada: abre web y permite continuar o descargar.
• Retorno desde navegador: no se pierde la sesión del registro.

Permisos y seguridad

• Evita exponer el OTP en notificaciones o logs locales.
• Si hay portapapeles: no “copies” automáticamente sin intención; respeta privacidad.
• Capturas de pantalla: si el producto es sensible, valida políticas (según requisitos) sin romper UX.

9) Backend: integridad, consistencia y mensajes correctos

• Idempotencia: reintentar “enviar OTP” por timeout no debe crear estados corruptos.
• Estados: usuario “pendiente de verificación”, “verificado”, “bloqueado” y transiciones claras.
• Errores: códigos HTTP correctos; mensajes de UI no exponen detalles internos.
• Colas: si hay worker caído, el sistema alerta; QA puede simular y verificar degradación.
• Persistencia: no guardes OTP en texto plano; valida hashing o equivalentes según arquitectura.

10) Analítica y métricas: saber dónde se cae el usuario

En flujos con OTP y correo desechable, la conversión se pierde en mil detalles. Si no mides, no mejoras. QA puede validar que los eventos existen y se disparan una sola vez, con parámetros correctos.

• Eventos sugeridos: signup_started, signup_submitted, verification_sent, otp_requested, otp_verified, verification_failed.
• Parámetros útiles: plataforma, país/idioma, tipo de flujo, motivo de error (sin PII).
• Funnel: confirma que el usuario no cuenta doble si vuelve atrás o reintenta.

11) Accesibilidad y calidad visual

• Lectores de pantalla: labels correctos, errores anunciados, focus manejado al mostrar validaciones.
• Contraste: botones y textos legibles; estados deshabilitados distinguibles.
• Teclado: navegación por tab, enter para enviar, escape para cerrar modales.
• Responsive: en móviles pequeños, el campo OTP no se corta; el teclado no tapa CTA.

12) Resultado esperado: criterios de “pasa/no pasa”

Para cerrar QA con claridad, define criterios verificables:

• El usuario puede completar registro y verificación con un correo desechable típico sin fricciones graves.
• Los OTP llegan con contenido correcto, dentro de tiempos razonables y con reenvíos controlados.
• Errores y expiraciones se comunican de forma clara, recuperable y segura.
• Rate limits y controles antiabuso funcionan sin bloquear a usuarios legítimos.
• Los enlaces y deep links se comportan bien en web, iOS y Android, sin pérdida de estado.
• La analítica registra el funnel sin duplicidades ni PII en claro.

Si tu checklist pasa estos puntos, tu flujo está listo para soportar el uso real: usuarios con prisa, redes imperfectas, buzones temporales que caducan y un ecosistema de dispositivos variado.