Los programas de referidos están entre los flujos más densos en email que lanzan los productos: un compartir genera un código, un referido recibe un correo, un registro crea la atribución y, finalmente, dos personas reciben correos de recompensa. Cada paso es una superficie de fallo distinta, y el flujo es inherentemente multi-bandeja — una prueba completa necesita al menos un referidor y un referido. Ahí es exactamente donde brillan las bandejas desechables: direcciones nuevas por ejecución, extracción de códigos programática, y ninguna bandeja personal de tus colegas llenándose de invitaciones de prueba.
Anatomía de un flujo de referidos que merece pruebas
Antes de automatizar nada, escribe los eventos que emite tu producto y lo que cada uno debe contener:
- Generación de código: único por referidor, a veces por canal, con restricciones de formato como longitud, juego de caracteres y sensibilidad a mayúsculas.
- Correo de compartir: contiene el código, un enlace personalizado con un identificador de clic, o ambos.
- Registro con el código aplicado: el referido pulsa el enlace o introduce el código a mano — dos rutas de código distintas.
- Atribución: el backend registra el referido bajo su referidor, normalmente con una ventana de atribución y reglas para conflictos.
- Correos de recompensa: típicamente dos, uno por parte, enviados cuando el referido completa una acción cualificadora — no al registrarse.
La mayoría de los bugs de referidos viven en las costuras: el código del correo no coincide con el generado, el identificador del enlace se pierde en una redirección, las recompensas se disparan al registrarse en vez de al calificar, o las dos plantillas de recompensa se intercambian.
El flujo de prueba multi-bandeja
1. Provisiona la bandeja A y registra al referidor. [Crea una bandeja temporal](/), o provisiona cuentas por API como se describe en correo temporal para cuentas de prueba QA. 2. Dispara el compartir. Usa la ruta de invitar-por-email con la dirección de la bandeja B como destinataria. Comprueba que llega el correo de compartir y extrae el código y el enlace — el analizador de OTP saca códigos de los cuerpos de mensaje sin regex por plantilla. 3. Provisiona la bandeja B como bandeja genuinamente separada. La detección de auto-referido es una de las cosas bajo prueba; asegúrate de que tu prueba la captura deliberadamente, nunca por accidente de aliasing. 4. Completa el registro del referido a través del enlace del correo. El enlace es el portador de la atribución; teclear el código a mano ejercita una ruta distinta. Verifica la atribución en el lado del servidor — en la base de datos o en una API de administración — no solo en una insignia de la interfaz. 5. Verifica los correos de recompensa para ambas partes. Tras la acción cualificadora, la bandeja A y la bandeja B deben recibir cada una su propio correo de recompensa. Revisa nombres, importes y enlaces por separado; las plantillas intercambiadas son un bug clásico. 6. Ejecuta las rutas negativas: código caducado, código reutilizado más allá de su tope, auto-referido, referido que ya es cliente, expiración de la ventana de atribución. Cada una debe producir un mensaje claro, no silencio. 7. Repite una vez con un código introducido a mano para cubrir la ruta sin enlace.
Los pasos uno a cinco se scriptan con limpieza para el CI, y el probador de API es la forma rápida de prototipar la coreografía de dos bandejas antes de que se convierta en suite.
Atribución de enlaces: donde los referidos se rompen en silencio
El enlace del correo es la parte frágil:
- Las cadenas de redirección — del correo al dominio de seguimiento y de ahí a la app — pueden perder parámetros de consulta en cualquier salto. Captura la URL final de aterrizaje en tu prueba y comprueba que el identificador de clic sobrevivió.
- Primer clic contra último clic: cuando un referido pulsa dos enlaces de referido distintos, tu regla de conflicto decide quién recibe el crédito. Prueba explícitamente el caso del doble clic; casi nadie lo hace.
- Realidad multidispositivo: clic en el móvil, registro en el portátil. Muchos programas pierden la atribución aquí por diseño; verifica que el comportamiento documentado coincide con la implementación.
- Normalización de códigos: mayúsculas, espacios en blanco y la confusión entre cero y la letra O. Un código que funciona pegado pero no tecleado es una máquina de generar tickets de soporte.
Trampas de disparo antifraude
Los programas de referidos están patrullados agresivamente contra el fraude, y un bucle de pruebas puede parecerse exactamente a un abuso:
- Ráfagas desde una misma IP: docenas de registros desde un runner de CI en minutos se parecen a una granja de fraude. Aísla el tráfico de prueba en staging, o consigue que las cuentas y los rangos IP de prueba se añadan a la lista de permitidos.
- Blocklists de dominios desechables: los flujos de referidos suelen bloquear dominios desechables precisamente por el abuso de referidos. Tu herramienta de pruebas puede ser bloqueada por la propia funcionalidad que pruebas — espéralo, y léelo como un dato sobre el comportamiento de tu blocklist, no como un misterio.
- Reglas de velocidad: bucles rápidos de generar-compartir-registrar por cuenta disparan las comprobaciones de velocidad. Espacia las ejecuciones automatizadas, o marca las cuentas como tráfico de prueba donde el sistema lo permita.
- Topes de recompensa: un tope por referidor puede dejar de recompensar en silencio tras un número fijo de referidos, lo que parece que los correos dejaron de enviarse. Revisa los contadores antes de culpar a la canalización de correo.
El modo de fallo a evitar: la suite queda marcada en la sombra, los referidos dejan de funcionar para sus cuentas, y empiezas a reportar bugs de correo que en realidad son veredictos del sistema antifraude.
Preguntas frecuentes
¿Cuántas bandejas necesita una prueba de referidos? Dos como mínimo: referidor y referido. Añade una tercera al probar conflictos de atribución — dos referidores compitiendo por un referido — y usa pares nuevos en cada ejecución para que el estado previo no filtre entre pruebas.
¿Cómo extraigo códigos de referido automáticamente? Recupera el mensaje más reciente de cada bandeja y parsea el código del cuerpo con un analizador dedicado. Hacer aserciones sobre la presencia y el formato del código es mucho más estable que hacerlas sobre el texto circundante, que cambia constantemente.
¿Deben las pruebas de referidos correr en el CI en cada commit? El camino feliz, sí — es barato con bandejas provisionadas por API. Mantén los escenarios adyacentes al fraude, como velocidad y topes, tras un flag o en un entorno nocturno donde el tráfico deliberadamente raro sea seguro.
¿Cómo distingo un bug de correo de un veredicto antifraude? Rastrea el envío primero en el lado del servidor. Si tu sistema nunca encoló el correo, la causa suele ser una regla — un tope, una blocklist, una comprobación de velocidad — y no la canalización de correo. Los logs en el punto de decisión ganan siempre a las conjeturas desde la bandeja.
En resumen
Los flujos de referidos multiplican las superficies de prueba de email: dos partes, varios mensajes, enlaces que transportan la atribución y sistemas antifraude observándolo todo. Las bandejas desechables hacen trivial el montaje multiparte — pares nuevos por ejecución, códigos parseados programáticamente, atribución verificada en el servidor. Prueba las rutas negativas con el mismo rigor que el camino feliz; en los sistemas de referidos, los caminos infelices es por donde se fuga el dinero.