Eine Unternehmenssoftware abnehmen: welche Tests vor dem täglichen Einsatz nötig sind

Die Abnahme einer Verwaltungssoftware scheitert fast immer auf dieselbe Weise: Man ruft die künftigen Nutzer zusammen, sagt „probiert es aus“, und die Personen probieren die Dinge, die sie schon können. Die Software besteht den Test. Dann, am ersten echten Arbeitstag, kommt die Bestellung, die nach dem Versand storniert werden muss, und das hatte niemand getestet.

Abnehmen bedeutet, vorher aufzuschreiben, was geschehen soll, und dann zu prüfen, ob es geschieht. Der Unterschied zwischen beiden Dingen steckt ganz im Wort „vorher“.

Ein Testszenario ist nicht „das Programm ausprobieren“

Ein Szenario hat vier Teile, und fehlt einer, ist der Test weder wiederholbar noch diskutierbar.

• Die Ausgangsdaten: welcher Kunde, welche Bestellung, welches Lager, mit welchen Werten.
• Die Rolle: wer den Test durchführt und mit welchen Berechtigungen.
• Die Schritte: was getan wird, in der Reihenfolge, in der es getan wird.
• Das erwartete Ergebnis: was am Ende zutreffen muss, geschrieben vor der Durchführung.

Das erwartete Ergebnis ist der Teil, der übersprungen wird, und der einzige, der zählt. Ohne ihn endet der Test mit „es scheint zu funktionieren“, was kein Ergebnis, sondern ein Eindruck ist und sich weder bestreiten noch bestätigen lässt.

Ein Testplan: der Auftrag

Illustratives Beispiel für ein Modul zur Auftragsverwaltung. Die Tests sind so gewählt, dass sie die drei Arten abdecken, die immer gebraucht werden: den Normalfall, die Ausnahme und das, was verhindert werden muss.

Die letzten drei Zeilen sind die, die immer vergessen werden. Ein System wird auch danach beurteilt, was es ablehnt, und die Ablehnung muss verständlich sein: Ein ohne Erklärung blockierter Vorgang löst dieselben Anrufe aus wie ein Fehler.

Die Tests, an die niemand denkt

• Die nicht autorisierten Vorgänge, wirklich mit der eingeschränkten Benutzerin oder dem eingeschränkten Benutzer getestet und nicht nur in der Berechtigungstabelle nachgelesen. Auch Ausdrucke und Exporte müssen geprüft werden, über die vertrauliche Daten häufiger austreten als über die Bildschirme.
• Fehlerhafte Daten: Namen mit Apostrophen, sehr lange Adressen, Beträge von null, große Anhänge, doppelte Zeilen.
• Die Unterbrechungen: die Verbindung, die mitten in einem Speichervorgang abbricht, zwei Personen, die denselben Datensatz ändern, derselbe Vorgang, der doppelt gesendet wird.
• Die Integrationen, wenn das andere System nicht antwortet: was die Nutzerin oder der Nutzer sieht, was offen bleibt, was geschieht, wenn das andere System wieder verfügbar ist.
• Die Abschlussmomente, falls die Software sie besonders behandelt.

Mängel einstufen statt sie nur aufzulisten

Eine Liste mit sechzig Meldungen ohne Einstufung blockiert das Projekt: Niemand weiß, wo anzufangen ist, und jede Besprechung wird zu einer Verhandlung. Vier vorab vereinbarte Kategorien genügen.

• Blockierend: verhindert das Arbeiten, und es gibt keinen Ausweichweg. Muss vor der Einführung behoben werden.
• Schwerwiegend: Man kann arbeiten, aber mit einem Umweg oder Fehlerrisiko. Muss vor der Einführung oder unmittelbar danach behoben werden, mit einem festen Termin.
• Gering: Ärgernis, Form, unklarer Text. Wird gesammelt und gebündelt behoben.
• Neue Anfrage: kein Mangel, sondern eine Funktion, die nicht vorgesehen war. Muss als solche erkannt und gesondert bewertet werden.

Die Unterscheidung zwischen der letzten Kategorie und den anderen ist die, die das Projekt rettet. Eine fehlende Funktion mit einem Mangel zu verwechseln, verschiebt die Kosten auf die Entwicklung und den Termin auf alle und verwandelt die Abnahme in eine endlose Baustelle.

Korrekturen prüfen, ohne den Rest zu beschädigen

Jede Korrektur muss von der Person geprüft werden, die die Meldung erstellt hat, nicht von der, die sie behoben hat, indem der ursprüngliche Test wiederholt wird und nicht ein ähnlicher. Gleichzeitig muss eine begrenzte Gruppe von Tests auf den wichtigsten Wegen wiederholt werden: Korrekturen bringen Nebenwirkungen mit sich, und das ist normal.

Es empfiehlt sich, während der Abnahme eine begrenzte Anzahl von Lieferungen festzulegen — zum Beispiel eine pro Woche — statt fortlaufend zu korrigieren. Ein System zu testen, das sich unter den Händen verändert, macht jedes Ergebnis unzuverlässig und jede Meldung anfechtbar.

Einführung, Support und Rückweg

1. Entscheiden Sie, wie gestartet wird: alle zusammen, eine Abteilung nach der anderen, oder parallel zum bisherigen System für einen festgelegten Zeitraum. Der Parallelbetrieb ist sicher, verdoppelt aber die Arbeit, deshalb braucht er eine schriftliche Frist.
2. Legen Sie fest, wer in den ersten Tagen antwortet, wo man sich meldet und in welcher Zeit geantwortet wird. Die ersten zwei Wochen erzeugen mehr Fragen als der ganze Rest des Jahres.
3. Legen Sie den Rückweg fest: unter welchen Bedingungen zurückgekehrt wird, wer das entscheidet und was mit den zwischenzeitlich erfassten Daten geschieht. Gibt es diese Antwort nicht, ist die Einführung ein Glücksspiel.

Was dieser Leitfaden nicht abdeckt

Hier geht es um die Abnahme von Prozessen mit vorhersehbarem Ergebnis: Bei einer bestimmten Eingabe muss das System genau eine Sache tun, immer dieselbe. Die Prüfung von Systemen, die probabilistisch antworten — Assistenten und automatische Antwortsysteme, bei denen dieselbe Frage unterschiedliche Antworten erhalten kann und Korrektheit eine Frage des Grades ist — erfordert eine andere Methode, die an anderer Stelle behandelt wird. Auch die Wahl dessen, was in die erste Version einer Verwaltungssoftware kommt, hat einen eigenen Leitfaden.