Abnahmetests bei einem Wechsel des A2P-SMS-Anbieters: So validieren Sie vor der Umschaltung
Ein Leitfaden, um vor der Migration von A2P-Traffic reproduzierbare Tests für Konnektivität, Antworten, Callbacks und Statusmeldungen zu vereinbaren. Die technische Abnahme bestätigt nicht, dass die SMS auf dem Endgerät angekommen ist.
Was ein Abnahmetest prüft – und was nicht
Ein Abnahmetest prüft, ob sich eine Integration und ihr Betrieb bei einem konkreten Anwendungsfall gemäß den vereinbarten Anforderungen verhalten. Bei einem Wechsel des A2P-Anbieters kann damit überprüft werden, ob das System Anfragen sendet, Antworten interpretiert, Callbacks verarbeitet und die erforderlichen Ereignisse protokolliert.
Die technische Abnahme belegt für sich genommen weder, dass die SMS auf dem Endgerät des Empfängers angekommen ist, noch garantiert sie, dass die beobachtete Leistung nach der Umschaltung anhält. Eine erfolgreiche HTTP-Antwort bestätigt eine Antwort dieser Schnittstelle, nicht die endgültige Zustellung der Nachricht. Ebenso sollte ein gemeldeter Zustellstatus als Information des Systems behandelt werden, das ihn ausgegeben hat, und nicht als unabhängiger Nachweis für den Empfang auf dem Gerät.
- Legen Sie getrennt fest, was die Schnittstelle prüft, welche Informationen der Anbieter meldet und welche Nachweise zur Zustellung vorliegen.
- Dokumentieren Sie die Grenzen des Tests: Umgebung, Ziele, Absender, Nachrichtentypen, Beobachtungszeitraum und externe Abhängigkeiten.
Umfang und Verantwortlichkeiten festlegen
Vereinbaren Sie vor der Durchführung der Tests, was eingebunden oder migriert wird. Legen Sie die verwendete Schnittstelle – HTTP oder SMPP –, die eingeschlossenen Ziele und Absender, die zulässigen Nachrichtentypen und die Zuständigkeit der einzelnen Systeme für jeden Schritt fest. Für SMPP kann die Spezifikation SMPP v3.4 als technische Referenz dienen, wenn Parameter und Antworten vereinbart werden. Die konkreten Details sind anhand der vereinbarten Version und des Integrationsprofils zu prüfen.
Gehen Sie nicht davon aus, dass alle Anbieter jedes Feld, jeden Status oder jedes Betriebsverhalten gleich interpretieren. Erstellen Sie eine Anforderungsmatrix, in der für jeden Anwendungsfall die erwartete Anfrage, die zu protokollierende Antwort, deren Urheber und die Kriterien für Erfolg oder Fehlschlag festgehalten sind. Abnahmekriterien und Bedingungen für das Anhalten oder Zurücksetzen der Änderung sind Projektentscheidungen und keine universellen Schwellenwerte.
- Halten Sie die Schnittstelle, die anwendbare Version oder das Integrationsprofil sowie die zu prüfende Konfiguration fest.
- Grenzen Sie die eingeschlossenen Ziele, Absender und Traffic-Kategorien ab und benennen Sie ausdrücklich, was ausgeschlossen ist.
- Weisen Sie dem Kunden, dem Anbieter und etwaigen Zwischensystemen Verantwortliche zu.
- Vereinbaren Sie vorab die Abnahmekriterien, blockierende Vorfälle sowie Bedingungen für eine Pause oder einen Rollback.
Testumgebung und Testdaten vorbereiten
Verwenden Sie eine autorisierte Testumgebung und Testnachrichten mit einem von allen Parteien vereinbarten Umfang. Lässt sich die Infrastruktur nicht vollständig von der Produktion trennen, dokumentieren Sie, welche Komponenten gemeinsam genutzt werden und wie die Auswirkungen begrenzt werden. Senden Sie keine Nachrichten an Nummern oder Personen ohne entsprechende Genehmigung.
Verwenden Sie nur die Daten, die für die Durchführung und Fehlerdiagnose des jeweiligen Testfalls erforderlich sind. Legen Sie fest, wer auf die Protokolle zugreifen darf, wie sie geschützt und wie lange sie gemäß den geltenden Richtlinien und Pflichten aufbewahrt werden. Allgemeine technische Quellen legen weder ein universelles Verfahren zur Trennung, Einwilligung oder Aufbewahrung fest noch decken sie alle Fälle ab. Diese Aspekte müssen anhand der geltenden Regeln und mit den zuständigen Personen geklärt werden.
- Bestätigen Sie vor dem Senden von Traffic die Genehmigung, Testziele und Absender.
- Verwenden Sie, sofern die Integration dies ermöglicht, Testkennungen, die von Produktionskennungen unterscheidbar sind.
- Vermeiden Sie unnötige personenbezogene Daten in Nachrichteninhalten, Protokollen oder Screenshots.
- Stellen Sie sicher, dass das Team weiß, wie es den Testlauf stoppt, wenn Traffic den vereinbarten Umfang überschreitet.
Positive und negative Testfälle erstellen
Ein aussagekräftiger Test beschränkt sich nicht darauf, eine gültige Nachricht zu senden. Er sollte auch prüfen, wie sich die Integration bei ungültigen Eingaben, unerwarteten Antworten oder Unterbrechungen verhält. Die Semantik von HTTP ist in RFC 9110 festgelegt; die Bedeutung einer Antwort für den SMS-Ablauf hängt jedoch zusätzlich vom Vertrag und dem Integrationsdesign ab.
Dokumentieren Sie für jeden Testfall das erwartete Ergebnis und die Nachweise, mit denen es verglichen wird. Erfinden Sie keine Fehlercodes und nehmen Sie nicht an, dass ein Verhalten bei allen Anbietern üblich ist. Prüfen Sie die geltenden Werte und Regeln anhand der vereinbarten technischen Dokumentation.
- Gültiger Fall: erforderliche Felder sind vorhanden und die Werte entsprechen dem vereinbarten Format.
- Ungültiger Fall: Ein erforderliches Feld fehlt oder ein Format wird gemäß dem Schnittstellenvertrag nicht akzeptiert.
- Ablehnung: Der Anbieter nimmt eine Anfrage nicht an. Prüfen Sie, ob der Client die Antwort korrekt speichert und klassifiziert.
- Timeout oder Unterbrechung: Prüfen Sie, wie die Ungewissheit protokolliert wird und welche Folgemaßnahme zulässig ist. Vermeiden Sie automatische Wiederholungen, die Nachrichten ohne vereinbarte Regel duplizieren könnten.
- Traffic-Grenze: Testen Sie ausschließlich das genehmigte Volumen und die zulässigen Bedingungen, mit vom Projekt festgelegten Grenzen.
Kennungen, Callbacks und Nachverfolgbarkeit prüfen
Prüfen Sie, ob sich jeder Versand mit seiner Antwort und den späteren Ereignissen verknüpfen lässt, die zur Integration gehören. Vereinbaren Sie, welches System welche Kennung zurückgibt oder erzeugt, an welcher Stelle sie protokolliert und wie sie mit den Callbacks verknüpft wird. Nehmen Sie weder an, dass Kennungen dasselbe Format haben, noch dass ihr Geltungsbereich plattformübergreifend identisch ist.
Testen Sie außerdem die tatsächlich konfigurierten Callbacks: Empfang, Authentizität gemäß dem vereinbarten Mechanismus, Behandlung von Duplikaten und Protokollierung von Verarbeitungsfehlern. Das erwartete Verhalten muss sich aus den Spezifikationen und der Integrationsvereinbarung ergeben. Allein aus dem Ereignisnamen lässt sich keine allgemeingültige Regel ableiten.
- Verknüpfen Sie Anfrage, Antwort und Callback anhand der verfügbaren und dokumentierten Kennungen.
- Protokollieren Sie Datum und Uhrzeit, Umgebung, Testziel, Ergebnis und die zur Reproduktion des Falls erforderliche Konfigurationsversion.
- Prüfen Sie, dass ein Callback nicht einem anderen Versand zugeordnet wird und wiederholte Ereignisse gemäß der vereinbarten Regel behandelt werden.
- Bewahren Sie technische Nachweise mit angemessenen Zugriffs- und Aufbewahrungsregeln auf und vermeiden Sie die Offenlegung von Geheimnissen oder unnötigen Daten.
Statusmeldungen und DLRs mit Vorsicht interpretieren
Nehmen Sie die Statusmeldungen, die Integration und Anbieter vereinbart haben, in die Matrix auf, behandeln Sie ihre Bezeichnungen aber nicht als universell. Dokumentieren Sie, welches System den jeweiligen Status erzeugt, was er in diesem System bedeutet und welche Ungewissheiten bestehen bleiben. Trifft ein Ereignis nicht oder verspätet ein oder entspricht es nicht dem erwarteten Ergebnis, halten Sie dies als Abweichung zur Untersuchung fest und nicht als automatische Schlussfolgerung über das Endgerät.
Ein DLR oder ein vom Anbieter gemeldeter Status ist nicht zwangsläufig eine unabhängige Bestätigung dafür, dass der Empfänger die Nachricht auf seinem Gerät erhalten hat. Der Test sollte die Konsistenz der Statusmeldung von zusätzlichen Empfangsnachweisen trennen, sofern solche Nachweise existieren und zugänglich sind.
- Vergleichen Sie die beobachteten Statusmeldungen mit der für diese Integration dokumentierten Definition.
- Protokollieren Sie fehlende, verspätete oder wiederholte Ereignisse sowie Ereignisse, die sich nur schwer zuordnen lassen.
- Leiten Sie aus einem gemeldeten Status keine Garantie für den Empfang auf dem Endgerät ab.
Verfügbarkeit und Latenz messen, ohne die Ergebnisse zu verallgemeinern
Wenn Verfügbarkeit, Latenz oder Konsistenz bewertet werden sollen, vereinbaren Sie den Beobachtungszeitraum, die Messpunkte, die Testpopulation und die Berechnungsmethode für jede Kennzahl. Trennen Sie die Antwortzeit der Schnittstelle von den Zeitspannen bis zu nachfolgenden Statusmeldungen: Sie messen unterschiedliche Schritte.
Es gibt keine universell gültigen Werte für Latenz, Verfügbarkeit, Stichprobengröße oder Traffic-Grenzen, die sich für alle Projekte als Abnahmekriterien eignen. Eine kleine Stichprobe, die nur bestimmte Ziele umfasst, erlaubt ebenfalls keine Verallgemeinerung auf die künftige Leistung. Legen Sie die Schwellenwerte mit den Parteien entsprechend der vorgesehenen Nutzung und der geltenden Vereinbarung fest und beschreiben Sie, was von der Messung ausgeschlossen ist.
- Geben Sie für jede Messung den Start- und Endpunkt an.
- Dokumentieren Sie den Zeitraum, die Anzahl und den Umfang der Tests. Stellen Sie die Stichprobe nicht als repräsentativ dar, wenn sie es nicht ist.
- Unterscheiden Sie Ergebnisse nach Schnittstelle, Ziel und Ereignistyp, sofern es der Datensatz zulässt.
- Vergleichen Sie Ergebnisse ausschließlich mit Kriterien, die vor ihrer Beobachtung genehmigt wurden.
Abnahme mit Nachweisen und einer reproduzierbaren Entscheidung abschließen
Fassen Sie die Ergebnisse in einem Protokoll zusammen, das eine andere Person prüfen und reproduzieren kann. Fügen Sie für jeden Testfall die relevante Konfiguration, nicht sensible Testdaten, das erwartete und beobachtete Ergebnis, einen Verweis auf den Nachweis, die verantwortliche Person und den zugehörigen Vorfall ein. Trennen Sie Beobachtungen klar von Interpretationen.
Aus der abschließenden Entscheidung muss hervorgehen, was genehmigt wurde, was noch an Bedingungen geknüpft ist und wer die Entscheidung freigegeben hat. Schlägt ein Test fehl oder kann er nicht ausgeführt werden, dokumentieren Sie die Einschränkung und vereinbaren Sie vor der Umschaltung die nächsten Schritte. Legen Sie mit den Verantwortlichen ausdrücklich das Verfahren für eine Pause oder einen Rollback fest. Es gibt keine universelle technische Bedingung, die diese Entscheidung ersetzt.
- Bewahren Sie die Testfallmatrix und das Ergebnisprotokoll an einem zugriffskontrollierten Ort auf.
- Klassifizieren Sie Vorfälle nach der vereinbarten Auswirkung und weisen Sie Verantwortliche sowie einen Nachverfolgungstermin zu.
- Dokumentieren Sie die Grenzen der Testabdeckung und nicht überprüfte Abhängigkeiten.
- Protokollieren Sie die Freigabe, ausstehende Bedingungen und das vereinbarte Verfahren zum Anhalten oder Zurücksetzen.
Häufige Fragen
Bestätigt eine erfolgreiche HTTP-Antwort, dass die SMS zugestellt wurde?
Nein. Sie bestätigt eine erfolgreiche Antwort der Schnittstelle gemäß der geltenden HTTP-Semantik. Für sich genommen belegt sie nicht, dass die Nachricht auf dem Endgerät angekommen ist.
Bestätigt ein DLR, dass der Empfänger die Nachricht auf seinem Gerät erhalten hat?
Das sollte nicht angenommen werden. Ein DLR ist ein Status, der vom ausgebenden System gemeldet wird, und entspricht nicht zwangsläufig einer unabhängigen Bestätigung des Empfangs auf dem Endgerät.
Welche Latenz- oder Verfügbarkeitsschwellenwerte sollte ich für die Abnahme des Anbieters verwenden?
Es gibt keine universell passenden Werte für alle Fälle. Legen Sie mit den Parteien Zeitraum, Messpunkte, Umfang und Schwellenwerte entsprechend der vorgesehenen Nutzung und der geltenden Vereinbarung fest.
Was sollte ich vor der Umschaltung testen?
Vereinbaren Sie mindestens Testfälle für gültige und ungültige Eingaben, Antworten, Timeouts, zulässige Grenzen, die Zuordnung von Kennungen, Callbacks und die Statusmeldungen, die zur Integration gehören. Ergänzen Sie Abnahmekriterien sowie Bedingungen für eine Pause oder einen Rollback.
Garantieren Abnahmetests die Leistung nach der Migration?
Nein. Sie beschreiben das beobachtete Verhalten in einer bestimmten Umgebung, innerhalb eines bestimmten Umfangs und Zeitraums. Sie garantieren keine künftigen Ergebnisse und erlauben keine Verallgemeinerungen über die erhobenen Nachweise hinaus.
Verwendete Quellen
- SMPP Protocol Specification v3.4SMPP Developers Forum
- HTTP Semantics (RFC 9110)IETF
- 3GPP specifications by series3GPP
- E.164: The international public telecommunication numbering planInternational Telecommunication Union
- GSMA networks resourcesGSMA