Der Systemtest

Die vorangegangene Episode dieser Kolumne hat gezeigt, welche verschiedenen Testarten es in der Softwareentwicklung hauptsächlich gibt, wie diese sich unterscheiden und welche Eigenschaften sie haben. Nun wäre noch der Systemtest etwas genauer zu beleuchten: sein Prinzip, wie er im Entwicklungsprozess untergebracht werden kann; woraus sich Testfälle für diese Art Test erstellen lassen; welche Möglichkeiten es gibt, diese zu verwalten; wer die Testfälle definieren sollte; wer für die Ausführung der Systemtests verantwortlich ist. Am Schluss steht noch ein kurzer Exkurs zum Mythos der ­Automatisierung von Oberflächentests.

Was ist ein Systemtest?

Beim besseren Verständnis soll das folgende Beispiel helfen: In einem Projekt werden von einem Projektmanager die Anforderungen an ein Softwaresystem ermittelt und danach von einem Entwicklungsteam in Quellcode umgesetzt. Zu Beginn legt der Projektmanager zehn Anforderungen fest, die anschließend in der ersten Iteration programmiert werden. Ist alles in Ordnung, sollten am Ende der Iteration alle Anforderungen für den Kunden im ersten Produktinkrement nutzbar sein.Wenn dies verifiziert werden soll, müssen alle Anwendungsfälle, die aus den umgesetzten Anforderungen abgeleitet werden können, auf die korrekte Ausführung hin überprüft werden. Dies würde einem ersten Systemtest entsprechen, der ­alle bisher umgesetzten Funktionen prüft – und zwar genau so, wie der Kunde es machen würde: über die Oberfläche.In der nächsten Iteration legt der Projektmanager 15 Anforderungen fest, die Entwickler setzen sie um. Wenn nun erneut ein Systemtest ausgeführt werden soll, so bezieht er sich natürlich (auch) auf diese aktuell umgesetzten Anforderungen und die damit verbundenen Anwendungsfälle. Jedoch würde das nur die neu entwickelten Funktionen absichern.Was ist, wenn die Erweiterungen bereits bestehenden Quellcode aus der ersten Iteration so verändert haben, das dieser nun nicht mehr wie gefordert funktioniert? Um das zu verhindern, werden die Anforderungen aus der ersten Iteration ebenfalls mitgetestet. In den folgenden Iterationen wird analog verfahren, und so wächst die Liste der Testfälle für den Systemtest mit jeder Runde um die neuen Testfälle der umgesetzten Anforderungen an.

Der Systemtest im Prozess

Das gezeigte Beispiel ordnet den Systemtest bereits seinem Platz im Prozess zu: nach der Entwicklung. Dabei unterscheiden sich traditionelle Prozesse nicht von agilen Vorgehen wie Scrum oder Kanban. Allerdings ist natürlich der damit verbundene Aufwand zu beachten. Während zu Beginn wenig Testfälle vorhanden sind, wächst ihre Anzahl bei (angenommener) konstanter Anforderungszahl pro Iteration linear zu diesen an. Angenommen die Iterationszeit beträgt zwei Wochen und es werden 30 Testfälle pro Iteration erstellt, so wären bereits nach einem Jahr über 600 Testfälle im Systemtest zu berücksichtigen. Folglich ist nach einigen Iterationen die aufzuwendende Zeit sehr groß und damit mit entsprechenden Kosten verbunden. Daher sollte ein Systemtest nur vor wirklich wichtigen Meilensteinen erfolgen, wie zum Beispiel vor einem Release oder einem Service-Pack.

Testfälle generieren

Das Aufnehmen und Aufschreiben von Anforderungen sind Aufgaben, die sehr sorgfältig ausgeführt werden müssen – denn schlechte Anforderungen sorgen immer für Probleme in weiteren Prozessschritten. Diesen oder einen vergleichbaren Satz hat bestimmt jeder Leser schon mehrfach in der einschlägigen Literatur gelesen. Auch der Systemtest gehört zu diesen Prozessschritten. Wie bereits erwähnt, ermittelt der Systemtest, ob die Anforderungen seit Projektbeginn vollständig und fehlerfrei umgesetzt wurden. Sind diese Anforderungen aber fehlerhaft, so können daraus keine guten Testfälle generiert werden.

