Test-IBAN für QA: Sichere synthetische Daten

Kurzantwort: Was ist eine Test-IBAN?

Eine Test-IBAN ist eine synthetische International Bank Account Number, mit der Softwareverhalten geprüft wird. Teams nutzen sie für Zahlungsformulare, Länderauswahl, Normalisierung, API-Fixtures, Browser-Automatisierung, Screenshots, Schulungen und technische Dokumentation. Die Zeichenfolge sollte zur ausgewählten Länderregel passen und die mathematischen Prüfungen bestehen, die der Code behandeln muss.

Das Wort Test ist entscheidend. Ein erzeugter Wert ist kein Weg zu einem echten Konto, einem Zahlungsempfänger oder einem Bankverzeichnis. Der IBAN-Massengenerator erzeugt isolierte synthetische Zeilen, während der IBAN-Prüfer die eingegebenen Zeichen untersucht. Keine der beiden Funktionen fragt eine Bank ab oder bestätigt Eigentum.

• Geeignet: Formularprüfung, Parser, Fixtures, Regressionstests, Demos und technische Texte.
• Nicht geeignet: Überweisungen, Lastschriften, Zahlungsempfänger, Eigentumsbehauptungen oder Kontosuche.
• Speichere Kennzeichnung, Umgebungsgrenze und Löschregel direkt neben den Testdaten.

Synthetische Testdaten sind kein echtes Bankkonto

Ein synthetischer Wert soll ein Format abbilden. Er kann den richtigen Ländercode, die erwartete Gesamtlänge, passende BBAN-Zeichenklassen und einen MOD-97-Rest von 1 besitzen. Das beantwortet nur eine technische Frage: Verhält sich die Zeichenfolge für diese Regel strukturell wie eine gültige IBAN?

Eine von einer Bank ausgestellte IBAN beantwortet andere Fragen. Sie kann einem Konto, einer Bank, einer Filiale, einer Währung, einem Zahlungsweg und einem aktuellen Zustand zugeordnet sein. Ein lokaler Prüfer kann das nicht aus den Zeichen ableiten. Deshalb kann eine IBAN die Prüfsumme bestehen und trotzdem nicht zugeteilt, inaktiv, ungeeignet für Zahlungen oder ausdrücklich nur ein Fixture sein.

Eine Test-IBAN in drei Schichten prüfen

Ein gutes QA-Fixture ist nicht nur eine zufällige Zeichenfolge. Beginne mit der registrierten Länderregel und prüfe jede Schicht separat, damit ein Fehler den richtigen Codepfad trifft. Das IBAN-Länderverzeichnis vergleicht unterstützte Längen und BBAN-Muster; der IBAN-Decoder zeigt sichtbare Länder-, Prüfziffer- und BBAN-Teile.

Zuerst werden Ländercode und Gesamtlänge geprüft. Danach folgen die erlaubten numerischen, alphabetischen oder alphanumerischen Zeichen. Zum Schluss wird MOD-97-10 berechnet. Eine Testsuite sollte erfolgreiche und absichtlich fehlerhafte Werte enthalten, denn Fehlerbehandlung ist Teil des Vertrags.

1. 1. Land und LängeWähle ein unterstütztes Land und bestätige die registrierte feste Länge des vollständigen Werts.
2. 2. ZeichenmusterPrüfe, ob jedes nationale Feld die vorgesehenen Ziffern oder Buchstaben akzeptiert.
3. 3. MOD-97-PrüfsummeFühre die internationale Berechnung aus und bestätige den erwarteten Rest.
4. 4. GeschäftsgrenzeHalte fest, dass nur Struktur geprüft wurde; leite daraus keinen Eigentums- oder Zahlungsnachweis ab.

• Längenfehler und Prüfsummenfehler getrennt testen, damit die Oberfläche das erste hilfreiche Problem erklärt.
• Für den Prüfsummenpfad eine einzelne Prüfziffer eines gültigen Fixtures ändern.
• Buchstaben in einem Zahlenfeld nur als bewusst dokumentierten Negativfall verwenden.

