Änderungen an HTTP- und SMPP-Integrationen für A2P-SMS: Kompatibilität vor dem Deployment prüfen

Welche Änderungen Regressionstests erfordern – und wo ihre Grenzen liegen

Regressionstests für eine Integration prüfen, ob eine Änderung den technischen Vertrag zwischen einer Anwendung und ihrer SMS-Schnittstelle beeinträchtigt hat. Sie sind sinnvoll, wenn die Clientanwendung, der Connector, die Transportkonfiguration oder die Interpretation von Antworten und Statusmeldungen geändert wird. HTTP und SMPP sind unterschiedliche Schnittstellen: Ein erfolgreicher Test der einen validiert nicht automatisch die andere.

Der Umfang muss ausdrücklich festgelegt werden. Eine erfolgreiche HTTP-Antwort bestätigt das Ergebnis der Anfrage gemäß der HTTP-Semantik, nicht die Zustellung der SMS an das Gerät. Ebenso beweisen weder der Aufbau einer SMPP-Sitzung noch eine Antwort auf einen Sendevorgang für sich genommen, dass der Empfänger die Nachricht erhalten hat. Die Zustellung und die Bedeutung späterer Statusmeldungen hängen von den verfügbaren Nachweisen und der maßgeblichen Dokumentation ab.

• Einbeziehen: Kompatibilität von Anfragen, Feldern und vereinbarter Codierung, Interpretation von Antworten, Zuordnung von Kennungen und Umgang mit Verbindungsabbrüchen.
• Getrennt betrachten: technische Annahme, späterer Nachrichtenstatus und bestätigter Empfang auf einem Endgerät.
• Integrationstests nicht als Ersatz für eine Bewertung von Route, Abdeckung oder Zustellqualität verwenden.

Technischer Vertrag: Felder, Codierung, Absender, Referenzen und Semantik

Überführen Sie vor dem Schreiben der Tests die aktuelle API-Dokumentation oder die Dokumentation des SMPP-Anbieters in einen überprüfbaren Vertrag. Aus allgemeiner Dokumentation lässt sich nicht ableiten, welche Felder verpflichtend sind, wie der Absender angegeben wird, welche Codierung unterstützt wird, welches Format eine Kennung hat oder welche Statusmeldungen zurückgegeben werden. Halten Sie für jede Regel die Quelle fest und klären Sie Unklarheiten anhand der maßgeblichen Spezifikation oder mit dem betreffenden Anbieter.

Notieren Sie für jedes Feld, ob es verpflichtend oder optional ist, welches Format und welche dokumentierten Grenzwerte gelten, ob es einen Standardwert gibt und welches Verhalten bei fehlenden oder ungültigen Angaben erwartet wird. Legen Sie für die Codierung fest, welche Textfälle der Vertrag abdeckt und wie Sie prüfen, ob der über die Schnittstelle empfangene Inhalt die erwartete Bedeutung beibehält. Gehen Sie nicht davon aus, dass zwei Connectoren Zeichen, Absender oder Referenzen gleich interpretieren.

Definieren Sie auch die Semantik der Antworten: Was Annahme oder Ablehnung in der jeweiligen Schnittstelle bedeutet, welche Kennung zurückgegeben wird und wie sie dem späteren Status zugeordnet wird. Interpretieren Sie SMPP-Vorgänge, Antworten, Felder und Statusmeldungen anhand der vereinbarten Versionsspezifikation und der vertraglich festgelegten Implementierung. Leiten Sie keine Details zu einer Integration aus der Dokumentation einer anderen ab.

• Führen Sie für jede Schnittstelle eine Tabelle mit Feld, dokumentierter Regel, Validierung und erwartetem Ergebnis.
• Trennen Sie Anforderungskennung und Nachrichtenkennung, sofern der Vertrag sie unterscheidet, und dokumentieren Sie Geltungsbereich und Verwendung.
• Bewahren Sie aussagekräftige, sichere Beispiele ohne echte personenbezogene Daten oder Zugangsdaten auf, um Tests wiederholen zu können.

HTTP- und SMPP-Testfälle: Annahme, Ablehnung und Wiederherstellung

