Casi todas las aplicaciones piden una dirección de correo y una cantidad sorprendente de funciones críticas depende de ella. Registro, verificación, restablecimiento de contraseña, enlaces mágicos, invitaciones, preferencias de notificación y recuperación dependen de mensajes que llegan realmente a un buzón. No puedes comprobarlo solo mirando el código. Hay que enviar un correo real a una cuenta real y revisar qué llega.
Ahí aparece un problema práctico para los equipos de QA. Probar estos flujos correctamente consume direcciones con rapidez porque muchas solo pueden usarse una vez. Intentar trabajar con el Gmail personal de un probador falla en cuanto el registro rechaza una dirección duplicada. Esta guía explica cómo preparar cuentas para probar de verdad la verificación, la autenticación y los escenarios con varios usuarios.
Por qué los buzones reales superan a las direcciones ficticias
Resulta tentador escribir test@test.com y continuar. El problema es que las direcciones ficticias solo prueban el camino ideal hasta el envío del correo. No indican si el enlace funciona, si el token de restablecimiento caduca correctamente ni cómo se muestra el mensaje en un cliente real. Esos son precisamente los puntos que fallan en producción y generan incidencias.
Con buzones reales puedes abrir el enlace, confirmar el restablecimiento de principio a fin, comprobar el nombre del remitente y el asunto y comparar la visualización en Gmail y Outlook. Así conviertes una prueba superficial en una prueba real. Para una función dirigida al usuario, esa diferencia es la esencia del QA.
Dónde resultan útiles las cuentas de prueba dedicadas
- Flujos de registro e incorporación que exigen una dirección única y verificable en cada ejecución
- Restablecimiento de contraseña y acceso por enlace mágico, donde debes recibir y usar el correo
- Funciones de invitación y colaboración que representan varios usuarios distintos
- Ajustes de notificaciones y resúmenes, donde compruebas la entrega real
- Suites de regresión que necesitan cuentas nuevas cada sprint para evitar que influya el estado anterior
- Comprobaciones entre proveedores para confirmar llegada y renderizado en Gmail, Yahoo y Outlook
Cuentas de prueba desechables o persistentes
No todas las pruebas necesitan el mismo tipo de cuenta. Algunas son desechables: crea una cuenta, ejecuta el flujo una vez y retírala. Otras se benefician de persistencia, como una cuenta que conservas para repetir un escenario de varios pasos con estado conocido. Definir cuál necesitas evita que el grupo se vuelva caótico.
| Tipo de cuenta | Úsala para | Duración |
|---|---|---|
| Desechable | Registros y verificaciones de una sola vez | Una ejecución |
| Persistente | Escenarios de regresión con estado conocido | Semanas o meses |
| Grupo compartido | Pruebas exploratorias manuales | Rotado por sprint |
| Por probador | Trabajo paralelo sin colisiones | Mientras el probador la necesite |
Rota las cuentas en cada sprint
La filtración de estado entre ejecuciones causa resultados inestables y falsa confianza. Una solución sencilla es crear un lote nuevo al comenzar cada sprint y retirar el anterior, para que cada ciclo empiece limpio.
Integración de cuentas de prueba en pipelines automatizados
El QA manual es solo parte del trabajo. Si tu suite de extremo a extremo se ejecuta en cada despliegue, necesita cuentas sin intervención humana. El patrón ordenado es aprovisionar un grupo con antelación, aportar sus credenciales al entorno como configuración y permitir que la suite elija una cuenta. Cuando falten, repón el grupo en lote en lugar de generar cuentas durante la ejecución.
Los equipos con un plan que incluye acceso a la API pueden integrar el aprovisionamiento en sus herramientas, convirtiendo la renovación del grupo en un paso programado. El objetivo es el mismo: las pruebas no esperan la creación ni chocan por una dirección compartida.
Configuración de un grupo de cuentas de prueba
- 1Calcula cuántas cuentas consume un ciclo completo y añade margen
- 2Crea el lote con MailCreator usando un patrón como qa-sprint12-001
- 3Configura un correo de recuperación compartido para recuperar cuentas bloqueadas
- 4Exporta el CSV, comprueba el estado de cada fila e importa las credenciales en un gestor de secretos aprobado
- 5Asigna funciones desechables o persistentes para evitar colisiones entre ejecuciones
- 6Renueva el grupo cada sprint y retira las cuentas antiguas
Mantén los datos de prueba fuera de hojas compartidas
Las cuentas de prueba siguen siendo credenciales reales. Guardarlas en una hoja de Google abierta crea un fallo de seguridad. Usa un gestor de contraseñas o el almacén de secretos de CI, igual que con cualquier otra credencial.