Rechnungsformular Testfälle sind die Prüfungen, die darüber entscheiden, ob Ihre Rechnungsmaske den Kontakt mit einem echten Geschäftskunden übersteht. Die Maske sieht einfach aus – ein Name, eine Adresse, ein paar Nummern –, und genau dort verstecken sich die teuersten Fehler, weil die Ausfälle leise sind: Eine Rechnung wird erstellt, versendet und ist falsch.
Dieser Artikel legt dar, was ein geschäftliches Rechnungsformular tatsächlich erfasst, welche Zweige des Formulars am häufigsten zu wenig getestet werden, wie man eine Fallmatrix baut, die sie abdeckt, und worauf jenseits des Formulars zu achten ist.
Was erfasst ein geschäftliches Rechnungsformular tatsächlich?
Mehr als eine Kundenkasse, und in einer anderen Gestalt. Ein privates Rechnungsformular will einen Namen und eine Adresse. Ein geschäftliches Rechnungsformular will wissen, welche Organisation in welcher Eigenschaft und unter welcher steuerlichen Behandlung abgerechnet wird.
Die Felder unterscheiden sich je nach Land, sie gruppieren sich aber in vertraute Blöcke:
- Wer abgerechnet wird – der eingetragene Name des Unternehmens und häufig ein abweichender Geschäftsname.
- Kennungen – die Handelsregisternummer, eine Steuerkennung und eine Umsatzsteuernummer, wo das Land eine ausgibt.
- Rechnungsadresse – die Adresse, die auf der Rechnung stehen muss, was nicht immer die Lieferadresse oder der Sitz ist.
- Kontakt – eine Person, an die die Rechnung geht, und oft eine eigene Adresse für den Rechnungsversand.
- Zahlungsbedingungen – Währung, eine Bestellreferenz und alles, was die Buchhaltung des Kunden verlangt.
Der wichtige strukturelle Punkt ist, dass dieselbe Maske zwei sehr verschiedene Gruppen bedient. Ein Geschäftskunde braucht die Kennungsfelder; eine Privatperson braucht sie nicht und kann sie meist nicht ausfüllen. Ein Formular, das beiden eine feste Feldmenge zeigt, sammelt entweder Unsinn von Privatpersonen ein oder blockiert Unternehmen.
Was sind die vier Zweige, die jedes Rechnungsformular durchlaufen sollte?
Jedes geschäftliche Rechnungsformular hat mindestens vier nennenswert verschiedene Wege, und die meisten Fehler sitzen an den Übergängen zwischen ihnen.
| Zweig | Was sich ändert | Was üblicherweise bricht |
|---|---|---|
| Unternehmen mit Umsatzsteuernummer | Die Kennungsfelder sind Pflicht und werden geprüft | Grenzüberschreitende Formatprüfungen weisen eine legitime Nummer ab |
| Unternehmen ohne Umsatzsteuernummer | Das Feld muss wirklich optional sein | Ein Pflichtattribut macht das Absenden unmöglich |
| Grenzüberschreitend | Steuerbehandlung und Kennungsregeln folgen dem Land des Käufers | Inlandsannahmen werden auf eine ausländische Adresse angewandt |
| Privatperson als Käufer | Geschäftsfelder sollten ganz verschwinden | Halb als Pflicht behandelte Felder bleiben und blockieren den Abschluss |
Testen Sie jeden Zweig zweimal: einmal mit gültiger Eingabe und einmal mit Eingaben, die auf genau eine Weise absichtlich falsch sind. Im zweiten Durchgang wird die Fehlerbehandlung beansprucht, und bei Rechnungsformularen geben Kunden genau dann auf.
Ein praktikables Minimum sind acht Fälle – vier Zweige, jeweils in gültiger und in ungültiger Form – plus die Paare beiderseits jedes Übergangs: der Wechsel von der Privatperson zum Unternehmen mitten im Formular, ein Länderwechsel nach Eingabe der Kennungen und die Rückkehr zu einem gespeicherten Entwurf. Diese Übergangsfälle prüfen Zustände, die einzelne Fälle nie berühren.
Warum verhält sich dasselbe Feld in verschiedenen Ländern anders?
Weil die Anforderung aus nationalen Steuer- und Rechnungsregeln stammt und diese Regeln sich darin unterscheiden, welche Felder eine Rechnung tragen muss und was in jedem Feld stehen muss.
Manche Jurisdiktionen erwarten die Steuerkennung des Käufers auf einer Geschäftsrechnung; andere verlangen sie in denselben Umständen nicht. Manche verlangen eine Registernummer, manche eine Steuernummer, manche beides. Die Pflichteigenschaft eines Feldes kann außerdem von der Art der Leistung abhängen und nicht nur vom Käufer, was bedeutet, dass ein Formular, das die Anforderungen eines Landes fest verdrahtet, im Ausland gleichzeitig zu streng und im Inland zu nachsichtig ist.
Die technische Antwort besteht nicht darin, die Regeln zu kodieren, sondern nach Land zu verzweigen. Bestimmen Sie zuerst das Land und den Käufertyp und leiten Sie daraus ab, welche Felder Pflicht sind, welche optional und welche auszublenden. Halten Sie diese Ableitung an einer einzigen Stelle, denn über eine Vorlage verstreute Länderbedingungen erzeugen genau die Drift, die ein Formular auf zwei Bildschirmen unterschiedlich reagieren lässt, die übereinstimmen müssten.
Was geht über das Formular hinaus schief?
Ein überraschender Teil der Rechnungsfehler berührt die Prüfung überhaupt nicht. Sie sitzen in dem, was nach dem Absenden geschieht.
Die Rechnungsnummerierung ist das klassische Beispiel. Die Nummer muss eindeutig sein und stabil bleiben. Wird sie beim Absenden aus einem Zähler erzeugt, der gelesen und dann geschrieben wird, können zwei gleichzeitige Absendungen dieselbe Nummer erzeugen, und die Dublette entdeckt Wochen später ein Buchhaltungsteam. Wird sie beim Nachdruck eines Dokuments neu erzeugt, haben Sie jetzt zwei Nummern für einen Vorgang.
Wiederholte Versuche sind das zweite klassische Problem. Ein Kunde sendet ab, die Anfrage läuft in den Zeitablauf, der Kunde sendet erneut ab, und zu einer Bestellung existieren zwei Rechnungen. Die Lösung ist Idempotenz: Ein Absenden sollte einen Schlüssel tragen, und ein zweites Absenden mit demselben Schlüssel sollte das erste Ergebnis zurückgeben statt eine zweite Rechnung zu erzeugen. Das richtig zu testen bedeutet, dieselbe Absendung bewusst zweimal zu schicken und zu prüfen, dass die Rechnungszahl eins beträgt.
Das dritte ist die Platzierung der Fehlermeldung. Ein Prüfungsfehler in einem langen Rechnungsformular muss sagen, welches Feld falsch ist und warum, und er darf nicht löschen, was der Kunde bereits eingetippt hat. Testen Sie mit einem bis zum letzten Feld ausgefüllten Formular und einem früh platzierten Fehler und bestätigen Sie, dass die Meldung auf die richtige Eingabe zeigt und nichts verloren geht.
Für Entwickler: die Fallmatrix und die Testdatensätze
Bauen Sie die Matrix als Daten und nicht als Haufen handgeschriebener Tests, damit das Hinzufügen eines Landes oder Zweigs eine Zeile kostet und keine Neufassung. Jede Zeile sollte den Käufertyp, das Land, die belegten Kennungsfelder, die erwartete Pflichteigenschaft jedes Feldes und das erwartete Ergebnis tragen. Lassen Sie dann einen einzigen Testrumpf die Matrix durchlaufen, was die Zusicherungen über alle Zweige hinweg konsistent hält.
Verwenden Sie Testdatensätze, die unmissverständlich synthetisch sind. Ein Rechnungstest mit einem plausibel klingenden echten Firmennamen lädt zur Verwechslung ein, sobald ein Screenshot in einem Ticket landet, und die Kennungen eines echten Unternehmens in einer Testumgebung zu verwenden, ist ein echtes rechtliches Risiko und nicht bloß unsauber. Erzeugte Einheiten aus dem Unternehmensdaten-Generator tragen neutrale, offensichtlich erfundene Namen und Kennungen, die zu nichts auflösen – genau das, was ein Rechnungsdatensatz braucht.
Trennen Sie auch in den Testdaten die Belange. Ein Datensatz für ein inländisches Unternehmen mit Umsatzsteuernummer, einer für ein ausländisches Unternehmen ohne, einer für einen Einzelunternehmer, einer für eine Privatperson: Vier Datensätze decken die Achsen der Matrix ab und lassen sich über jedes Formular des Produkts hinweg wiederverwenden. Halten Sie sie in der Versionsverwaltung mit einem Hinweis darauf, dass sie erfunden sind, dass kein echtes Unternehmen beschrieben wird und dass sie nicht verwendet werden dürfen, um Konten zu eröffnen oder echte Dokumente auszustellen.
Zwei weitere Gewohnheiten verkürzen die Rückmeldeschleife. Prüfen Sie in der Reihenfolge, in der der Kunde das Formular ausfüllt, und nicht in der Reihenfolge, in der die Felder zufällig deklariert sind, damit der erste Fehler, auf den der Nutzer trifft, auch der erste ist, den er beheben kann. Und protokollieren Sie einen Korrelationsschlüssel für jeden Absendeversuch – denselben, der für die Idempotenz dient –, damit sich eine Meldung über doppelte Rechnungen auf das verursachende Anfragepaar zurückführen lässt.
Felder, die einzeln geprüft werden, scheitern in Kombination trotzdem, weshalb die Ausführungen zu den Umsatzsteuernummern und die zur Steuerkennung am selben Punkt enden: die Gestalt lokal prüfen, die Registrierung amtlich bestätigen und niemals das Erste für das Zweite nehmen.
Nächste Schritte
Nehmen Sie Ihre Rechnungsmaske und schreiben Sie die vier Zweige auf ein Blatt Papier, gehen Sie dann jeden mit einem synthetischen Geschäftsdatensatz durch und notieren Sie jedes Feld, das Sie blockiert. Die Zweige, die sich mit erzeugten Daten nicht abschließen lassen, sind genau die, die auch Ihre echten Geschäftskunden nicht abschließen können. Wenn die Matrix läuft, erweitern Sie sie um einen grenzüberschreitenden Fall mit einem Land, dessen Format Sie noch nie gesehen haben und prüfen Sie, ob das Formular die richtigen Dinge abfragt und nicht die vertrauten. Erzeugen Sie die Testdaten für die gesamte Matrix im Unternehmensdaten-Generator, damit kein echter Firmenname je in einem Ticket landet.