Testautomatisierung wird erst möglich wenn die Grundlagen der Qualitätssicherung stimmen

„Das kann man nicht automatisieren.“

In vielen Softwareprojekten fällt dieser Satz früher oder später. Besonders in historisch gewachsenen Systemlandschaften mit komplexer Fachlichkeit, zahlreichen Abhängigkeiten und regulatorischen Anforderungen entsteht der Eindruck, dass Testautomatisierung an ihre Grenzen stößt.

Diese Überzeugung herrschte auch in einem komplexen Projekt der öffentlichen Verwaltung. Über Jahre wurde davon ausgegangen, dass eine umfassende Testautomatisierung nicht realisierbar sei wegen komplexen Oracle-Systemlandschaft, anspruchsvollen fachlichen Prozessen, sensiblen Steuerdaten und eine über viele Jahre gewachsene Architektur.

Bei einer genaueren Analyse wurde jedoch klar, dass nicht die Technologie die Testautomatisierung verhindert, sondern die eigentlichen Hindernisse lagen in den Grundlagen der Qualitätssicherung.

Vor Projektbeginn existierten weder eine dokumentierte Teststrategie noch systematisch aufgebaute Regressionstests. Testfälle waren nur eingeschränkt nachvollziehbar, ein Großteil des Testwissens befand sich bei einzelnen Personen und die Qualitätssicherung war überwiegend reaktiv organisiert.

Erst nachdem diese Grundlagen geschaffen wurden, stellte sich heraus, dass viele der zuvor als „nicht automatisierbar“ eingestuften Szenarien durchaus automatisiert werden konnten.

Welche Erkenntnisse haben zu diesem Wandel geführt?

1. Es gab keine Teststrategie

Zu Beginn des Projekts existierte keine dokumentierte Teststrategie. Tests wurden zwar durchgeführt, jedoch fehlte ein gemeinsames Verständnis darüber, welche Qualitätsziele verfolgt werden, welche Testarten eingesetzt werden und welche Rolle die Qualitätssicherung im Entwicklungsprozess einnimmt.

Die Auswahl der Testfälle beruhte häufig auf Erfahrungswissen einzelner Beteiligter. Welche Bereiche bei einem Release geprüft wurden, hing oftmals von der Erfahrung der Testenden ab und weniger von einem definierten Vorgehen.

Ohne eine klare Teststrategie entsteht Qualität reaktiv statt planbar. Eine langfristige und reproduzierbare Qualitätssicherung lässt sich auf dieser Grundlage kaum aufbauen.

Im Projekt wurde deshalb zunächst eine Teststrategie entwickelt. Sie definierte Verantwortlichkeiten, schuf Transparenz über die Testprozesse und legte den Grundstein für den späteren Aufbau automatisierter Regressionstests.

Erkenntnis: Testautomatisierung benötigt eine klare Richtung. Ohne Teststrategie fehlt die Grundlage für nachhaltige Automatisierung.

 

2. Regressionstests waren nicht definiert

Ein weiteres Hindernis bestand darin, dass es keine systematisch aufgebauten Regressionstests gab.

Viele Prüfungen wurden zwar regelmäßig durchgeführt, jedoch war nicht eindeutig festgelegt, welche Testfälle bei jedem Release wiederholt werden mussten. Dadurch hing die Testdurchführung stark vom Erfahrungswissen einzelner Personen ab.

Automatisierung setzt voraus, dass bekannt ist, welche Abläufe regelmäßig und reproduzierbar geprüft werden sollen. Ohne definierte Regressionstests gibt es letztlich nichts, was sinnvoll automatisiert werden kann.

Im Projekt wurden daher zunächst wiederkehrende und geschäftskritische Testfälle identifiziert, strukturiert beschrieben und schrittweise als Grundlage für die Testautomatisierung aufgebaut.

Erkenntnis: Testautomatisierung setzt voraus, dass bekannt ist, welche Testfälle bei jedem Release zuverlässig geprüft werden müssen.

 

3. Testwissen war nicht dokumentiert