Erstellen Sie für jede Schnittstelle eine eigene Testsuite. Prüfen Sie bei HTTP gültige Anfragen und Eingaben, die der Vertrag als ungültig definiert. Kontrollieren Sie, ob die Anwendung die Antwort korrekt interpretiert und die notwendige Zuordnung beibehält. HTTP-Statuscodes beschreiben das Ergebnis der HTTP-Interaktion gemäß RFC 9110; ihre Bedeutung für den SMS-Versand muss jedoch dem API-Vertrag entnommen werden.

Testen Sie bei SMPP die Verbindung und die für die verwendete Version und den jeweiligen Anbieter definierten Sendevorgänge getrennt. Prüfen Sie die Protokollantwort und den Umgang mit dokumentierten Ablehnungen. Die SMPP-Spezifikation v3.4 dient als Referenz für Vorgänge und Antworten dieser Version; welche konkreten Ergebnisse zu erwarten sind, hängt jedoch vom jeweils geltenden Vertrag ab.

Ergänzen Sie Szenarien für Timeouts, Verbindungsabbrüche und Wiederherstellung, legen Sie dabei aber kein allgemeingültiges Verhalten fest. Klären Sie zunächst, was der Vertrag zu Wiederholungsversuchen, Anfragen mit unbekanntem Ergebnis und zur erneuten Verbindung vorgibt. Ist nichts dokumentiert, halten Sie den Fall als offene Entscheidung fest, statt eine Annahme zum Abnahmekriterium zu machen.

• Testen Sie die technische Annahme mit autorisierten Testdaten und einem kontrollierten Ziel.
• Beziehen Sie erwartete Ablehnungen ein und bestätigen Sie, dass das System sie nicht als Annahme protokolliert.
• Simulieren Sie Timeouts und Verbindungsabbrüche in einer kontrollierten Umgebung, überprüfen Sie das vereinbarte Verhalten und sichern Sie die Nachweise.
• Senden Sie eine Nachricht mit ungewissem Ergebnis nicht automatisch erneut, sofern Vertrag und Anwendungsdesign nicht festlegen, wie unerwünschte Folgen vermieden werden.

Callbacks und zugeordnete Statusmeldungen: Was ein DLR belegt

Wenn die Integration Callbacks oder Statusbenachrichtigungen verwendet, testen Sie den vollständigen Ablauf von der anfänglichen Annahme bis zum späteren Ereignis, das der Vertrag definiert. Prüfen Sie, ob die Benachrichtigung anhand der dokumentierten Kennungen dem richtigen Sendevorgang zugeordnet werden kann und ob die Anwendung zwischen einem ausbleibenden Ereignis, einem empfangenen Ereignis und einem gemeldeten Endstatus unterscheidet.

Gehen Sie nicht davon aus, dass Callbacks bei allen Anbietern dieselben Felder, dieselbe Reihenfolge oder dieselbe Semantik haben. Prüfen Sie Format, Authentizität, Wiederholungen und den Umgang mit verspäteten Ereignissen anhand der Dokumentation der Integration. Ist ein Aspekt nicht spezifiziert, kennzeichnen Sie ihn als Unsicherheit und vereinbaren Sie, wie er im Betrieb beobachtet wird.

Ein DLR meldet einen Status innerhalb des Systems, das ihn ausgibt und übermittelt. Für sich genommen ist es nicht zwingend eine unabhängige Bestätigung des Empfangs auf dem Mobilgerät. Kennzeichnen Sie in den Regressionstest-Nachweisen klar, was Sie beobachtet haben: API-Antwort, SMPP-Antwort, Callback oder – sofern vorhanden – eine unabhängige Überprüfung am Endgerät.

• Prüfen Sie, ob jedes Ereignis gemäß Vertrag der richtigen Referenz zugeordnet wird.
• Protokollieren Sie Quelle und Zeitpunkt der Beobachtung jeder Statusmeldung.
• Unterscheiden Sie von der Route gemeldete Statusmeldungen von unabhängig verifiziertem Empfang.

Vorher und nachher anhand von Kriterien und Nachweisen vergleichen

Führen Sie dieselben Testfälle mit der vorherigen und der neuen Version unter vergleichbaren Bedingungen aus. Vergleichen Sie die Ergebnisse je Schnittstelle und Szenario, nicht nur den Gesamtanteil bestandener Tests. Eine Abweichung kann erwartet sein, wenn der Vertrag bewusst geändert wurde; sie muss vor dem Deployment dokumentiert, freigegeben und in den Tests berücksichtigt sein.

