Test di accettazione SMS A2P: convalida l’integrazione prima della produzione

Che cosa convalida un test di accettazione e che cosa resta escluso

Un test di accettazione consente di verificare che l’integrazione scambi richieste e risposte come concordato: stabilisce una connessione, esegue l’autenticazione, accetta o rifiuta gli invii in modo interpretabile ed elabora gli eventi successivi previsti. Il risultato si limita ai casi, alle destinazioni, ai mittenti, ai contenuti e all’ambiente sottoposti a test.

Non equivale a una garanzia di consegna futura e non dimostra il comportamento presso altri operatori, destinazioni o condizioni. In SMPP, la risposta a submit_sm comunica l’esito della richiesta; la consegna può avvenire in seguito. È opportuno registrare separatamente l’accettazione tecnica, lo stato successivo del messaggio e qualsiasi conferma disponibile.

• Definisci quali componenti e comportamenti rientrano nell’accettazione: connettività, autenticazione, formato, risposte, correlazione e callback.
• Annota gli aspetti esclusi, come la consegna a destinazioni non testate o le prestazioni sotto carichi diversi da quelli provati.
• Concorda il significato di «approvato» per ciascun caso prima di iniziare.

Definisci l’ambito prima di inviare messaggi

Prepara un piano condiviso da ingegneria, operations e dalle parti responsabili della connessione. Specifica l’ambiente di test, le destinazioni autorizzate, i mittenti e i contenuti approvati, oltre a chi esegue ciascun caso e a chi ne interpreta il risultato. Usa solo numeri e messaggi il cui impiego è autorizzato e conforme alle regole applicabili.

Documenta anche le condizioni tecniche attese: protocollo, parametri supportati, formato degli indirizzi, codifica, limiti concordati e meccanismo di ricezione delle risposte o degli eventi. La struttura della numerazione internazionale va gestita in modo coerente con l’ambito definito; non dare per scontato che qualsiasi stringa dall’aspetto numerico sia valida per la route.

• Definisci l’ambiente, la finestra di test, le destinazioni e i mittenti consentiti.
• Approva i contenuti e verifica che i messaggi siano legittimi e autorizzati.
• Assegna i responsabili dell’invio, del monitoraggio, dell’analisi degli errori e della decisione di approvazione.
• Registra le versioni della configurazione e i parametri rilevanti, così da poter riprodurre il caso.

Verifica connettività, autenticazione, formato e risposte

In HTTP, verifica che la richiesta raggiunga l’endpoint previsto e che il client interpreti sia il codice di stato sia il corpo della risposta. Le classi HTTP descrivono l’esito della richiesta HTTP: un 2xx, da solo, non dimostra che l’SMS sia arrivato al terminale. Verifica anche il formato della risposta e come vengono rappresentati accettazione e rifiuto in base al contratto tecnico.

In SMPP, convalida l’instaurazione della sessione e il bind, lo scambio di PDU, le risposte e il mantenimento della connessione. enquire_link consente di verificare la comunicazione a livello applicativo. La risposta submit_sm_resp include l’esito della richiesta e, quando previsto, un identificativo del messaggio assegnato dall’SMSC; non confonderla con un successivo rapporto di consegna.

Prova i formati usati dall’integrazione: indirizzo di destinazione, indirizzo di origine, codifica e lunghezza del messaggio. L’SMSC può rifiutare o troncare contenuti che superano i limiti consentiti dalla rete o dall’implementazione. Verifica anche che i rifiuti vengano registrati e classificati; in SMPP, command_status comunica l’esito della richiesta.

• Prova credenziali valide e, in un ambiente controllato, la gestione di credenziali di autenticazione non valide.
• Verifica, entro l’ambito concordato, formati validi e non validi degli indirizzi, codifica e lunghezze.
• Controlla le risposte di accettazione e di rifiuto senza interpretarle come prova di consegna.
• In SMPP, convalida il bind, le risposte associate e il mantenimento della sessione, inclusi i timer configurati.

Verifica la correlazione e la gestione dei callback

Ogni invio e ogni evento successivo devono poter essere associati in modo univoco all’interno dell’applicazione. In SMPP, sequence_number collega una risposta alla relativa richiesta e deve essere conservato nella risposta; inoltre, le risposte possono arrivare fuori ordine. Non basare la correlazione esclusivamente sull’ordine di arrivo.

Definisci come gestire callback o ricevute duplicati, tardivi e fuori ordine. La deduplicazione è una scelta d’implementazione: non si deve presumere che il protocollo garantisca la consegna di un singolo evento. Registra gli identificativi, lo stato ricevuto, il timestamp disponibile e l’esito dell’elaborazione, evitando che un evento ripetuto produca effetti collaterali indesiderati.

• Prova risposte che arrivano fuori ordine e verifica che siano associate all’invio corretto.
• Invia o simula eventi ripetuti e verifica la policy di deduplicazione concordata.
• Convalida la gestione di callback tardivi, assenti o con identificativi non correlabili.
• Conserva tracce sufficienti a ricostruire la sequenza senza esporre credenziali.

Progetta casi controllati per successi, rifiuti e stati incerti