So logisch diese Aussage ist, so bewusst muss man sich ihrer Konsequenz sein: Wenn über lange Zeit schlechte oder keine (auch das gibt es) Anforderungen aufgenommen oder niedergelegt wurden, können keine Testfälle daraus entstehen. Ich habe immer wieder mit Projekten zu tun, bei denen der Systemtest ein in Schieflage geratenes Projekt retten soll, jedoch ist dies aufgrund fehlender oder mangelhafter Anforderungen nicht mehr oder nur mit sehr großem Aufwand möglich.Also: Anforderungen sollten immer schriftlich festgehalten werden und immer Akzeptanzkriterien enthalten, denn diese sind im Endeffekt die Testfälle, die für eine Anforderung generiert werden.

Aufbau eines Testfalls

Genau wie Anforderungen müssen Testfälle eine feste Struktur haben und natürlich ebenfalls schriftlich niedergelegt werden. Grundsätzlich gilt, dass alle Testfälle einer Testfallliste immer voneinander unabhängig sein sollen, die Reihenfolge der Ausführung also keine Rolle spielt. Dies verhindert Seiten­effektfehler durch andere fehlerhafte Tests und ermöglicht im späteren Verlauf eine einfache Neusortierung der einzelnen Testfälle.Was bei Unit-Tests noch vergleichsweise einfach einzuhalten ist, gestaltet sich bei den Testfällen eines Systemtests meist recht schwierig. So werden beispielsweise die Testfälle „Nutzer anlegen“, „Nutzer editieren“ und „Nutzer löschen“ in einer­ Gruppe definiert. Diese drei Test­fälle müssen dabei in der gezeigten Reihenfolge ausgeführt werden, aber die Reihenfolge ist nur innerhalb dieser Gruppe wichtig.Der Aufbau eines Testfalls selbst ist meist etwas strenger geregelt und umfasst die Schritte:

• Setup
• beliebig viele Testschritte
• Teardown

Im Setup werden alle für den Test benötigten Ressourcen vorbereitet, damit die Ausgangssituation für einen Testfall immer identisch ist. Die oben erwähnte „Nutzer“-Reihenfolge könnte auch so aufgelöst werden, dass vor den Testschritten von „Nutzer editieren“ ein Datenbankskript ausgeführt werden muss, das einen zu editierenden Nutzer vor dem Test in die Datenbank einträgt.Innerhalb der Testschritte wird definiert, welche Aktionen der Tester für diesen Testfall ausführen muss und welche Eigen­schaften er dabei zu testen hat. So könnte eine Liste von Testschritten wie folgt aussehen:

• Browser öffnen
• auf www.David-Tielke.de navigieren
• auf Kontakt klicken
• als Namen Testbenutzer eingeben
• als E-Mail test@dotnetpro.de eingeben
• auf Absenden klicken
• testen: Bestätigungsseite wird aufgerufen

An dieser Stelle wird Ihnen die Detailliertheit dieses Testfalls wahrscheinlich missfallen, denn derselbe Testfall ließe sich auch mit weit weniger Testschritten beschreiben. Ich kann Ihnen hier nur dringend davon abraten, bei den Testfällen irgendwelches Detail- oder Systemwissen vorauszusetzen. Wie schon gezeigt, ist der erforderliche Aufwand für den Systemtest schon nach kurzer Entwicklungszeit enorm. Folglich wird ein Systemtest irgendwann auch mit zusätzlichen Testern ausgeführt, um die große Menge von Testfällen zu bewältigen. Diese zusätzlichen Tester sollten nur minimales Wissen benötigen, um die Tests zu absolvieren – Domänenwissen muss natürlich teilweise vorhanden sein. Bei dieser Art des Testens wird auch vom „Testen für dressierte Affen“ gesprochen [1].Der letzte Teil eines Testfalls, der Teardown, tut das Gegenteil des Setups. Dieser Schritt versetzt alle durch den Test manipulierten Zustände wieder zurück in den Ursprungszustand. Im Beispiel aus dem Abschnitt des Setups würde mit­hilfe eines Datenbankskripts der zum Bearbeiten angelegte Nutzer wieder aus der Datenbank entfernt.

Organisation und Verwaltung von Testfällen

