Volver al blog Calidad y confianza

Cómo crear una matriz de pruebas A2P SMS por destino, operador, remitente y tipo de mensaje

Una guía operativa para diseñar pruebas A2P SMS repetibles, registrar evidencia técnica y comparar rutas sin confundir DLR con recepción observada en el terminal.

Equipo editorial de BulkSMSMarket06 septiembre 2026Control editorial 94/100

Matriz operativa de pruebas A2P SMS con destinos, redes, remitentes y resultados de entrega

Por qué una prueba aislada no valida una ruta SMS

Un SMS enviado a un único número, en una única red y en una única franja horaria solo describe ese caso concreto. No demuestra que la misma ruta mantendrá un comportamiento comparable ante otros países, redes de suscripción, tipos de remitente, codificaciones, longitudes o contenidos legítimos.

Una matriz de pruebas A2P SMS transforma una comprobación puntual en un programa de evaluación repetible. Su objetivo no es prometer entrega ni sustituir la supervisión de producción: es generar evidencia comparable para decidir qué rutas merecen más observación, qué escenarios requieren investigación y bajo qué condiciones una ruta puede evaluarse antes de recibir más tráfico.

La disciplina principal consiste en no extrapolar más allá de la muestra. Un resultado favorable en un destino no valida un país completo; un resultado favorable en una red no valida necesariamente otra red; y un DLR favorable no prueba por sí mismo que una persona haya visto el mensaje en la interfaz de su teléfono.

Trate cada combinación de variables como una celda de prueba independiente.
Mantenga una versión identificable de la matriz y de cada caso ejecutado.
Compare solo celdas equivalentes o documente con precisión qué variable cambió.
Separe los hechos observados de las declaraciones contractuales, técnicas o comerciales de terceros.

Por qué una prueba aislada no valida una ruta SMS

Qué debe responder la matriz antes de mover tráfico a producción

Antes de ampliar tráfico, la matriz debe responder preguntas operativas concretas. ¿Qué combinaciones de destino, red, remitente y contenido se han probado? ¿Qué resultados se observaron? ¿Cuántas observaciones comparables existen? ¿Qué estados llegaron, en qué secuencia y con qué retraso? ¿Hubo diferencias entre la aceptación inicial, los callbacks o DLR y la recepción observada en un terminal de prueba?

No todas las decisiones necesitan el mismo nivel de evidencia. Una ruta en exploración puede requerir pruebas controladas y revisión manual. Una ruta que vaya a recibir tráfico sensible, como OTP o notificaciones transaccionales, exige una cobertura de casos más cercana a su uso real, con límites internos de riesgo definidos por el equipo responsable.

La matriz también debe dejar visibles las áreas no probadas. La ausencia de un resultado no debe convertirse en una inferencia positiva. Marque las celdas sin muestra como no evaluadas, no como correctas.

Cobertura: qué destinos, redes y escenarios están realmente representados.
Repetibilidad: si el mismo caso puede ejecutarse y compararse de nuevo.
Evidencia: qué ocurrió en la plataforma, qué informó el proveedor y qué se observó de forma independiente.
Incertidumbre: qué no puede concluirse por tamaño de muestra, falta de terminal de prueba o variación de condiciones.
Decisión: ampliar, mantener bajo observación, pausar o investigar.

Qué debe responder la matriz antes de mover tráfico a producción

Dimensiones básicas de una matriz de pruebas A2P SMS

El diseño comienza por definir las dimensiones que pueden alterar el resultado. Normalice el número de destino en formato internacional y conserve el país como un campo explícito. La Recomendación ITU-T E.164 es la referencia apropiada para representar la dimensión internacional de la numeración.

No deduzca el operador actual solo a partir del rango numérico. La portabilidad móvil permite conservar el MSISDN al cambiar de red de suscripción. Por ello, conviene distinguir el operador inferido por rango, cuando exista, del operador o red de suscripción observado o confirmado por un procedimiento autorizado.

Registre el remitente exactamente como fue sometido. El tipo de remitente puede ser alfanumérico, numérico u otro formato permitido por el contexto técnico y regulatorio aplicable. No suponga que el comportamiento de un remitente será idéntico al de otro, incluso en el mismo destino.

