Abnahmetests für Software von einem Lieferanten

Sie haben eine Agentur, einen Auftragnehmer oder ein Team im Ausland dafür bezahlt, etwas zu bauen. Es ist geliefert. Die Demo lief gut.

Und nun: Woher wissen Sie, dass es funktioniert?

Das ist eine unbequeme Lage, in der sich sehr viele Organisationen befinden und über die wenige sprechen. Sie haben keinen Quellcode, oder Rechte daran, die Sie nicht nutzen können. Intern könnte ihn niemand lesen, wenn Sie ihn hätten. Der Lieferant sagt, es sei fertig, und wartet auf die Abnahme — und Ihr einziger Beleg ist eine Vorführung, die er selbst gesteuert hat.

Warum der übliche Rat hier nicht greift

Übliche Testempfehlungen setzen voraus, dass Ihnen der Code gehört und Sie Menschen beschäftigen, die ihn verstehen. Schreiben Sie Unit-Tests, erhöhen Sie die Abdeckung, hängen Sie es in CI. Nichts davon steht hier zur Verfügung, und es einer Auftraggeberin in dieser Lage vorzuschlagen, hilft nicht.

Was Sie haben, ist wertvoller, als es aussieht: Sie wissen, was die Software tun soll. Sie haben es spezifiziert. Genau dieses Wissen verlangen Abnahmetests, und es ist Wissen, das der Lieferant nicht an Ihrer Stelle beisteuern kann.

Schreiben Sie die Kriterien vor der Lieferung

Das Wirksamste, was Sie tun können, kostet nichts und geschieht, bevor eine Zeile Code existiert: Schreiben Sie Ihre Abnahmekriterien als konkrete Abläufe.

Ein brauchbares Kriterium benennt drei Dinge — einen Ausgangszustand, eine Handlung und ein beobachtbares Ergebnis:

Als Kundin mit einem Artikel im Warenkorb erzeugt der Abschluss des Kaufs mit einer gültigen Karte eine Bestellbestätigungs-E-Mail und eine Bestellung, die in der Kontohistorie sichtbar ist.

Vergleichen Sie das mit dem, was die meisten Verträge tatsächlich enthalten: „Der Bestellvorgang muss korrekt funktionieren.“ Das Erste kann jemand prüfen, der auf einen Bildschirm schaut. Das Zweite ist ein Streit, der darauf wartet zu passieren.

Die Probe für ein gutes Kriterium ist einfach. Wenn Sie es nicht durch einen Blick auf die Anwendung prüfen können, ist es kein Abnahmekriterium. Es mag eine berechtigte Anforderung sein — Leistungsziele, Sicherheitsniveau, Codequalität — aber sie braucht eine andere Art der Prüfung und gehört getrennt behandelt.

Fünfzehn bis dreißig davon decken die meisten Auftragsprojekte ab. Hängen Sie sie an den Vertrag.

Prüfen Sie selbst

Akzeptieren Sie eine Vorführung nicht als Beleg. Eine Demo ist ein einstudierter Weg durch die Software, vorgeführt von denen, die sie gebaut haben, auf Daten, die sie ausgewählt haben. Sie sagt Ihnen, dass der glückliche Pfad an einem Dienstag funktioniert.

Führen Sie die Kriterien selbst aus, gegen die gelieferte Anwendung, auf einem System, das Sie kontrollieren, mit Daten, die Sie gewählt haben. Weil End-to-End-Testen über die Oberfläche arbeitet, braucht das keinen Zugriff auf den Code und keine Mitwirkung außer einer URL und Zugangsdaten.

Drei Dinge, die zu prüfen sich lohnt und die Lieferanten selten vorführen:

• Die unglücklichen Pfade. Eine abgelaufene Karte. Eine doppelte E-Mail-Adresse. Ein leer gelassenes Pflichtfeld. Hier ist beauftragte Software am schwächsten, weil die Spezifikation hier am dünnsten war.
• Berechtigungen. Melden Sie sich als eine Kundin an und versuchen Sie, an die Daten einer anderen zu kommen. Das ist der Fehler, der zu einer Meldepflicht wird.
• Das zweite Mal. Führen Sie denselben Ablauf zweimal aus. Software, die einen sauberen Zustand voraussetzt, bricht häufig bei der Wiederholung.

Behalten Sie die Tests nach der Abnahme

Abnahmetests werden meist als Ereignis behandelt: prüfen, unterschreiben, weitermachen. Damit verschenkt man den größten Teil des Werts.

Die Kriterien, die Sie geschrieben haben, sind eine Regressionssuite. Bleibt der Lieferant im Wartungsvertrag, beschreiben sie jetzt, was bei künftiger Arbeit nicht brechen darf. Bleibt er nicht, und die Software liegt zwei Jahre unberührt, ist die Suite der Weg, auf dem Sie erfahren, dass ein Browser-Update, ein abgelaufenes Zertifikat oder ein gewechselter Zahlungsdienstleister etwas kaputt gemacht hat, das niemand beobachtet hat.

Die Kosten, sie laufen zu lassen, sind gering. Die Kosten, von einer Kundin von einem zwei Monate alten Ausfall zu erfahren, sind es nicht.

Wenn etwas fehlschlägt

Melden Sie Fehlschläge als Reproduktionen, nicht als Meinungen. „Der Kaufabschluss ist kaputt“ ist bestreitbar; ein konkreter Ablauf mit konkreten Daten, zweimal ausgeführt, mit festgehaltenem Ergebnis ist es nicht. Es verschiebt das Gespräch von der Frage, ob es ein Problem gibt, zu der Frage, wann es behoben wird.

Das ist in einer Geschäftsbeziehung mehr wert, als es klingt. Lieferanten handeln in der Regel nicht in böser Absicht — sie arbeiten nach einer Spezifikation, die vager war, als beide Seiten bemerkt haben. Konkrete, reproduzierbare Kriterien nehmen die Mehrdeutigkeit heraus, die aus einer Lieferung einen Streit macht.

Werkzeuge, die zu dieser Lage passen

Die Anforderung ist ungewöhnlich und verengt das Feld deutlich: Das Werkzeug muss gegen eine Anwendung laufen, die Sie nicht verändern können, ohne Zugriff auf den Code, ohne Build-Pipeline und vermutlich ohne Entwicklerinnen.

Das streicht codebasierte Frameworks, alles, was CI voraussetzt, und die meisten QA-Plattformen. Übrig bleiben Werkzeuge, die nur eine URL und eine Beschreibung des Ablaufs brauchen: Testmode, testRigor, Rainforest QA, Functionize und Autify.

Das Verfassen in normaler Sprache zählt hier mehr als sonst, aus einem konkreten Grund: Die Person, die weiß, was beauftragt wurde, ist diejenige, die die Spezifikation geschrieben hat, nicht eine Entwicklerin. Wenn das Schreiben des Tests Code erfordert, sitzen Wissen und Fähigkeit in verschiedenen Köpfen, und bei der Übergabe geht etwas verloren.

Siehe die Übersicht der KI-Testwerkzeuge für das gesamte Feld, sortiert danach, was jedes von Ihnen braucht, und Regressionstests ohne QA-Team dazu, was Sie nach der Abnahme mit der Suite machen.