Die Menge der Testfälle und der damit verbundenen Testschritte wächst schnell an, und so müssen diese natürlich auch ordentlich verwaltet werden. Die erste Möglichkeit dazu bietet Excel. Ja genau: Excel. Klingt unprofessionell? Vielleicht ist es das, aber es ist besser als gar nichts. Schon so oft habe ich in Projekten irgendwelche Stichpunktlisten, unstrukturierte Word-Dokumente oder vergleichbare Lösungen gesehen. Also mein Appell: Nutzen Sie zumindest dieses Tool, denn es gibt Struktur und die damit erzeugte Struktur sollte für alle verständlich sein.Besser ist es natürlich, auf eine professionelle Lösung zurückzugreifen, die das Testen direkt in den Entwicklungsprozess einbindet. Diese professionellen Tools präsentieren sich als ganze Suiten für das Testen, können Iterationen, Testpläne, Testfälle, Testschritte und vieles Weitere verwalten und ermöglichen es, das Testen im Team zu koordinieren – eine Eigenschaft, die früher oder später notwendig ist.Beispiele für solche Tools wären der Microsoft Test Manager (MTM) oder die vergleichbaren Funktionen für das manuelle Testen in der Weboberfläche des Team Foundation Server (TFS). In beiden Fällen dient der TFS als Datenspeicher und ermöglicht ein vergleichbar komfortables Arbeiten mit einem Testfall wie mit jedem anderen Work-Item im Team Founda­tion Server selbst. Auch andere Hersteller wie Hewlett Packard bieten mit HP ALM ganze Application-Lifecycle-­Management-Lösungen an, die auch ein Produkt für Systemtests enthalten. All diesen Lösungen ist gemein, dass sie nicht kostenlos sind. Eine gute Übersicht über kostenlose Alternativen hat TestLodge, ein Softwareanbieter, der sich auf Test-Tools spezialisiert hat, zusammengestellt [2].

Wer testet das System?

Etwas schwierig wird es, wenn es um die Frage geht, wer denn nun überhaupt die ausführende Kraft beim Systemtest ist. Zuerst zum einfachen Teil der Antwort: Definitiv nicht beteiligt sind die Entwickler. Der Systemtest ist eine Testart auf Ebene eines Anwenders; würde dieser Test tatsächlich von einem Entwickler ausgeführt, so wäre dies eine unglaubliche Verschwendung von Entwicklungsressourcen. Damit möchte ich nicht sagen, dass Tester in irgendeiner Weise weniger qualifiziert wären als Entwickler oder sonst von mir geringer geschätzt würden. Es geht darum, dass alle Fähigkeiten und Fertigkeiten eines Entwicklers in einem Systemtest überhaupt keine Relevanz haben, sondern andere Dinge gefordert sind. Auch wenn Entwickler diese Tätigkeit natürlich auch ausführen können, sollten sie darüber lieber mehrmals nachdenken.Hauptakteur des Systemtests ist natürlich der Tester. Aber was genau ist ein Tester? Ein Entwickler? Ein Administrator? Der Projektmanager? Ein Mitarbeiter des Fachbereichs? Ein Kunde? – Ja, alle können Tester im Systemtest sein. Allerdings ist immer zu berücksichtigen, dass Testen für fast alle der angesprochenen Rollen keine besonders beliebte Arbeit ist und neben dem Alltagsgeschäft erledigt werden muss.Und sind wir mal ganz ehrlich: Wenn die Zeit knapp wird, was wird als Erstes vernachlässigt? Genau, das Testen. Daher rate ich dringend: Wenn Sie den Systemtest ernst nehmen wollen, schaffen Sie exklusive Ressourcen für diese Tätigkeit, einen eigenen Tester, am besten noch in einer eigenen Abteilung für Qualitätssicherung. Natürlich gibt es auch kleine Teams, die müssen andere Lösungen finden und eventuell Mitarbeiter in gewissen Anteilen für das Testen fest einplanen oder eine vergleichbare Lösung finden. Eine solche Rolle benötigen Sie für einen Systemtest, denn er erfordert Planung, Koordination und sorgfältig geplante Testfälle.Weiter oben habe ich das Testen durch „dressierte Affen“ angesprochen, was hier vielleicht als Widerspruch aufgefasst werden könnte. Dem ist nicht so. Damit „dressierte Affen“ testen können, müssen zuvor die Testfälle von einer qualifizierten Testkraft geplant und ausgeführt werden.

Automation

Testfalllisten, die immer länger werden und immer mehr Ressourcen für das Ausführen der Tests benötigen – das schreit ja geradezu nach einer Automatisierung. Diesen Schrei erhören die zahlreichen am Markt verfügbaren Tools für automatische Oberflächentests, wie etwa Testcomplete, Selenium oder Coded-UI (letzteres in Visual Studio). Was eine vielversprechende Lösung zu sein scheint, führt jedoch zu immer denselben Problemen: zu einem Wartungsalbtraum und Ressourcenproblemen.