País y destino en formato internacional.
Red móvil o red de suscripción, con la fuente de la atribución.
Tipo de numeración y condición conocida de portabilidad, si procede.
Ruta, conexión o configuración bajo evaluación.
Remitente sometido y su formato.
Tipo de mensaje: OTP, transaccional o marketing autorizado.
Codificación, alfabeto, longitud y segmentación.
Ventana horaria y fecha de ejecución.

Separe OTP, transaccionales y marketing autorizado

OTP, mensajes transaccionales y marketing autorizado no deben mezclarse en una misma conclusión operativa. Aunque todos utilicen SMS, suelen responder a expectativas de contenido, oportunidad y trazabilidad diferentes. Una prueba debe representar el caso de uso legítimo que se pretende evaluar, sin reutilizar indiscriminadamente el mismo texto para todos los escenarios.

Para OTP, utilice textos de prueba inequívocos, sin datos personales y sin códigos que concedan acceso real. Registre el instante de envío y la observación en el terminal cuando disponga de un dispositivo de prueba controlado. Para mensajes transaccionales, use una notificación ficticia y claramente identificada como prueba. Para marketing, limite los ensayos a números autorizados y a contenido que cumpla las obligaciones aplicables.

Esta separación reduce interpretaciones erróneas. Un resultado técnico de un mensaje corto de prueba no demuestra necesariamente el comportamiento de un mensaje concatenado, con caracteres no GSM o con un remitente distinto.

OTP: texto breve de prueba, sin credenciales ni acceso real.
Transaccional: evento ficticio, identificable y sin información sensible.
Marketing autorizado: solo destinatarios de prueba autorizados y contenido conforme.
No combine resultados entre categorías sin indicar que el caso de uso cambió.

Seleccione números de prueba de forma responsable

Mantenga un inventario controlado de números de prueba con autorización documentada para recibir mensajes. Cada número debe tener un identificador interno, país, formato internacional, fuente de la atribución de red y, cuando sea posible, información sobre si la recepción puede observarse en un terminal controlado.

No exponga números completos en informes amplios si no es necesario. Use un identificador interno o una versión enmascarada en los cuadros de mando, y reserve los datos operativos completos para los controles de acceso adecuados.

Revise el inventario periódicamente. Un número puede cambiar de estado, de dispositivo o de red de suscripción. Si un resultado depende de una condición que ya no puede verificarse, marque esa celda como pendiente de actualización.

Identificador interno del número de prueba.
Destino normalizado y país.
Red atribuida y método o fecha de atribución.
Estado de autorización para pruebas.
Disponibilidad de terminal controlado para observación independiente.
Última fecha de validación del inventario.

Diseñe casos que cambien una variable cada vez

Un caso base permite detectar diferencias sin confundir causas. Defina un mensaje de prueba legítimo, reconocible y sin información sensible. Después, cree variaciones controladas: cambie la codificación, la longitud, el remitente o un elemento de contenido, manteniendo constantes las demás variables.

La codificación debe ser una dimensión explícita. La especificación 3GPP TS 23.038 contempla, entre otras opciones, el alfabeto GSM de 7 bits, datos de 8 bits y UCS2 de 16 bits. También establece que, con el alfabeto GSM de 7 bits, un mensaje puede contener hasta 160 caracteres. La longitud, los caracteres empleados y la concatenación pueden cambiar el tratamiento técnico del mensaje.

Incluya casos de una sola parte y casos concatenados cuando sean relevantes para el tráfico previsto. Registre la configuración solicitada y el resultado observado; no infiera la codificación final a partir del texto visible en el teléfono.

Caso base: texto corto, identificable y sin caracteres ambiguos.
Variación de codificación: pruebe el conjunto de caracteres relevante para su tráfico.
Variación de longitud: una parte y, cuando proceda, mensaje concatenado.
Variación de remitente: evalúe cada remitente que vaya a utilizarse.
Variación de contenido: cambie solo el elemento que desea investigar.
Ventana horaria: repita en franjas definidas sin alterar otras condiciones.

