In unseren Projekten sind wir immer da, wo gerade der größte Bedarf besteht. Das bedeutet, dass wir auch mal außerhalb unserer Kernthemen Big Picture Engineering, Digital Design und Software-Architektur unterwegs sind. Beispielsweise in der Qualitätssicherung. Hier haben wir mittlerweile das eine oder andere Test-Konzept geschrieben, Testpläne erstellt und auch jede Menge Tests durchgeführt.

Ja, ich weiß, Tests konzipieren und manuell durchführen ist nicht super agile und sexy, aber wir begleiten immer wieder die Entwicklung und Einführung von Systemen in Projekten mit Auftraggeber-Auftragnehmer-Situationen, und diese Systeme müssen nun einmal umfassend geprüft und abgenommen werden. Und Ihr glaubt nicht, wie viele Dinge man auf diese Weise findet.

Mit gut gemachten Systemtests kann man aber auch in weniger regulierten Settings, während des normalen Entwicklungszyklus, beispielsweise nach Fertigstellung eines wichtigen Inkrements, in einfacher Weise die Qualität der Umsetzung absichern. Und die erstellten Testpläne können dann auch als Basis für eine weitere Automatisierung dienen. Die grundsätzlichen Gedanken zur Konzeption der Testfälle muss man sich nämlich ohnehin machen.

Daher zeigen wir Euch heute mal, wie wir Testpläne in einfacher Weise erstellen, die wir zur Konzeption und Durchführung von Systemtests verwenden.

Unsere Testpläne sind grundsätzlich tabellenorientiert. Wir arbeiten für die Erstellung typischerweise mit Microsoft Excel, weil es die Zusammenarbeit mit unseren Kunden erleichtert, aber jedes andere Werkzeug mit dem man Tabellen erstellen kann, ist genauso gut geeignet. Das folgende Bild zeigt ein Beispiel.

Wie Ihr seht, unterteilen sich die Testpläne in zwei Teile: die Testfall-Spezifikation und die Durchführung. Die Spezifikation definiert den Testfall und legt fest, was zu tun ist, welche Daten zu verwenden sind und welches Ergebnis erwartet wird. Die Testfall-Durchführung dokumentiert einen Durchlauf durch den Testplan, der von einer Tester:in zu einem Zeitpunkt durchgeführt wird, zusammen mit den erzielten Ergebnissen. Folglich muss eine Testplan-Spezifikation nur einmal erstellt werden, die Testfall-Durchführung wird pro Durchlauf erstellt, also wahrscheinlich viele Male.

Hier eine kurze Erläuterung zu den einzelnen Feldern:

Testfall-Spezifikation

• ID: Jeder einzelne Testfall sollte einen eindeutigen Bezeichner haben, so dass man sich darauf beziehen kann, beispielsweise in Tickets.
• Kategorie: Eine einfache Möglichkeit um Testfälle zu gruppieren und für mehr Struktur zu sorgen
• Beschreibung: Eine kurze Beschreibung als Name, aus der das Ziel und Inhalt des Tests hervorgeht
• Pfad: Die Art des Testpfades (siehe unten)
• Vorbedingung: Alle Faktoren, die gegeben sein müssen um den Testfall durchführen zu können
• Schritte/Eingabe/Daten: Eine konkrete und genaue Auflistung aller Schritte, die bei der Testfall-Durchführung ausgeführt werden müssen, inklusive der zu verwendenden Daten. Dies sollte so genau sein, dass eine andere Tester:in weiß, was zu tun ist.
• Erwartetes Ergebnis: Alle Ergebnisse, die vom System als Reaktion auf die Eingaben erwartet werden. Dies kann mehrere, unterschiedliche Dinge enthalten.

Testfall-Durchführung

• Datum: Das Datum der Durchführung
• Tester: Name der Person, die den Test durchführt
• Ergebnis: Das tatsächliche Ergebnis, das die Tester:in nach Ausführung der vorgegebenen Schritte erhalten hat. Im Erfolgsfall kann man die Dokumentation auf so etwas wie „Wie erwartet“ verkürzen. Im Fehlerfall sollten hier alle Ergebnisse aufgelistet sein, die einen Aufschluss über die Ursache des Fehlers geben.
• Erfolg/Fehler: Eine eindeutige Kennzeichnung als Erfolg oder Fehler
• Ticket: Eine Angabe oder Verlinkung zur Aufgabe, welche die Behebung des Fehlers zum Ziel hat
• Kommentare: Alle sonstigen wichtigen Informationen der Tester:in

Darüber hinaus fügen wir je nach Projekt-Situation und Bedarf noch weitere Felder hinzu.

Testpfade

Im Bild sind exemplarisch zwei Testfälle gezeigt; einer der den Happy Path (siehe Pfad „HP“) abbildet und einer, der einen Angry Path (siehe Pfad „AP“), also den Umgang fehlerhaften Eingaben abbildet (hier ist nicht das Ergebnis der Testdurchführung, sondern die Testspezifikation gemeint). Es ist extrem wichtig, nicht nur den Happy Case abzutesten, sondern eben auch den Umgang mit Fehleingaben, Ausfällen, etc., ansonsten gehen einem ziemlich sicher Fehler im System durch die Lappen.

Neben den genannten, gibt es noch zahlreiche weitere Testpfade. Hier eine Auswahl in der Übersicht:

• Happy Path: Alle möglichen Erfolgsszenarien
• Angry Path: Die wichtigsten Fehler-Testfälle, beispielsweise Fehleingaben
• Scary Path: Alle Hochrisiko-Testfälle, die richtig was kaputt machen könnten
• Delinquent Path: Jemand versucht absichtlich eine Funktionalität zu missbrauchen
• Stressful Path: Das System soll an die Belastungsgrenze gebracht werden

Eine gute Übersicht über die unterschiedlichen Test-Pfade gibt Kevin Sookocheff auf seiner Webseite.

Die zwei beispielhaften Testfälle zeigen bei der Durchführung auch zwei unterschiedliche Ergebnisse in der Test-Durchführung (türkis), nämlich einen Erfolg (das System bildet den Happy Path korrekt ab) und einen festgestellten Fehler (das System verhindert eine Fehleingabe nicht wie erwartet). Wenn Ihr Fehler findet, dokumentiert diese am besten so, dass dieser auch reproduziert werden kann und klar ist, was bei Euch als Ergebnis herausgekommen ist. Wurden die zugrundeliegenden Fehler behoben, könnt Ihr einen neuen Durchlauf machen. Diesen Zyklus macht Ihr so lange, bis Ihr genug Konfidenz aufgebaut habt, dass keine schwerwiegenden Fehler mehr verbleiben.

Fazit

In diesem Artikel haben wir Euch gezeigt, wie wir mit einfachen Mitteln Testpläne erzeugen, um die Qualität auf Gesamtsystem-Ebene zu untersuchen. Wir erhalten damit eine klare Struktur, Wiederholbarkeit und Unterstüzung, nichts wichtiges zu vergessen. Wir schaffen damit auch die Grundlage für eine weitergehende Automatisierung.

Wir hoffen, wir konnten Euch einen hilfreichen Eindruck vermitteln. Lasst uns gerne mal ein Feedback da, wie Ihr Systemtests in Euren Projekten so typischerweise durchführt.