Wenn solche Oberflächentests erstellt werden müssen, so geschieht dies bei mehr Komplexität fast immer mit Programmier- oder Skriptsprachen. Für das Erstellen sind also Entwicklungskenntnisse notwendig – eine Ressource, die heutzutage nicht gerade auf Bäumen wächst. Noch viel schlimmer wird es, wenn die Software geändert wird, weil fast immer auch die Testfälle angepasst werden müssen. Folglich muss ein Entwickler die Änderung der Software programmieren und danach noch die Testfälle anpassen, bevor diese wieder ausgeführt werden können. Hat der Entwickler selbst noch Unit-Tests geschrieben, müssen diese auch noch angepasst werden.Das Resultat ist die Entwicklungsgeschwindigkeit einer Schnecke und irgendwann eine Vernachlässigung des Testens. Auch wenn Sie Entwicklungskapazitäten ohne Ende haben, mit einer langsamen Entwicklungsgeschwindigkeit leben können und Ihre (Entwickler-)Kollegen es total spannend finden: Lassen Sie es trotzdem sein! Wenn es eine Rangliste in der Softwareentwicklung geben würde, womit am meisten Geld verbrannt wird, würden die automatisierten Oberflächentests definitiv direkt hinter schlechten Anforderungen auf Platz zwei stehen.

Reduktion des Testaufwandes

Natürlich ist es in lang laufenden Projekten nahezu unmöglich, alle Testfälle der aktuellen und aller vorhergehenden Iterationen zu testen. Eine Möglichkeit, die Aufwände einzugrenzen, ist eine saubere Strukturierung der Anforderungen und eine saubere und modulare Anwendungsarchitektur. Wenn beides gegeben ist, wirken sich Änderungen oder Erweiterungen nur auf Teilbereiche der Anwendung aus. Damit sollte es für die Entwicklungsabteilung ohne Weiteres möglich sein, die Bereiche für den nächsten Systemtest zweifelsfrei zu bestimmen. Ist nicht klar, was genau entwickelt wurde, und die Anwendungsarchitektur ist ein riesiger Monolith, müssen für eine fehlerfreie Auslieferung alle Systemtestfälle ausgeführt werden.

Reduktion der Testressourcen

Das Reduzieren der Testfälle mindert die benötigten Ressourcen natürlich bereits enorm, aber die Rolle, die alle Tests ausführt, verringert das Gesamte nochmals enorm. Das Testen durch die erwähnten „dressierten Affen“ ist natürlich wesentlich günstiger als durch eine ausgebildete Entwicklungs- oder Test-Fachkraft.Wenn beispielsweise ein Webshop entwickelt wird, muss ein Tester rein theoretisch keinerlei Vorkenntnisse besitzen, um einen Testfall auszuführen. Auch wenn die Domäne einen anderen Nutzerkreis hat als ein Webshop, lassen sich dafür bestimmt auch solche Tester finden – notfalls die Anwender beim Kunden (funktioniert erstaunlich oft) oder aber der Fachbereich.

Mit meinen Kunden habe ich beispielsweise Systemtests sehr erfolgreich von Studenten ausführen lassen, während wenige hochqualifizierte Tester die Testfälle und Testpläne ausgearbeitet haben. Die Studenten können einen Großteil des Jahres dem Studium nachgehen und sind dann blockweise vor einem Release-Termin anwesend, um die Programme zu testen. Das ermöglicht nicht nur einen günstigen und sorgfältigen Systemtest, sondern bindet qualifizierte Fachkräfte bereits während ihres Studiums an das Unternehmen – oft werden diese später dann Entwickler oder „richtige“ Tester in dem Softwareprojekt.

Fazit

Der Systemtest ist eine Testmöglichkeit, die von der Struktur der entwickelten Software unabhängig ist, jedoch einiges an Vorarbeiten erfordert. Sind diese Voraussetzungen erfüllt, kann ohne Blockierung der Entwicklungsressourcen das Softwareprodukt auf Fehlerfreiheit geprüft werden. Sollten Sie diese Testart bereits einsetzen, so haben Sie alles richtig gemacht.Falls Sie noch nicht mit Systemtests arbeiten, stellen Sie sich selbst die Frage, ob Sie gerne ein ungetestetes Auto fahren oder in einem ungetesteten Flugzeug sitzen möchten. Ich weiß, es gibt die Bananensoftware, die später beim Kunden reift. Um in diesem Bild zu bleiben: Sie wissen nun, dass es die „dressierten Affen“ gibt. Die verspeisen die Bananen, und folglich kommt beim Kunden dann nur noch eins an: Software, weitestgehend fehlerfrei.Ich wünsche Ihnen viel Spaß und vor allem Erfolg mit dem Systemtest.

Fussnoten

1. Wikipedia, Monkey Testing, http://www.dotnetpro.de/SL1803DDD1
2. Top Free Test Case Management Tool List, http://www.dotnetpro.de/SL1803DDD2