Ein sicherer QA-Fixture-Ablauf

Behandle eine Test-IBAN wie jedes andere synthetische Fixture: Zweck definieren, nach einer bekannten Regel erzeugen, prüfen, kennzeichnen und in der benötigten Umgebung halten. Das ist wichtig, weil ein mathematisch gültiger Wert gefährlich werden kann, wenn er in Produktions-Seeds, Rechnungen, Kundendaten oder echte Zahlungsempfänger gelangt.

Für wenige Fälle reicht der Generator auf der Startseite. Für Matrizen und Regressionen nutze den Massengenerator und exportiere CSV oder JSON. Ergänze im eigenen Fixture Land, Länge, erwartetes Ergebnis, Zweck und Verantwortlichen für die Bereinigung. Die Erzeugung passiert im Browser; Repository und CI brauchen trotzdem eigene Produktionsdatenschutz-Kontrollen.

1. DefinierenLand, Feldverhalten, erwartetes Ergebnis und Zweck des Fixtures festhalten.
2. ErzeugenSynthetische Werte nach der Länderregel erstellen; keine Kundendaten in Testdatenbanken kopieren.
3. PrüfenLänge, Muster und MOD-97 testen und das erwartete Ergebnis speichern.
4. Isolieren und löschenTestdaten getrennt halten, Promotion blockieren und nach dem Lauf löschen oder rotieren.

Eine Testmatrix statt nur eines Happy Paths

Ein einziger erfolgreicher Wert beweist wenig. Eine robuste Suite umfasst Länderunterschiede, Darstellungsformen und vorhersehbare Fehler. Nimm mindestens ein kurzes und ein langes Format, numerische und alphanumerische BBANs, eine Druckdarstellung mit Leerzeichen, eine kompakte elektronische Darstellung, Kleinschreibung und eine geänderte Prüfziffer auf.

Welche Länder konkret nötig sind, hängt vom Produkt ab. Die Tabelle ist ein Planungsmuster und keine Zusage, dass jeder Wert im Sandbox-System eines Anbieters funktioniert. Wenn ein Zahlungsanbieter eigene Sandbox-IDs liefert, folge dessen Dokumentation und trenne sie von allgemeinen Format-Fixtures.

• Erwartete Ergebnisse neben dem Fixture speichern, damit Validatoränderungen reviewbar bleiben.
• Beschreibende IDs wie `iban-de-length-22-valid` statt unbeschrifteter Zufallswerte nutzen.
• Keine echten Namen, Karten, Rechnungen oder Kontoauszüge in synthetische Fälle aufnehmen.

Häufige Fehler und praktische Grenzen

Der häufigste Fehler ist die Annahme, eine fake IBAN sei automatisch ein sicherer Zahlungswert. In Suchergebnissen kann fake einen synthetischen Entwicklungswert meinen, aber auch Täuschung andeuten. In Code, Dokumentation und Teamkommunikation sind Test-IBAN, synthetische IBAN oder Fixture bessere Begriffe. Für echte Zahlungen muss der Wert aus einer aktuellen Bankquelle stammen.

Ein weiterer Fehler ist, den Prüfer als Bankabfrage zu behandeln. Ein Browser-Tool kann die sichtbaren Zeichen erklären, weiß aber nicht, ob eine Bankkennung aktiv ist, wem ein Konto gehört, ob ein Empfänger geprüft wurde oder ob eine Zahlung abgewickelt wird. Dafür sind Bank, Zahlungsanbieter oder ein geeignetes Verifikationsverfahren zuständig.

• Synthetische Werte nicht als offiziell, zahlungssicher, zugeteilt oder inhabergeprüft bezeichnen.
• IBAN nicht aus Name, Karte, lokaler Kontonummer oder Screenshot ableiten.
• Fixtures nicht in Rechnungen, Gehaltsdateien, Rückerstattungen oder echte Lastschriftmandate übernehmen.
• Nicht auf einen universellen reservierten Bereich vertrauen; generierte Daten isolieren und kennzeichnen.