Systemtest

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”

Definition Systemtest

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.

Testbasis

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.

Testfallerstellung für Systemtests

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:

• Strukturierte Testfallerstellung: Mit systematischen Methoden wie Äquivalenzklassenbildung, Grenzwertanalyse, Entscheidungstabellen, etc. lassen sich Anforderungen strukturiert analysieren und Testfälle daraus ableiten. Dies stellt sicher, dass die nötige Breite und Testfalllabdeckung der Anforderungen gegeben ist.
• Erfahrungsbasierte Testfallerstellung: Anforderungsdokumente können nie das System in seiner Gesamtheit komplett darstellen. Dafür gibt es zu viel Transferverlust von der Idee hin zur aufgeschriebenen Anforderung. D.h. hier ist es immer ratsam, Testfälle anhand der eigenen Erfahrung und auch der Erwartung der Anwender zu definieren.

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.

Testobjekt

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.

Testziele des Systemtests

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).

Testumgebung für Systemtests

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.

Testdaten

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:

• Echte Daten: Wenn vorhanden, lassen sich z.B. aus produktiven Systemen Datenabzüge nutzen, um diese als Testdaten für den Systemtest zu nutzen. Gerade in der Wartungsphase wird das gerne genutzt. Wo nötig, werden diese ggf. anonymisiert. Aber immer in dem Bewusstsein, damit auch die Daten zu verändern. Der Vorteil bei echten Daten liegt natürlich in der Praxistauglichkeit, aber auch darin, dass manchmal Daten und Konstellationen vorkommen, die über Anforderungen und Testfälle nicht abgedeckt sind.
• Synthetische Testdaten: Echte Daten decken bei Weitem nicht alle Möglichkeiten, Corner-Cases und Kombinationen ab. Daher ist es auch hier ratsam, konkrete synthetische Daten zu generieren, um besondere Fälle zu prüfen: Geburtstag am 29.2. oder Postleitzahlen mit 0 beginnend sind hier Klassiker.

Testautomatisierung des Systemtests

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.

Systemtest in agilen Projekten

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.

Typische Probleme

Wenn ich mir die Projekte der letzten Jahre ansehe, treten beim Systemtest immer wieder die gleichen Herausforderungen im Alltag auf:

• Nicht-funktionale Anforderungen werden nicht bedacht. Zum Systemtest gehört nicht nur die Fachlichkeit. Nicht-funktionale Anforderungen müssen hier ebenfalls berücksichtigt werden, wie z.B. Usability-Tests, Performance- oder Zuverlässigkeits-Tests.
• Der Systemtest ist die erste Teststufe, die komplett auf den Anforderungen beruht. Und von den Anforderungen zum Code und zu den Testfällen gibt es zwangsläufig einen Medienbruch. Aus natürlicher Sprache wird Technik. Während die Entwicklung die Lücken kreativ füllen kann, kann ein Tester das nicht, um Testfälle zu erstellen. Hier muss immer wieder am gleichen Zielbild gearbeitet werden.

Systemtest in der Praxis

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.