Un piano utile non si limita al caso ideale. Includi una richiesta accettata, una richiesta rifiutata per un parametro controllato, una risposta tardiva o un timeout e i diversi esiti di consegna osservabili tramite la connessione. Per ciascun caso, annota l’input, il risultato atteso, quello effettivo e le evidenze.

Considera incerto un timeout dell’invio HTTP: la richiesta potrebbe essere stata elaborata anche se il client non ha ricevuto risposta. Non ripetere alla cieca un’operazione non idempotente, a meno che non esista un meccanismo concordato per determinare se sia stata applicata o per evitare duplicati. Un timeout, da solo, non dimostra che il provider abbia rifiutato il messaggio.

In SMPP, distingui un errore di sottomissione comunicato nella risposta da un successivo errore di consegna. Registra i due esiti separatamente e verifica come li rappresenta l’applicazione.

• Caso accettato: verifica la risposta, l’identificativo e la registrazione dell’invio.
• Caso rifiutato: verifica la classificazione dell’errore e l’assenza di una falsa conferma di consegna.
• Caso con timeout: contrassegna l’esito come incerto e segui la procedura concordata prima di riprovare.
• Caso con callback assente, tardivo o duplicato: verifica allarmi, riconciliazione e gestione operativa.
• Caso con messaggio ancora in transito: evita di classificarlo prematuramente come consegnato o fallito.

Distingui l’accettazione tecnica dall’osservazione della consegna

Se devi osservare l’esito della consegna in SMPP, verifica che, quando opportuno, venga richiesto il SMSC Delivery Receipt e che l’integrazione possa ricevere l’evento previsto, per esempio tramite deliver_sm o data_sm, a seconda dell’implementazione. La risposta immediata all’invio e la ricevuta successiva sono fasi distinte.

Interpreta ciascun DLR in base a chi lo emette e a ciò che indica. La specifica 3GPP distingue i rapporti del Service Centre, che confermano la ricezione da parte di quel centro e non del terminale, dai rapporti emessi dalla Mobile Station, che confermano la ricezione da parte della stazione mobile, ma non che una persona abbia visto o letto il messaggio. Uno stato come ENROUTE indica che il messaggio è ancora in transito: non è né una conferma finale di consegna né, di per sé, un errore.

L’osservazione di pochi messaggi controllati descrive solo quei casi nell’ambiente e nel momento del test. Non garantisce risultati futuri né consente di estrapolare automaticamente conclusioni ad altre destinazioni, altri operatori o altre condizioni.

• Separa l’esito della richiesta HTTP o SMPP dallo stato di consegna successivo.
• Documenta la fonte e la portata dei DLR ricevuti.
• Non presentare un DLR come prova di lettura o di ricezione da parte di una persona.
• Definisci come conteggiare gli stati non finali e le ricevute che non arrivano durante la finestra di osservazione.

Definisci i criteri di approvazione e le evidenze

I criteri devono essere osservabili e concordati prima di eseguire i test. Separa i requisiti di connettività e di elaborazione delle richieste da quelli relativi all’osservazione della consegna. Per ciascuno, indica quale risposta o evento vale come approvazione, quali errori impediscono l’abilitazione e quali esiti restano in attesa di analisi.

Conserva il piano, la configurazione rilevante, le richieste e le risposte, gli identificativi, gli eventi ricevuti e il risultato di ogni caso. Le evidenze devono permettere di ricostruire che cosa è stato testato e che cosa no, senza trasformare un campione controllato in un’affermazione generale sulle prestazioni.

• Approvazione tecnica: sessione o endpoint operativo, autenticazione e formati conformi, risposte interpretate e correlazione corretta.
• Approvazione operativa: rifiuti, timeout, duplicati ed eventi tardivi gestiti secondo la procedura concordata.
• Osservazione della consegna: ambito, stati, fonte del DLR e finestra di attesa documentati separatamente.
• Decisione finale: registra i casi approvati, quelli in sospeso, le eccezioni accettate e i responsabili che autorizzano a procedere.

Abilita la produzione gradualmente e prevedi una procedura di ripristino

Dopo l’accettazione, abilita il traffico gradualmente, con limiti e una finestra di osservazione definiti per il servizio. Non esiste una soglia universale di volume né una sequenza di promozione stabilita dagli standard: concorda limiti, segnali di allerta e responsabili in base al rischio e alle esigenze operative.

Prima del primo traffico, stabilisci chi può fermare o revocare l’abilitazione, quali condizioni attivano tale decisione e come gestire i messaggi con esito incerto. Monitora separatamente connettività, risposte, rifiuti, callback e stati di consegna. L’approvazione di un test controllato autorizza solo l’ambito concordato e non garantisce il comportamento in qualsiasi condizione futura.

• Definisci i limiti iniziali e i segnali di allerta prima di attivare il traffico.
• Assegna i responsabili del monitoraggio e l’autorità di fermare o revocare l’abilitazione.
• Stabilisci come analizzare i timeout ed evitare tentativi che possano duplicare i messaggi.
• Amplia l’ambito solo dopo aver esaminato le evidenze e risolto i blocchi concordati.