Cambios de integración HTTP y SMPP para A2P SMS: cómo validar compatibilidad antes de desplegar

Qué cambios justifican una regresión y qué queda fuera de su alcance

Una regresión de integración comprueba que un cambio no haya alterado el contrato técnico entre una aplicación y su interfaz SMS. Conviene ejecutarla al modificar la aplicación cliente, el conector, la configuración de transporte o la forma en que se interpretan respuestas y estados. HTTP y SMPP son interfaces distintas: una prueba satisfactoria en una no valida automáticamente la otra.

El alcance debe quedar explícito. Una respuesta HTTP satisfactoria confirma el resultado de la solicitud según la semántica HTTP, no la entrega del SMS al dispositivo. Del mismo modo, establecer una sesión SMPP o recibir una respuesta a una operación de envío no demuestra por sí mismo que el destinatario haya recibido el mensaje. La entrega y el significado de los estados posteriores dependen de la evidencia disponible y de la documentación aplicable.

• Incluye: compatibilidad de solicitudes, campos, codificación acordada, interpretación de respuestas, correlación de identificadores y tratamiento de desconexiones.
• Trata por separado: aceptación técnica, progreso posterior del mensaje y recepción comprobada en un terminal.
• No uses una prueba de integración como sustituto de una evaluación de ruta, cobertura o calidad de entrega.

Contrato técnico: campos, codificación, remitente, referencias y semántica

Antes de escribir pruebas, convierte la documentación vigente de la API o del proveedor SMPP en un contrato verificable. La documentación genérica no permite asumir qué campos son obligatorios, cómo se expresa el remitente, qué codificación se admite, qué formato tiene un identificador ni qué estados se devuelven. Registra cada regla con su fuente y confirma cualquier punto ambiguo con la especificación o el proveedor correspondiente.

Para cada campo, anota si es obligatorio u opcional, su formato, límites documentados, valor por defecto si existe y conducta esperada cuando falta o no es válido. Para la codificación, define los casos de texto permitidos por el contrato y cómo comprobarás que el contenido recibido por la interfaz conserva el significado esperado. No presupongas que dos conectores interpretan igual caracteres, remitentes o referencias.

Define también la semántica de las respuestas: qué significa aceptación o rechazo en esa interfaz, qué identificador se devuelve y cómo se correlaciona con el estado posterior. En SMPP, utiliza la especificación de la versión acordada y la implementación contratada para interpretar operaciones, respuestas, campos y estados; no infieras detalles de una integración a partir de documentación de otra.

• Mantén una tabla por interfaz con campo, regla documentada, validación y resultado esperado.
• Separa el identificador de solicitud del identificador de mensaje si el contrato los distingue; documenta su alcance y uso.
• Guarda ejemplos representativos y seguros, sin datos personales reales ni credenciales, para repetir las pruebas.

Casos de prueba HTTP y SMPP: aceptación, rechazo y recuperación

Construye una batería por interfaz. Para HTTP, verifica solicitudes válidas y entradas que el contrato defina como inválidas; comprueba que la aplicación interpreta correctamente la respuesta y conserva la correlación necesaria. Los códigos de estado HTTP describen el resultado de la interacción HTTP conforme a RFC 9110, pero su significado para el envío SMS debe obtenerse del contrato de la API.

Para SMPP, prueba por separado la conexión y las operaciones de envío definidas para la versión y el proveedor utilizados. Comprueba la respuesta de protocolo y el tratamiento de rechazos documentados. La especificación SMPP v3.4 proporciona la referencia para las operaciones y respuestas de esa versión, pero los detalles concretos que debes esperar dependen del contrato aplicable.

Añade escenarios de timeout, desconexión y recuperación, pero no fijes una conducta universal. Define primero qué establece el contrato sobre reintentos, solicitudes cuyo resultado no se conoce y reconexión. Si no hay una regla documentada, registra el caso como decisión pendiente en lugar de convertir una suposición en criterio de aprobación.

• Prueba aceptación técnica con datos de prueba autorizados y un destino controlado.
• Incluye rechazos esperados y confirma que el sistema no los registra como aceptación.
• Simula timeout y desconexión en un entorno controlado; verifica la conducta acordada y conserva la evidencia.
• No reenvíes automáticamente un mensaje cuyo resultado sea incierto salvo que el contrato y el diseño de la aplicación definan cómo evitar consecuencias no deseadas.

Callbacks y estados correlacionados: qué demuestra un DLR

Si la integración utiliza callbacks o notificaciones de estado, prueba el recorrido completo entre la aceptación inicial y el evento posterior que el contrato defina. Verifica que la notificación pueda asociarse al envío correcto mediante los identificadores documentados y que la aplicación distinga entre ausencia de evento, evento recibido y estado final informado.

No presupongas que un callback tiene los mismos campos, orden o semántica en todos los proveedores. Contrasta formato, autenticidad, repetición y tratamiento de eventos tardíos con la documentación de la integración. Si algún aspecto no está especificado, delimítalo como incertidumbre y acuerda cómo se observará operativamente.

Un DLR informa un estado dentro del sistema que lo emite y transmite; por sí solo no equivale necesariamente a una comprobación independiente de recepción en el móvil. En la evidencia de la regresión, etiqueta claramente qué observaste: respuesta de API, respuesta SMPP, callback o verificación independiente de terminal, si esta última existe.

• Comprueba que cada evento se correlacione con la referencia correcta según el contrato.
• Registra el origen y el momento de observación de cada estado.
• Separa los estados reportados por la ruta de la recepción verificada de forma independiente.

Comparar antes y después con criterios y evidencias

Ejecuta el mismo conjunto de casos contra la versión anterior y la nueva, en condiciones comparables. Compara resultados por interfaz y escenario, no solo el porcentaje global de pruebas superadas. Una diferencia puede ser esperable si el contrato cambió de forma deliberada; debe estar documentada, aprobada y reflejada en las pruebas antes del despliegue.

Conserva la versión de la aplicación y del conector, la configuración no secreta relevante, el caso ejecutado, la respuesta observada y el resultado esperado. Almacena los datos sensibles de acuerdo con las políticas aplicables y evita incluir credenciales o información personal innecesaria en registros compartidos.

Define los criterios de aprobación antes de ejecutar. Como mínimo, los casos obligatorios del contrato deben producir el resultado esperado y las diferencias no explicadas deben investigarse. No establezcas umbrales de latencia, disponibilidad o entrega sin una especificación aplicable y una medición adecuada.

• Clasifica cada diferencia como cambio previsto, regresión confirmada o resultado todavía no explicado.
• Compara códigos y cuerpos HTTP según la API; compara respuestas SMPP según la versión y la implementación acordadas.
• Adjunta evidencias suficientes para repetir el caso sin exponer secretos.

Despliegue gradual y reversión sin mezclar pruebas con producción

Prueba primero en un entorno y con destinos autorizados para ensayo, siempre que estén disponibles y documentados. Mantén separadas las credenciales, la configuración y las evidencias de prueba de las de producción. Si no existe un entorno de prueba adecuado, limita cualquier validación a lo aprobado para producción y a las reglas de consentimiento y cumplimiento aplicables.

Antes de desplegar, acuerda quién decide continuar o detener el cambio, qué casos deben aprobarse y qué señales obligan a investigar o revertir. La reversión debe corresponder a un procedimiento probado para la aplicación y el conector; no hay una regla universal de infraestructura que pueda fijarse sin conocer el sistema.

Durante cualquier despliegue gradual, identifica con claridad qué versión genera cada solicitud y conserva observabilidad suficiente para distinguir errores de integración de resultados posteriores de entrega. No interpretes una respuesta técnica satisfactoria como prueba de calidad de ruta.

• Asegura que existe una versión o configuración anterior recuperable y que el procedimiento de reversión está validado.
• Define responsables, criterios de parada y evidencia mínima antes de iniciar el cambio.
• Mantén el tráfico de prueba identificado y separado del tráfico productivo.

Lista de verificación para mantener compatibilidad

Una integración se mantiene compatible cuando sus reglas se pueden consultar, sus pruebas se pueden repetir y los cambios intencionados se distinguen de las regresiones. Revisa el contrato cuando cambie una versión de API, una especificación SMPP, un conector o la configuración que afecte a campos, respuestas o estados. La referencia siempre debe ser la documentación vigente de la interfaz concreta.

Usa esta lista antes de aprobar un cambio:

• ¿Está documentada la versión y la interfaz HTTP o SMPP bajo prueba?
• ¿Cada campo, codificación, remitente e identificador tiene una regla respaldada por documentación?
• ¿Hay casos separados para aceptación, rechazo, timeout, desconexión y recuperación?
• ¿Los callbacks y estados se correlacionan según el contrato y se identifica quién los informa?
• ¿La evidencia distingue aceptación técnica, DLR y recepción verificada en el terminal?
• ¿Las diferencias respecto a la versión anterior están explicadas y aprobadas?
• ¿Están definidos responsables, criterios de parada y procedimiento de reversión?
• ¿Las pruebas y el tráfico productivo están separados y cumplen las reglas aplicables?