Halten Sie die Version der Anwendung und des Connectors, relevante nicht geheime Konfigurationen, den ausgeführten Testfall, die beobachtete Antwort und das erwartete Ergebnis fest. Speichern Sie sensible Daten gemäß den geltenden Richtlinien und vermeiden Sie Zugangsdaten oder unnötige personenbezogene Informationen in gemeinsam genutzten Protokollen.

Legen Sie die Abnahmekriterien vor der Ausführung fest. Mindestens müssen die verpflichtenden Vertragstests das erwartete Ergebnis liefern, und ungeklärte Abweichungen müssen untersucht werden. Legen Sie keine Grenzwerte für Latenz, Verfügbarkeit oder Zustellung ohne anwendbare Spezifikation und geeignete Messung fest.

• Ordnen Sie jede Abweichung als geplante Änderung, bestätigte Regression oder noch ungeklärtes Ergebnis ein.
• Vergleichen Sie HTTP-Statuscodes und -Antwortkörper anhand der API sowie SMPP-Antworten anhand der vereinbarten Version und Implementierung.
• Fügen Sie genügend Nachweise bei, um den Testfall wiederholen zu können, ohne Geheimnisse offenzulegen.

Schrittweises Deployment und Rollback, ohne Tests und Produktion zu vermischen

Testen Sie zuerst in einer Umgebung und mit für Tests freigegebenen Zielen, sofern diese verfügbar und dokumentiert sind. Halten Sie Zugangsdaten, Konfiguration und Testnachweise getrennt von denen der Produktion. Gibt es keine geeignete Testumgebung, beschränken Sie jede Validierung auf das für die Produktion Genehmigte und beachten Sie die geltenden Einwilligungs- und Compliance-Regeln.

Vereinbaren Sie vor dem Deployment, wer über Fortsetzung oder Abbruch entscheidet, welche Testfälle bestanden sein müssen und welche Signale eine Untersuchung oder einen Rollback erfordern. Der Rollback muss einem erprobten Verfahren für die Anwendung und den Connector folgen. Ohne Kenntnis des Systems lässt sich keine allgemeingültige Infrastrukturregel festlegen.

Machen Sie während eines schrittweisen Deployments eindeutig kenntlich, welche Version die jeweilige Anfrage erzeugt, und sorgen Sie für ausreichende Beobachtbarkeit, um Integrationsfehler von nachgelagerten Zustellergebnissen zu unterscheiden. Werten Sie eine erfolgreiche technische Antwort nicht als Nachweis für die Qualität der Route.

• Stellen Sie sicher, dass eine vorherige Version oder Konfiguration wiederherstellbar ist und das Rollback-Verfahren validiert wurde.
• Legen Sie vor Beginn Verantwortliche, Abbruchkriterien und die Mindestnachweise fest.
• Kennzeichnen Sie den Testverkehr eindeutig und halten Sie ihn vom Produktivverkehr getrennt.

Checkliste zur Sicherung der Kompatibilität

Eine Integration bleibt kompatibel, wenn ihre Regeln auffindbar sind, ihre Tests wiederholt werden können und beabsichtigte Änderungen von Regressionen zu unterscheiden sind. Überprüfen Sie den Vertrag, wenn sich eine API-Version, eine SMPP-Spezifikation, ein Connector oder eine Konfiguration ändert, die Felder, Antworten oder Statusmeldungen beeinflusst. Maßgeblich ist stets die aktuelle Dokumentation der konkreten Schnittstelle.

Verwenden Sie diese Checkliste, bevor Sie eine Änderung freigeben:

• Sind Version und zu testende HTTP- oder SMPP-Schnittstelle dokumentiert?
• Ist jede Regel zu Feldern, Codierung, Absender und Kennungen durch Dokumentation belegt?
• Gibt es separate Testfälle für Annahme, Ablehnung, Timeout, Verbindungsabbruch und Wiederherstellung?
• Werden Callbacks und Statusmeldungen gemäß Vertrag zugeordnet, und ist ihre Quelle eindeutig?
• Unterscheiden die Nachweise zwischen technischer Annahme, DLR und verifiziertem Empfang auf dem Endgerät?
• Sind Abweichungen gegenüber der vorherigen Version erklärt und freigegeben?
• Sind Verantwortliche, Abbruchkriterien und Rollback-Verfahren festgelegt?
• Sind Tests und Produktivverkehr getrennt und werden die geltenden Regeln eingehalten?