Por Qué Importa el Testing de Emails y Notificaciones
Los emails y notificaciones son canales críticos de comunicación entre una aplicación y sus usuarios. Un email de restablecimiento de contraseña roto significa que los usuarios no pueden recuperar sus cuentas. Una confirmación de pedido faltante erosiona la confianza. Un email de marketing mal renderizado daña la percepción de marca.
A pesar de su importancia, el testing de emails y notificaciones frecuentemente se pasa por alto porque involucran sistemas externos y son más difíciles de automatizar que el testing de UI.
Tipos de Emails a Probar
Emails Transaccionales
Activados por acciones del usuario — máxima prioridad:
| Tipo de Email | Verificaciones Críticas |
|---|---|
| Confirmación de registro | Link funciona, datos de usuario correctos |
| Restablecimiento de contraseña | Token expira, uso único, entrega oportuna |
| Confirmación de pedido | Items correctos, precios, número de orden |
| Recibo de pago | Montos precisos, impuestos, método de pago |
| Cambios de cuenta | Notificación correcta de qué cambió |
| Autenticación de dos factores | Código válido, expira correctamente |
Emails de Marketing
Enviados a grupos de usuarios:
- Tokens de personalización se resuelven correctamente (nombre, preferencias)
- Link de cancelar suscripción funciona y es prominente
- Cumplimiento CAN-SPAM/GDPR (dirección física, identificación del remitente)
Notificaciones del Sistema
Alertas automatizadas: notificaciones de error a admins, emails de reportes programados, alertas de umbral.
Entorno de Testing de Email
Herramientas para Capturar Emails de Prueba
Nunca envíes emails de prueba a direcciones reales. Usa sandboxes de email:
| Herramienta | Tipo | Características Clave |
|---|---|---|
| Mailtrap | Servicio cloud | Inbox SMTP, preview HTML, análisis de spam |
| Mailhog | Self-hosted | Servidor SMTP local, web UI |
| Ethereal Email | Servicio gratuito | Cuentas SMTP desechables |
Configurando Mailhog Localmente
# Instalar (macOS)
brew install mailhog
# Ejecutar
mailhog
# SMTP: localhost:1025
# Web UI: http://localhost:8025
Qué Probar en Emails
Entrega
- Email llega dentro del tiempo esperado (transaccional: <30 segundos)
- Email no es atrapado por filtros de spam
- Destinatario correcto (campos To, CC, BCC)
- Remitente correcto (dirección From coincide)
Contenido
- Asunto es correcto y personalizado
- Contenido del cuerpo coincide con la acción que lo activó
- Datos dinámicos son correctos (nombres, montos, fechas)
- Links son válidos y apuntan a destinos correctos
- Link de cancelar suscripción presente y funcional
Renderizado HTML
| Funciona Siempre | No Confiable | Evitar |
|---|---|---|
| Tablas para layout | Flexbox | JavaScript |
| CSS inline | CSS externo | CSS Grid |
| Imágenes básicas | SVG | Video |
Prueba renderizado en al menos: Gmail, Apple Mail, Outlook, Yahoo Mail.
Seguridad (Emails Transaccionales)
- Tokens de reset son de uso único
- Tokens expiran después del tiempo apropiado
- Tokens son criptográficamente seguros
- Links usan HTTPS
- Sin datos sensibles expuestos en el cuerpo del email
Ejercicio: Testing de Flujo de Registro y Restablecimiento de Contraseña
Estás probando las notificaciones de email del sistema de autenticación de una aplicación web.
Escenario 1: Email de Confirmación de Registro
| Paso | Acción | Resultado Esperado |
|---|---|---|
| 1 | Registrarse con email test@example.com | Email de confirmación llega en 30 segundos |
| 2 | Verificar asunto del email | “Confirma tu dirección de email” o similar |
| 3 | Verificar remitente | noreply@tuapp.com |
| 4 | Verificar contenido | Contiene nombre del usuario, link de confirmación |
| 5 | Click en link de confirmación | Cuenta activada, redirige al dashboard |
| 6 | Click en link de confirmación otra vez | Muestra “ya confirmado”, no un error |
| 7 | Registrarse con el mismo email | No debe enviar nueva confirmación |
Escenario 2: Email de Restablecimiento de Contraseña
| Paso | Acción | Resultado Esperado |
|---|---|---|
| 1 | Solicitar reset para test@example.com | Email llega en 30 segundos |
| 2 | Verificar link de reset | Contiene token único, usa HTTPS |
| 3 | Click en link de reset | Muestra formulario de reset |
| 4 | Establecer nueva contraseña | Contraseña cambiada, email de confirmación enviado |
| 5 | Click en el mismo link de reset otra vez | Token expirado/usado — muestra error |
| 6 | Solicitar reset para email inexistente | Misma respuesta que email válido (seguridad) |
| 7 | Solicitar múltiples resets | Solo el último token funciona |
Solución: Bugs Comunes en Testing de Email
Bug 1: Link de reset reutilizable El token no se invalidaba después de uso, permitiendo resetear la contraseña múltiples veces. Severidad: Crítica (seguridad).
Bug 2: Enumeración de emails vía reset Diferentes mensajes para emails existentes vs no existentes. Esto permite a atacantes descubrir cuentas válidas. Corrección: Siempre mostrar el mismo mensaje.
Bug 3: Link de confirmación expira muy rápido Token expiraba en 10 minutos, pero algunos proveedores retrasan la entrega 5+ minutos. Corrección: Extender a 24 horas para confirmaciones.
Bug 4: HTML roto en Outlook
Email usaba layout <div> que Outlook no soporta. Corrección: Usar layout <table>.
Bug 5: Link de cancelar suscripción faltante Violación de CAN-SPAM — todos los emails comerciales deben incluir mecanismo de cancelación. Puede resultar en penalidades legales.
Bug 6: Variables de template sin resolver “Hola {{user.firstName}}” en lugar de “Hola Alice”. Corrección: Agregar texto de fallback.
Testing de Push Notifications
Qué Probar
| Aspecto | Verificaciones |
|---|---|
| Permiso | Prompt aparece una vez, respeta elección del usuario |
| Entrega | Llega dentro del tiempo esperado |
| Contenido | Título, cuerpo, ícono son correctos |
| Acción | Click en notificación abre pantalla correcta |
| Agrupación | Múltiples notificaciones se apilan correctamente |
| Modo DND | Notificaciones respetan No Molestar |
| Background | Notificaciones llegan con app en segundo plano |
Puntos Clave
- Nunca uses direcciones de email reales para testing — siempre usa sandboxes como Mailtrap o Mailhog
- Emails transaccionales requieren testing de seguridad (expiración de token, uso único, sin enumeración)
- El renderizado HTML de emails varía dramáticamente entre clientes — prueba en Gmail, Outlook y Apple Mail mínimo
- Push notifications necesitan testing de flujo de permisos, timing de entrega e interacción con modo DND
- Siempre verifica funcionalidad de cancelar suscripción y cumplimiento legal
- Prueba edge cases: datos dinámicos faltantes, emails rebotados, notificaciones encoladas