Pruebas de aceptación para cambios de proveedor A2P SMS: cómo validar antes del corte
Una guía para acordar pruebas reproducibles de conectividad, respuestas, callbacks y estados antes de migrar tráfico A2P. La aceptación técnica no equivale a confirmar la recepción del SMS en el terminal.
Qué valida una prueba de aceptación y qué queda fuera
Una prueba de aceptación comprueba si una integración y su operación se comportan según los requisitos acordados para un caso concreto. En un cambio de proveedor A2P, puede verificar que el sistema envía solicitudes, interpreta respuestas, procesa callbacks y registra los eventos necesarios.
La aceptación técnica no demuestra por sí sola que el SMS llegó al terminal del destinatario ni garantiza que el rendimiento observado vaya a mantenerse después del corte. Una respuesta HTTP satisfactoria confirma una respuesta de esa interfaz, no la recepción final del mensaje. Del mismo modo, un estado de entrega reportado debe tratarse como información del sistema que lo emitió, no como prueba independiente de recepción en el dispositivo.
- Defina por separado qué valida la interfaz, qué informa el proveedor y qué evidencia existe sobre la entrega.
- Documente los límites de la prueba: entorno, destinos, remitentes, tipos de mensaje, ventana observada y dependencias externas.
Definir el alcance y las responsabilidades
Antes de ejecutar pruebas, acuerde qué se está incorporando o migrando. Especifique la interfaz utilizada —HTTP o SMPP—, los destinos y remitentes incluidos, los tipos de mensajes permitidos y qué sistema es responsable de cada etapa. Para SMPP, la especificación SMPP v3.4 puede servir como referencia técnica al acordar parámetros y respuestas; los detalles concretos deben contrastarse con la versión y el perfil de integración pactados.
No dé por hecho que todos los proveedores interpretan igual cada campo, estado o comportamiento operativo. Prepare una matriz de requisitos que indique, para cada caso, la solicitud esperada, la respuesta que se debe registrar, quién la produce y cómo se considera aprobado o fallido. Los criterios y las condiciones para detener o revertir el cambio son decisiones del proyecto, no umbrales universales.
- Anote interfaz, versión o perfil aplicable y configuración que se está probando.
- Delimite destinos, remitentes y categorías de tráfico incluidas; deje explícitas las exclusiones.
- Asigne responsables para cliente, proveedor y cualquier sistema intermedio.
- Acuerde de antemano los criterios de aprobación, las incidencias bloqueantes y las condiciones de pausa o reversión.
Preparar el entorno y los datos de prueba
Use un entorno y tráfico de prueba autorizados, con alcance acordado por las partes. Cuando no sea posible separar totalmente la infraestructura de producción, documente qué componentes se comparten y cómo se limita el impacto. No envíe mensajes a números o personas sin autorización.
Incluya únicamente los datos necesarios para ejecutar y diagnosticar cada caso. Defina quién puede consultar los registros, cómo se protegen y durante cuánto tiempo se conservan según las políticas y obligaciones aplicables. Las fuentes técnicas generales no fijan un procedimiento universal de aislamiento, consentimiento o retención: esos aspectos deben confirmarse con las reglas vigentes y los responsables pertinentes.
- Confirme autorización, destinos de prueba y remitentes antes de enviar tráfico.
- Use identificadores de prueba distinguibles de los de producción, si la integración lo permite.
- Evite incluir datos personales innecesarios en contenido, registros o capturas.
- Verifique que el equipo sabe cómo detener la ejecución si el tráfico sale del alcance acordado.
Construir casos positivos y negativos
Una prueba útil no se limita a enviar un mensaje válido. Debe comprobar también cómo se comporta la integración cuando recibe entradas incorrectas, respuestas inesperadas o interrupciones. La semántica de HTTP está definida por RFC 9110, pero el significado de una respuesta para el flujo SMS depende además del contrato y del diseño de la integración.
Para cada caso, registre el resultado esperado y la evidencia que permitirá compararlo. No invente códigos de error ni suponga que un comportamiento es común a todos los proveedores: confirme los valores y reglas aplicables en la documentación técnica acordada.
- Caso válido: campos requeridos presentes y valores dentro del formato acordado.
- Caso inválido: omisión de un campo requerido o formato no aceptado, según el contrato de interfaz.
- Rechazo: solicitud que el proveedor no acepta; verifique que el cliente conserva y clasifica la respuesta correctamente.
- Timeout o interrupción: compruebe cómo se registra la incertidumbre y qué acción posterior está autorizada; evite reintentos automáticos que puedan duplicar mensajes sin una regla acordada.
- Límite de tráfico: ensaye únicamente el volumen y las condiciones autorizadas, con límites definidos por el proyecto.
Verificar identificadores, callbacks y trazabilidad
Compruebe que cada envío se puede relacionar con su respuesta y con los eventos posteriores que formen parte de la integración. Acuerde qué identificador devuelve o genera cada sistema, en qué punto se registra y cómo se vincula con los callbacks. No asuma que los identificadores tienen el mismo formato ni que su ámbito es idéntico entre plataformas.
Pruebe también los callbacks que realmente estén configurados: recepción, autenticidad según el mecanismo acordado, tratamiento de duplicados y registro de fallos de procesamiento. Los comportamientos esperados deben quedar definidos por las especificaciones y el acuerdo de integración; no hay una regla universal que se pueda inferir solo del nombre del evento.
- Correlacione solicitud, respuesta y callback mediante los identificadores disponibles y documentados.
- Registre fecha y hora, entorno, destino de prueba, resultado y versión de configuración necesaria para reproducir el caso.
- Compruebe que un callback no se atribuye a otro envío y que los eventos repetidos se manejan según la regla acordada.
- Guarde evidencia técnica con acceso y retención adecuados, evitando exponer secretos o datos innecesarios.
Interpretar estados y DLR con cautela
Incluya en la matriz los estados que la integración y el proveedor hayan acordado, pero no trate las etiquetas como universales. Documente quién origina cada estado, qué significa en ese sistema y qué incertidumbres conserva. Si un evento no llega, llega tarde o no coincide con el resultado esperado, registre el hecho como una discrepancia para investigar, no como una conclusión automática sobre el terminal.
Un DLR o estado comunicado por un proveedor no equivale necesariamente a una verificación independiente de que el destinatario recibió el mensaje en su dispositivo. La prueba debe separar la consistencia del informe de estado de cualquier evidencia adicional de recepción, si esta existe y es accesible.
- Compare los estados observados con la definición documentada para esa integración.
- Registre eventos ausentes, tardíos, repetidos o difíciles de correlacionar.
- No convierta un estado reportado en garantía de recepción en el terminal.
Medir disponibilidad y latencia sin extrapolar
Si se van a evaluar disponibilidad, latencia o consistencia, acuerde la ventana de observación, los puntos de medición, la población de pruebas y la forma de calcular cada métrica. Separe el tiempo de respuesta de la interfaz de los tiempos de estados posteriores: miden etapas distintas.
No hay cifras universales de latencia, disponibilidad, tamaño de muestra o límite de tráfico que sirvan como criterio de aceptación para todos los proyectos. Una muestra pequeña y limitada a ciertos destinos tampoco permite generalizar el rendimiento futuro. Defina umbrales con las partes según el uso previsto y el acuerdo aplicable, y describa qué queda fuera de la medición.
- Indique el punto inicial y final de cada medición.
- Registre la ventana, el número y el alcance de las pruebas, sin presentar la muestra como representativa si no lo es.
- Distinga resultados por interfaz, destino y tipo de evento cuando el conjunto de datos lo permita.
- Compare únicamente contra criterios aprobados antes de observar los resultados.
Cerrar la aceptación con evidencias y una decisión reproducible
Consolide los resultados en un registro que otra persona pueda revisar y repetir. Para cada caso, incluya configuración relevante, datos de prueba no sensibles, resultado esperado, resultado observado, referencia de evidencia, responsable e incidencia asociada. Mantenga separadas las observaciones de las interpretaciones.
La decisión final debe indicar qué se aprobó, qué queda condicionado y quién la autorizó. Si una prueba falla o no puede ejecutarse, documente la limitación y acuerde el siguiente paso antes del corte. Fije explícitamente el procedimiento de pausa o reversión con los responsables; no existe una condición técnica universal que sustituya esa decisión.
- Conserve la matriz de casos y el registro de resultados en una ubicación controlada.
- Clasifique incidencias por impacto acordado y asigne responsable y fecha de seguimiento.
- Documente límites de cobertura de la prueba y dependencias no verificadas.
- Registre la aprobación, las condiciones pendientes y el procedimiento acordado para detener o revertir.
Preguntas frecuentes
¿Una respuesta HTTP satisfactoria confirma que se entregó el SMS?
No. Confirma una respuesta satisfactoria de la interfaz según la semántica HTTP aplicable. Por sí sola no demuestra que el mensaje haya llegado al terminal.
¿Un DLR confirma que el destinatario recibió el mensaje en su dispositivo?
No debe asumirse así. Un DLR es un estado reportado por el sistema que lo emite; no equivale necesariamente a una verificación independiente de recepción en el terminal.
¿Qué umbrales de latencia o disponibilidad debo usar para aprobar al proveedor?
No hay cifras universales adecuadas para todos los casos. Defina con las partes la ventana, los puntos de medición, el alcance y los umbrales según el uso previsto y el acuerdo aplicable.
¿Qué debo probar antes del corte?
Como mínimo, acuerde casos para entradas válidas e inválidas, respuestas, timeouts, límites autorizados, correlación de identificadores, callbacks y estados que formen parte de la integración. Añada criterios de aprobación y condiciones de pausa o reversión.
¿Las pruebas de aceptación garantizan el rendimiento después de la migración?
No. Describen el comportamiento observado en un entorno, alcance y ventana determinados. No garantizan resultados futuros ni permiten generalizar más allá de la evidencia obtenida.
Fuentes consultadas
- SMPP Protocol Specification v3.4SMPP Developers Forum
- HTTP Semantics (RFC 9110)IETF
- 3GPP specifications by series3GPP
- E.164: The international public telecommunication numbering planInternational Telecommunication Union
- GSMA networks resourcesGSMA