Pruebas de aceptación A2P SMS: valida la integración antes de producción

Qué valida una prueba de aceptación y qué queda fuera

Una prueba de aceptación permite comprobar que la integración intercambia solicitudes y respuestas como se acordó: establece una conexión, autentica, acepta o rechaza envíos de forma interpretable y procesa los eventos posteriores previstos. Su resultado se limita a los casos, destinos, remitentes, contenido y entorno que se probaron.

No equivale a una garantía de entrega futura ni demuestra el comportamiento en otros operadores, destinos o condiciones. En SMPP, la respuesta a submit_sm informa del resultado de la solicitud; la entrega puede ocurrir después. Conviene registrar por separado la aceptación técnica, el estado posterior del mensaje y cualquier confirmación disponible.

• Defina qué componentes y comportamientos entran en la aceptación: conectividad, autenticación, formato, respuestas, correlación y callbacks.
• Anote qué aspectos quedan fuera, como la entrega en destinos no probados o el rendimiento bajo cargas distintas de las ensayadas.
• Acuerde qué significa «aprobado» para cada caso antes de empezar.

Defina el alcance antes de enviar mensajes

Prepare un plan compartido por ingeniería, operaciones y las partes responsables de la conexión. Especifique el entorno de prueba, los destinos autorizados, los remitentes y los contenidos aprobados, además de quién ejecuta cada caso y quién interpreta el resultado. Use únicamente números y mensajes cuyo uso esté autorizado y cumpla las reglas aplicables.

Documente también las condiciones técnicas esperadas: protocolo, parámetros admitidos, formato de direcciones, codificación, límites acordados y mecanismo de recepción de respuestas o eventos. La estructura de numeración internacional debe tratarse de manera coherente con el alcance definido; no dé por supuesto que cualquier cadena con apariencia de número será válida para la ruta.

• Fije entorno, ventana de prueba, destinos y remitentes permitidos.
• Apruebe el contenido y confirme que los mensajes son legítimos y están autorizados.
• Asigne responsables de envío, monitorización, análisis de errores y decisión de aprobación.
• Registre versiones de configuración y parámetros relevantes para poder reproducir el caso.

Compruebe conectividad, autenticación, formato y respuestas

En HTTP, compruebe que la solicitud llega al endpoint previsto y que el cliente interpreta tanto el código de estado como el cuerpo de respuesta. Las clases HTTP describen el resultado de la solicitud HTTP: un 2xx, por sí solo, no demuestra que el SMS haya llegado al terminal. Verifique además el formato de la respuesta y cómo se representa una aceptación o un rechazo según el contrato técnico.

En SMPP, valide establecimiento de sesión y bind, intercambio de PDU, respuestas y mantenimiento de la conexión. enquire_link permite comprobar la comunicación a nivel de aplicación. La respuesta submit_sm_resp incluye el resultado de la solicitud y, cuando corresponde, un identificador del mensaje del SMSC; no la confunda con un informe posterior de entrega.

Pruebe los formatos que utilizará la integración: dirección de destino, dirección de origen, codificación y longitud del mensaje. El SMSC puede rechazar o truncar contenido que exceda lo permitido por la red o la implementación. Compruebe también que los rechazos se registran y clasifican; en SMPP, command_status comunica el resultado de la solicitud.

• Pruebe credenciales válidas y, en un entorno controlado, el tratamiento de autenticación inválida.
• Compruebe formato correcto e incorrecto de direcciones, codificación y longitudes dentro del alcance acordado.
• Verifique respuestas de aceptación y rechazo sin interpretarlas como prueba de entrega.
• En SMPP, valide el bind, las respuestas asociadas y el mantenimiento de sesión, incluidos los temporizadores configurados.

Verifique correlación y tratamiento de callbacks

Cada envío y cada evento posterior deben poder asociarse de forma inequívoca dentro de la aplicación. En SMPP, sequence_number relaciona una respuesta con su solicitud y debe conservarse en la respuesta; además, las respuestas pueden llegar fuera de orden. No base la correlación únicamente en el orden de llegada.

Defina cómo se procesan callbacks o recibos duplicados, tardíos y desordenados. La deduplicación es una decisión de implementación: no debe suponerse que el protocolo garantiza una entrega única del evento. Registre identificadores, estado recibido, marca temporal disponible y resultado del procesamiento, evitando que un evento repetido genere efectos secundarios no deseados.

• Pruebe respuestas que lleguen fuera de orden y confirme que se asocian al envío correcto.
• Envíe o simule eventos repetidos y compruebe la política de deduplicación acordada.
• Valide el tratamiento de callbacks tardíos, ausentes o con identificadores que no puedan correlacionarse.
• Conserve trazas suficientes para reconstruir la secuencia sin exponer credenciales.