Ein erheblicher Teil des Testwissens befand sich ausschließlich in den Köpfen einzelner Mitarbeitender.

Dieses Wissen war über Jahre gewachsen und wurde nur selten dokumentiert. Fiel eine erfahrene Person aus oder wechselte das Projekt, gingen wichtige Informationen verloren oder mussten mühsam neu erarbeitet werden.

Für Testautomatisierung ist das ein grundlegendes Problem.

Automatisierte Tests können nur das abbilden, was nachvollziehbar beschrieben wurde. Solange Testwissen ausschließlich auf Erfahrung basiert, lässt es sich weder reproduzierbar durchführen noch automatisieren.

Deshalb wurde im Projekt ein besonderer Schwerpunkt darauf gelegt, Testfälle und fachliches Wissen systematisch zu dokumentieren und für das gesamte Team verfügbar zu machen.

Erkenntnis: Nicht Wissen lässt sich automatisieren – sondern dokumentierte Prozesse.

 

4. Testdesign wurde Bestandteil der Qualitätssicherung

Zu Projektbeginn bestand die Auffassung, dass Testfälle überwiegend durch den Fachbereich geliefert werden müssten. Die Aufgabe der Qualitätssicherung bestand hauptsächlich darin, diese Tests auszuführen.

Ein strukturierter Testdesign-Prozess war kaum etabliert. Dadurch wurden Risiken nicht immer frühzeitig erkannt und Potenziale für eine spätere Automatisierung blieben ungenutzt.

Im Verlauf des Projekts änderte sich dieses Verständnis grundlegend.

Die Qualitätssicherung wurde frühzeitig eingebunden und übernahm eine aktive Rolle bei der Entwicklung von Testfällen. Gemeinsam mit Entwicklung und Fachbereich wurden Risiken bewertet, Testfälle entwickelt und Regressionstests definiert.

Dadurch entstanden Tests, die fachlich nachvollziehbar, wiederholbar und langfristig automatisierbar waren.

Erkenntnis: Je früher die Qualitätssicherung in den Entwicklungsprozess eingebunden wird, desto besser lassen sich Testfälle strukturieren und später automatisieren.

Fazit Die Voraussetzungen machten den Unterschied

Nachdem Teststrategie, Regressionstests, dokumentiertes Testwissen und ein strukturierter Testdesign-Prozess aufgebaut worden waren, konnte erstmals systematisch bewertet werden, welche Testfälle sich tatsächlich automatisieren lassen.

Dabei zeigte sich, dass viele Prozesse, die zuvor als „nicht automatisierbar“ galten, durchaus automatisiert werden konnten. Möglich wurde dies durch den Aufbau der organisatorischen und methodischen Grundlagen, auf denen eine strukturierte Qualitätssicherung aufbaut.

Mit dem Aufbau dieser Grundlagen konnten nicht nur automatisierte Regressionstests etabliert werden. Gleichzeitig wurden wichtige Voraussetzungen geschaffen für

  • eine nachhaltige Qualitätssicherung,
  • eine höhere Release-Sicherheit,
  • ein skalierbares Testing,
  • eine geringere Abhängigkeit von Einzelpersonen sowie
  • langfristige Kosteneinsparungen.

Wer Testautomatisierung in einem komplexen Projekt einführen möchte, sollte deshalb zunächst die Frage stellen:

Sind die Voraussetzungen geschaffen, um Testprozesse systematisch zu analysieren und nachhaltig zu automatisieren?

Weiterführende Unterstützung:

Eine fundierte Teststrategie und systematische QA-Grundlagen sind die zwingende Voraussetzung, um Automatisierungsprojekte auch in komplexen Systemlandschaften erfolgreich und wartbar umzusetzen. Wir unterstützen Sie dabei, diese Strukturen nachhaltig in Ihrem Unternehmen zu etablieren:

Waldemar Siebert

Test-Enthusiast
at SimplyTest GmbH, Nürnberg

Hier finden Sie weitere interessante Fachartikel:

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert