Lista de pruebas de correo para desarrolladores: de la solicitud a la caducidad
Revisado por Revisión editorial de Once Email
Guía del artículo
Por qué vale la pena leer este artículo
- Análisis original
- Dividimos el recorrido en eventos observables para diferenciar defectos de aplicación, proveedor, transporte, renderizado y limpieza.
- Contexto de tendencias
- El correo transaccional combina más plantillas, localización, enlaces firmados y controles de autenticación, aumentando los puntos de fallo.
- Valor práctico
- El equipo obtiene una lista reutilizable con evidencias mínimas, tiempos UTC y criterios de resultado que reducen pruebas inestables.
En esta página
Una prueba de correo completa no consiste solo en «el mensaje llegó». Debe demostrar que el evento correcto generó un único mensaje, que el destinatario y el contenido son adecuados, que los secretos caducan y que el entorno queda limpio.
1. Define el escenario
Especifica propósito, entorno, tipo de usuario y resultado esperado. Utiliza una cuenta y datos creados para la prueba. Nunca copies listas de clientes ni direcciones reales a un entorno de ensayo.
Registra un identificador de ejecución que no sea secreto y horas UTC para cada paso. Decide cuánto retraso es aceptable antes de considerar el caso fallido.
2. Observa la solicitud
Comprueba que la acción del usuario produjo una única orden de envío. Si administras la aplicación, registra el nombre de plantilla, locale, destinatario enmascarado y un identificador del proveedor. No registres códigos, tokens ni el cuerpo completo.
Ensaya dobles clics y reintentos: la interfaz debe evitar envíos duplicados o explicar el límite. Un error de proveedor debe mostrarse sin afirmar que el correo fue entregado.
3. Comprueba la recepción
Verifica destinatario exacto, remitente visible, asunto y hora. Mide la latencia desde la solicitud hasta la recepción. Distingue «aceptado por el proveedor», «aceptado por el servidor receptor» y «visible en el buzón»; son hitos diferentes.
Confirma que una ejecución solo consume su propio mensaje. Las pruebas paralelas necesitan direcciones o identificadores independientes para no leer el correo de otro caso.
4. Valida texto y HTML
Revisa versión de texto, HTML protegido, jerarquía de títulos, contraste, idioma y enlaces. El contenido importante debe seguir siendo comprensible con imágenes bloqueadas. Los botones necesitan texto descriptivo y un destino coherente.
Prueba asuntos largos, nombres con caracteres internacionales y datos próximos a los límites. Evita incluir información sensible innecesaria en asunto o preencabezado, porque pueden aparecer en notificaciones y registros.
5. Códigos y enlaces
Un código debe aceptar el valor más reciente, caducar en el plazo documentado y no poder reutilizarse después del éxito. Un enlace debe usar HTTPS, un dominio reconocible y un token impredecible; tras caducar debe mostrar una respuesta segura sin revelar estado interno.
Comprueba que solicitar un nuevo secreto invalida los anteriores según el contrato. No guardes el valor real como evidencia. Registra únicamente que estaba presente, su longitud o formato permitido y el resultado de uso.
6. Adjuntos
Si la función envía archivos, prueba tipo, nombre, tamaño, descarga y comportamiento ante contenido no admitido. Utiliza ficheros de prueba inocuos. La respuesta debería forzar descarga, impedir interpretación MIME ambigua y evitar caché cuando el contenido sea sensible.
Incluye casos sin adjuntos, varios adjuntos, nombre Unicode y tamaño justo por debajo y por encima del límite. Nunca utilices malware real para una prueba funcional corriente.
7. Autenticación y cabeceras
Revisa SPF, DKIM y DMARC en el receptor de prueba, teniendo en cuenta proveedores delegados y alineación. Confirma Message-ID, Date y cadena Received razonables. Un pass de autenticación no sustituye las pruebas de contenido y autorización.
8. Accesibilidad y localización
Navega el mensaje y la página de destino con teclado. Comprueba orden de lectura, texto alternativo y zoom. Para cada idioma, revisa formato de fecha, dirección del texto, expansión de botones, tono y terminología; no limites la prueba a que «no falten claves».
9. Casos negativos
Prueba dirección inválida, dominio rechazado, proveedor no disponible, límite de frecuencia, buzón caducado, token alterado y acceso desde otra sesión. La aplicación debe utilizar estados claros y no filtrar si una cuenta sensible existe.
10. Limpieza y evidencia
Elimina cuenta, buzón, archivos y datos creados. Conserva solo identificador de ejecución, versión, horas, resultados y capturas redactadas cuando sean necesarias. La guía de evidencia segura explica cómo evitar que un informe se convierta en una filtración.
Automatiza los pasos deterministas y reserva la revisión visual para cambios de plantilla. Una prueba robusta consulta con intervalos y un plazo total, no con esperas fijas que fallan según la carga.
Guías relacionadas
Por qué Once Email solo recibe correo por diseño
Qué problemas resuelve un buzón temporal, cuándo no conviene utilizarlo y por qué Once Email mantiene un límite estricto de solo recepción.
Cómo guardar evidencias de pruebas de correo sin exponer secretos
Qué conservar, qué ocultar y cómo demostrar un resultado sin archivar códigos, enlaces de acceso o mensajes completos.