Diseñe casos controlados para éxitos, rechazos y estados inciertos

Un plan útil no se limita al caso feliz. Incluya una solicitud aceptada, una solicitud rechazada por un parámetro controlado, una respuesta tardía o timeout y los distintos resultados de entrega que la conexión permita observar. Para cada caso, anote la entrada, el resultado esperado, el resultado real y la evidencia.

Trate un timeout de envío HTTP como incierto: la solicitud podría haberse procesado aunque el cliente no haya recibido respuesta. No reintente a ciegas una operación no idempotente salvo que exista un mecanismo acordado para determinar si se aplicó o para evitar duplicados. Un timeout no demuestra por sí mismo que el proveedor rechazó el mensaje.

En SMPP, distinga un error de sumisión comunicado en la respuesta de un fallo de entrega posterior. Registre ambos como resultados diferentes y compruebe cómo los representa la aplicación.

• Caso aceptado: comprobar respuesta, identificador y registro del envío.
• Caso rechazado: verificar clasificación del error y ausencia de una falsa confirmación de entrega.
• Caso con timeout: marcar el resultado como incierto y seguir el procedimiento acordado antes de reintentar.
• Caso con callback ausente, tardío o duplicado: comprobar alarmas, conciliación y tratamiento operativo.
• Caso con mensaje aún en ruta: evitar clasificarlo prematuramente como entregado o fallido.

Separe aceptación técnica de observación de entrega

Si necesita observar el resultado de entrega en SMPP, compruebe que se solicita el SMSC Delivery Receipt cuando corresponda y que la integración puede recibir el evento previsto, por ejemplo mediante deliver_sm o data_sm según la implementación. La respuesta inmediata al envío y el recibo posterior son etapas distintas.

Interprete cada DLR según quién lo emite y qué indica. La especificación 3GPP distingue los informes del Service Centre, que confirman recepción por ese centro y no por el equipo terminal, de los informes emitidos por la Mobile Station, que confirman recepción por la estación móvil, no que una persona haya visto o leído el mensaje. Un estado como ENROUTE indica que sigue en tránsito; no es ni una confirmación final de entrega ni, por sí mismo, un fallo.

La observación de unos pocos mensajes controlados solo describe esos casos en el entorno y momento de la prueba. No garantiza resultados futuros ni permite extrapolar automáticamente a otros destinos, operadores o condiciones.

• Separe el resultado HTTP o SMPP de la solicitud del estado de entrega posterior.
• Documente la fuente y el alcance de los DLR recibidos.
• No presente un DLR como prueba de lectura o recepción humana.
• Defina cómo se contabilizan los estados no finales y los recibos que no llegan durante la ventana observada.

Fije criterios de aprobación y evidencia

Los criterios deben ser observables y acordados antes de ejecutar las pruebas. Separe los requisitos de conectividad y procesamiento de solicitudes de los requisitos de observación de entrega. Para cada uno, indique qué respuesta o evento cuenta como aprobado, qué errores bloquean la habilitación y qué resultados permanecen pendientes de análisis.

Conserve el plan, la configuración relevante, las solicitudes y respuestas, los identificadores, los eventos recibidos y el resultado de cada caso. La evidencia debe permitir reconstruir qué se probó y qué no, sin convertir una muestra controlada en una afirmación general de rendimiento.

• Aprobación técnica: sesión o endpoint operativo, autenticación y formatos conformes, respuestas interpretadas y correlación correcta.
• Aprobación operativa: rechazos, timeouts, duplicados y eventos tardíos tratados según el procedimiento acordado.
• Observación de entrega: alcance, estados, fuente del DLR y ventana de espera documentados por separado.
• Decisión final: registrar aprobados, pendientes, excepciones aceptadas y responsables que autorizan avanzar.

Habilite producción gradualmente y con capacidad de reversión

Tras la aceptación, habilite el tráfico de forma gradual con límites y una ventana de observación definidos para ese servicio. No existe un umbral universal de volumen o una secuencia de promoción fijada por los estándares: acuerde los límites, señales de alerta y responsables según el riesgo y la operación.

Antes del primer tráfico, determine quién puede detener o revertir la habilitación, qué condiciones activan esa decisión y cómo se gestionan los mensajes cuyo resultado sea incierto. Monitorice conectividad, respuestas, rechazos, callbacks y estados de entrega por separado. La aprobación de una prueba controlada autoriza el alcance acordado, no garantiza el comportamiento bajo cualquier condición futura.

• Defina límites iniciales y señales de alerta antes de activar tráfico.
• Asigne responsables de monitorización y autoridad para detener o revertir.
• Establezca cómo investigar timeouts y evitar reintentos que puedan duplicar mensajes.
• Amplíe el alcance solo tras revisar la evidencia y resolver los bloqueos acordados.