Qué medir en cada envío

El registro de cada envío debe permitir reconstruir la secuencia completa. Conserve el instante de sometimiento, el resultado de aceptación, los identificadores de correlación devueltos por la interfaz, todos los eventos de callback o DLR y cualquier observación independiente en el terminal.

Los identificadores son esenciales. La especificación 3GPP TS 23.040 define elementos como TP-Message-Reference y SMS-STATUS-REPORT, así como marcas temporales y estados asociados. En una integración HTTP o SMPP, el identificador expuesto por cada sistema puede ser distinto; documente cómo se correlaciona un identificador de cliente con el identificador de proveedor, el callback y la observación de prueba.

Registre estados temporales y fallos, no solo un resultado final simplificado. El flujo SMS puede contemplar indisponibilidad temporal, reintentos o resultados posteriores. Borrar estos eventos intermedios impide entender si una diferencia se debe a aceptación, entrega, notificación o retraso de reporte.

Identificador interno de ejecución y versión del caso.
Marca temporal de sometimiento y resultado de aceptación.
Identificadores de correlación disponibles.
Ruta o configuración evaluada.
Destino y remitente tal como fueron sometidos.
Codificación, longitud y número de partes esperadas.
Eventos DLR o callback: estado bruto, hora de recepción y carga útil conservada.
Observación de terminal: sí, no o no disponible; hora y método de observación.

DLR enviado no equivale a recepción observada en el terminal

Un DLR es evidencia técnica valiosa, pero debe interpretarse en su nivel correcto. TS 23.040 distingue SMS-SUBMIT, SMS-DELIVER, SMS-DELIVER-REPORT y SMS-STATUS-REPORT. Estos mecanismos describen eventos, acuses y resultados de transferencia; no definen un evento de lectura por la persona destinataria.

Clasifique la evidencia para evitar afirmaciones excesivas. La aceptación confirma que una interfaz aceptó el envío bajo sus condiciones. Un callback o DLR confirma que se recibió un reporte con un estado y una hora. La observación independiente en un terminal controlado confirma que el mensaje se vio en ese dispositivo y momento, si la correlación con el envío es sólida. Ningún nivel acredita por sí mismo consentimiento, identidad, propiedad del número o lectura por un usuario final.

Cuando no exista observación en terminal, informe el resultado como estado reportado, no como recepción comprobada. Cuando exista, conserve el método de verificación y el identificador que vincula la observación al envío concreto.

Nivel 1: aceptación del envío por la interfaz.
Nivel 2: DLR o callback recibido y conservado.
Nivel 3: recepción observada en un terminal de prueba controlado.
No equipare recepción observada con lectura humana, consentimiento o identidad.
No presente un DLR como garantía universal de entrega.

FAQ

Preguntas frecuentes

¿Cuántos envíos necesita una matriz de pruebas A2P SMS?

No existe un número universal que convierta una muestra en concluyente. Defínalo según el riesgo operativo, los destinos, las redes, el tipo de mensaje y la variabilidad que necesite observar. Lo importante es conservar el tamaño de muestra por celda y no comparar como equivalentes celdas con cobertura o condiciones distintas.

¿Un DLR de entregado prueba que el SMS llegó al teléfono?

No por sí solo. Un DLR es un reporte técnico de estado y debe conservarse como evidencia de ese nivel. La recepción observada en un terminal de prueba controlado es una evidencia distinta. Ninguna de las dos prueba por sí misma que una persona leyó el mensaje.

¿Debe incluirse HLR Lookup en la matriz?

Puede registrarse como una fuente de contexto cuando su uso esté autorizado, pero no debe tratarse como prueba de consentimiento, identidad, propiedad del número, ruta real ni entrega. La portabilidad móvil puede separar el rango numérico de la red de suscripción actual.

¿Por qué deben probarse caracteres y mensajes largos?

Porque la codificación y el alfabeto son variables técnicas explícitas. TS 23.038 contempla GSM de 7 bits, datos de 8 bits y UCS2 de 16 bits, y la longitud puede requerir concatenación. Un resultado con texto corto no valida automáticamente otro contenido o una longitud distinta.