Der Systemtest ist eine sehr spannende Teststufe. Unittest und Integrationstest fokussieren sich mehr auf die inneren Aspekte der Applikation. Im Systemtest geht es viel mehr um die Außensicht. Die Software wird zum ersten Mal als Blackbox betrachtet und gegen die fachlichen Anforderungen geprüft. Auch diese spielen jetzt eine viel größere Rolle als noch in den unteren Teststufen. Das führt dazu, dass auch fachliche Mitarbeiter, spätere Anwender oder Kunden hier schon aktiv mittesten können. Dieser Perspektivwechsel bringt aber auch ganz neue Herausforderungen mit sich. Aus diesem Grund habe ich dem Thema ein ganzes Buch gewidmet: “Der Systemtest – Von den Anforderungen zum Qualitätsnachweis”
Das ISTQB definiert Systemtest als “eine Teststufe mit dem Schwerpunkt zu verifizieren, dass ein System als Ganzes die spezifizierten Anforderungen erfüllt.”
Der große Unterschied zu vorherigen Teststufen ist, dass hier das integrierte Gesamtsystem gegen die Anforderungen getestet wird. Das System wird wie eine Blackbox von außen betrachtet.
Als Testbasis für den Systemtest dienen meistens funktionale und nicht-funktionale Anforderungen. Doch auch User-Stories, Geschäftsprozesse oder Anwenderdokumentationen eignen sich. Fehlt diese Basis oder ist sie lückenhaft, können Anwender oder Fachabteilungen befragt werden. Auch das alte System kann als Testorakel dienen, z.B. bei Systemablösen oder Migrationen.
Fachliche Anforderungen liegen häufig in Textform vor. Wie kann man aus diesen Anforderungen nun Testfälle erstellen? In der Praxis hat sich dazu eine Kombination aus zwei Vorgehen bewährt:
Dieses Zusammenspiel bringt ein gutes Set an Testfällen für den Systemtest. In der Praxis ist es häufig so, dass bei der Testfallerstellung für den Systemtest viele Fragen auftauchen. Will ich einen konkreten Testfall erstellen, müssen die Sätze in den Dokumenten auch konkret sein. Und das ist häufig nicht der Fall: “Das System muss performant sein”, “Die Applikation sollte leicht zu bedienen sein”, “Der Button sollte grün sein”. Auch Lücken werden hier schnell deutlich. All diese Rückfragen müssen geklärt werden.
Die geklärten Punkte müssen natürlich auch dem Entwickler bekannt sein. Daher ist es umso wichtiger, frühzeitig mit der Testfallerstellung zu beginnen.
Das Testobjekt für den Systemtest ist das integrierte Gesamtsystem. D.h. die Software oder Applikation wird über die Oberfläche oder die Schnittstellen geprüft. Für eine abschließende Bewertung muss das System daher auch vollständig sein.
Die Integration mit anderen Systemen ist nicht Teil des Systemtests, sondern wird häufig als Systemintegrationstest bezeichnet.
Das Ziel des Systemtests ist es, zu prüfen, ob die funktionalen und nicht-funktionalen Anforderungen an die Applikation erfüllt und ausreichend umgesetzt sind. In der Praxis lauern hier einige Herausforderungen, die frühzeitig bedacht werden müssen (siehe auch typische Probleme).
Hier lauert ebenfalls eine Schwierigkeit. Für eine valide Aussage zum Systemtest ist es notwendig, dass die Testumgebung der Produktivumgebung entspricht. Oder dieser zumindest sehr ähnlich ist. Gerade wenn es um nicht-funktionale Testarten wie Performancetest oder Zuverlässigkeit geht. Und diese doppelte Infrastruktur kann teuer sein. Hier zeigt sich auch ein massiver Vorteil virtueller Maschinen und Cloud-Lösungen. Ist das spätere produktive System eine parametrisierte virtuelle Maschine, lässt sich diese für den Systemtest auch kostengünstig klonen.
Testdatenmanagement wird ab der Systemteststufe deutlich anspruchsvoller. Unit- und Integrationstests hantieren meist noch mit Testdaten im lokalen Umfeld des Testfalls. Beim Systemtest können aber deutlich umfangreichere Testdatensets vonnöten sein, z.B. angelegte Verträge, historische Daten, verknüpfte Datensätze, etc. Hier haben sich in der Praxis zwei Verfahren etabliert:
Lange Zeit war es um die Testautomatisierung beim Systemtest dürftig bestellt. Tests unter der Haube, wie Unit- und Integrationstests, waren allein schon durch die Entwicklungsnähe gut mit Tools versorgt. Gerade mit Aufkommen der agilen Projekte hat es hier aber auf Systemtestebene einen massiven Schub gegeben. Sowohl bei Testautomatisierungslösungen für Oberflächentests, Webtests und auch Schnittstellentests. Hier gibt es heute ein Fülle an Möglichkeiten. Wie man Testautomatisierung hier konkret implementiert, habe ich im Buch “Basiswissen Testautomatisierung” zusammengefasst.
Das Modell der Teststufen kommt aus einer Zeit lange vor agilen Projekten. Es wird deswegen in Scrum und Co gerne ignoriert. Aber schauen wir mal genauer auf das Modell, dann sehen wir, wie wichtig die Ideen und Aspekte der Teststufen natürlich auch in agilen Kontexten sind. So wie beim Systemtest: Das System von außen testen. Testdaten vorbereiten. Testfälle überlegen. Und natürlich Testautomatisierung aufsetzen.
In diesem Kontext taucht auch immer wieder das Modell der Testpyramide auf. Es liefert eine ähnliche Perspektive wie die Teststufen.
Daher lohnt sich der Blick durch die Systemtest-Brille auch in agiler Softwareentwicklung. Die Intention des Systemtests lässt sich übertragen, und das Relevante davon im eigenen Projekt nutzen.
Wenn ich mir die Projekte der letzten Jahre ansehe, treten beim Systemtest immer wieder die gleichen Herausforderungen im Alltag auf:
In der Praxis ist der Systemtest oft die Teststufe, mit der begonnen wird. Das kommt daher, dass diese Teststufe für Fachabteilungen, Tester und Management leichter greifbar ist. Man nehme die Anforderungen und prüfe das System dagegen. Das ist leichter verständlich als auf Codeebene irgendwelche kleinteiligen Unittests zu verargumentieren.
In dieser Situation zeigt der Systemtest dann aber leider auch oft die Lücken der anderen Teststufen. Instabilitäten und inkonsistentes Verhalten der Software deuten dann darauf hin, dass es im Unterbau an Robustheit fehlt. Durch die späte Testbarkeit beim Systemtest kommen diese Erkenntnisse leider sehr spät.
Daher ist es besonders wichtig auch die anderen Teststufen zu etablieren. Nur ein Systemtest ist zu wenig.
Auch wenn die Durchführung des Systemtests erst recht spät möglich ist, lassen sich z.B. die Testfälle schon entwerfen, bevor die erste Zeile Code geschrieben ist. Fragen und Unklarheiten werden somit frühzeitig bereinigt.