RFC Blogreihe: Testautomatisierung

RFC Professionals befasst sich in den nächsten Wochen in einer Blogreihe mit der Thematik Testautomatisierung. Ziel ist es, unseren Kunden einen Überblick über die vielfältigen Methoden und Lösungsansätze für den Projektalltag zu verschaffen. Gerne nehmen wir weitere Anregungen, Vorschläge und Wünsche von Ihnen auf. Dazu können Sie gerne über den Link am Ende des jeweiligen Artikels Kontakt zu uns aufnehmen.

Teil 1: Warum Testautomatisierung?

Motivation

Der Softwaretest ist ein zentrales Element in der Qualitätssicherung von IT-Projekten, da es in der Softwareentwicklung essenziell ist, einen definierten Status bzgl. der Qualität der Software zu haben. In diesem Kontext gewinnt die automatisierte Unterstützung im Bereich des Softwaretests zunehmend an Bedeutung. Die dynamischen Veränderungen in Märkten und Wettbewerb erzeugen einen hohen Innovationsdruck bei den Unternehmen und einen damit verbundenen steigenden Zeit- und Kostendruck.

Eine Testautomatisierung sollte das Ziel einer besseren Software-Qualität durch höhere Testabdeckung haben, kann aber auch zur Beschleunigung des Entwicklungsprozesses führen. Die Einführung der Testautomatisierung in den QS-Prozess ist zunächst kein „Muss“, um Software in hoher Qualität zu produzieren, sie ist aber dennoch oft ein gutes Instrument in der Qualitätssicherung. Darum wird in vielen komplexen und großen Software-Projekten mit einer großen Anzahl von Regressionstests (wiederholbaren Tests) ein sehr großer Anteil der Tests durch automatisierte Testverfahren ausgeführt (siehe Abbildung 1).

Im Endeffekt kann sich die Entwicklungszeit sicherlich verkürzen, da früher Fehler gefunden werden können, wenn die automatisierten Tests öfter ausgeführt werden, dies sollte aber nicht der generelle Fokus sein. Was sicher ist, ist die höhere Testqualität und damit höhere Softwarequalität, wenn auf allen Teststufen entsprechend der Software und den Zielen ein passender Umfang an Testautomatisierung gewählt wird. Häufige Wiederholung manueller Tests führt zu sinkender Aufmerksamkeit der Tester. Hat eine Software einen sehr hohen Bedarf an Regressionstests und besteht die Forderung nach schnellen und zuverlässigen Tests sowie einer hohen Testabdeckung, dann ist diese Anforderung nur mit automatisierten Testen zu bewältigen, die in jedem Fall zu einem Zeitgewinn sowie einer Kostenersparnis führen. Grundsätzlich spricht ein gewisser Grad an Regressionstests für eine Testautomatisierung.

 

Abbildung 1: Motivation für Testautomatisierung

Dimensionen

Das Thema Testautomatisierung beinhaltet viele Aspekte, die durch mehrere Dimensionen kategorisiert werden können (siehe Abbildung 2):

  • Stufe

    Es gibt unterschiedliche Teststufen und damit verbunden unterschiedliche Testziele:

    • Testgegenstand beim Modultest ist die Funktionalität innerhalb der kleinsten Einheit, in der Software sinnvoll getestet werden kann (Module, Klassen, Unterprogramme, …), zu überprüfen. Testziel dieser häufig durch den Softwareentwickler durchgeführten Tests ist der Nachweis der technischen Lauffähigkeit und korrekter fachlicher (Teil-)Ergebnisse. Ein automatisierter Komponententest gibt dem Entwicklungsteam schnelles Feedback über Auswirkungen von Änderungen am Testobjekt. Er bietet z.B. bei Refactoring die Sicherheit, dass die bestehende Funktionalität nicht beeinträchtigt ist. Auch hier ist zumindest eine Teilautomatisierung (z.B. ein Smoketest nach Installation der Testumgebung) sinnvoll.
    • Ziel vom Integrationstest ist, die Robustheit und Datenintegrität zwischen Systemkomponenten über komplette Abläufe hinweg sowie die Einhaltung von Schnittstellendefinitionen zu überprüfen.
    • Der Systemtest ist die Teststufe, bei der das gesamte System gegen alle definierten Anforderungen (funktionale und nicht-funktionale) getestet wird. Neben dem Test von neuen bzw. korrigierten Funktionalitäten ist häufig auch ein Regressionstest erforderlich. Die Testautomatisierung ist in dieser Teststufe i.d.R. sehr aufwendig:
      • Fokus ist die gesamte Anwendung ggf. inklusive nachgelagerter Systeme.
      • Es ist fachliches Verständnis erforderlich.
      • Betroffene Schnittstellen sind evtl. „nur“ für Interaktion mit dem Anwender ausgelegt.
      • Vorbereitung von konsistenten Testdaten.
      • Erstellung von Testtreibern für die Simulation von Drittsystemen.
    • Im Rahmen vom Abnahmetest – auch User Acceptance Test (UAT) genannt – wird die erstellte Software anhand der Anforderungsdokumentation vom Kunden bzw. Auftraggeber abgenommen und beinhaltet meist einen End-to-End- (E2E) Test. Der erfolgreiche Abschluss dieser Teststufe ist meist Voraussetzung für die Software-Übernahme. Besonders für den System- und Abnahmetest wird das Black-Box-Verfahren angewendet. Behaviour Driven Development (BDD) kann als Weiterführung von Test Driven Development angesehen werden und beinhaltet eine automatisierte Überprüfung der definierten Akzeptanzkriterien. Die Testfälle sollten dabei in einer Form definiert werden, die einerseits fachlich verständlich und andererseits automatisiert durchführbar sind.
  • Methodik

    Beim White-Box-Test wird die Implementierung der zu testenden Applikation berücksichtigt. Mit Hilfe der Code-Analyse können interne Strukturen, Datenflüsse und Zustände im Rahmen der Testdurchführung überprüft werden. Beim Black-Box-Test dagegen werden „nur“ die zur Verfügung gestellten öffentlichen Schnittstellen und Services der bereitgestellten Applikation getestet und das korrekte fachliche Verhalten verifiziert.

  • Schicht

    Tests auf der User-Interface-Schicht (UI) interagieren mit der Benutzeroberfläche einer Applikation und simulieren damit die Aktivitäten des End-Users. Tests auf der Application Programming Interface- (API) bzw. Middleware-Schicht interagieren mit den öffentlichen Schnittstellen von Web- und Application-Servern und simulieren oft interne Geschäftsabläufe. Tests auf der Datenbank– bzw. Storage-Schicht greifen direkt auf die Datenhaltungsschicht zu, um komplexe Datentransformations- und ETL Prozesse möglichst ungefiltert und direkt zu testen.

  • Fokus

    Der Fokus beim funktionalen Test liegt auf der Verifizierung des korrekten fachlichen Produktverhaltens. Der Fokus beim nicht-funktionalen Test liegt auf Sicherstellung weiterer betriebs- und nutzungsspezifische Aspekte wie Stabilität, Performance, Lastverhalten, Effizienz, Benutzerfreundlichkeit und Sicherheit in Hinblick auf die Erfüllung der Anforderungen bzw. Akzeptanzkriterien.

Abbildung 2: Dimensionen der Testautomatisierung

Testautomatisierungspyramide

Besonders im Zuge der agilen Entwicklung, kann auf Testautomatisierung kaum verzichtet werden. Die meisten Best Practices und Erfahrungsberichte von Agile-Experten sind sich einig, dass gerade bei den kurzen Iterationen automatisierte Tests eine äußerst sinnvolle Ergänzung sind. Tests laufen z.B. über Nacht und können automatisch nach jedem Code-Check-in inklusive eines automatischen Build-Prozesses („Continuous Integration“) ablaufen. Beim „Continuous Integration“ sollten nach dem Code-Check-in ein automatischer Software-Build und Installationsprozess laufen. Anschließende Unit Tests geben den Entwicklern in kürzester Zeit Feedback über die grundlegende Qualität der Software. Auch andere Teststufen wie Integrationstests und Systemtests können automatisch ablaufen und schnelles Feedback geben.

Im Kontext der Testautomatisierung – insbesondere im agilen Umfeld – hat sich der Begriff der Testautomatisierungs-Pyramide (siehe Abbildung 3) etabliert, die im Wesentlichen die wichtigsten Test-Stufen abbildet, wobei die Form der Pyramide gleichzeitig die Schwerpunkte für die Testautomatisierung im konkreten Projekt als Teil der Testautomatisierungs-Strategie festlegt. Hierbei ist zu beachten, dass die Zahl der automatisierten GUI-Tests deutlich kleiner sein sollte als die der Unit-Tests. Dies soll das Diagramm der Agilen Test Pyramide verdeutlichen. Die folgende zwei Formen dieser Pyramide sind in der Praxis häufig anzutreffen:

Abbildung 3: Formen der Testautomatisierungs-Pyramide

In der agilen Software-Entwicklung wird ein besonderes Augenmerk auf die „wohlgeformte“ Pyramide (linke Grafik) mit stark ausgeprägten Unit- und Integrationstests und darauf abgestimmten reduzierten End-to-End Systemtests gelegt. Auf diese Weise werden schnelle Feedback-Schleifen mit kurzen Testlaufzeiten und hoher Robustheit begünstigt.

Regressionstest

Automatische Tests, die nach dem Einspielen einer Änderung unerwünschte Auswirkungen auf andere Funktionen abtesten, werden Regressionstests genannt. Unter einem Regressionstest werden in der Softwaretechnik die Wiederholung von Testfällen verstanden, die sicherstellen, dass Modifikationen in bereits getesteten Teilen der Software keine neuen Fehler („Regressionen“) verursachen. Solche Modifikationen entstehen regelmäßig z. B. aufgrund der Pflege, Änderung und Korrektur von Software. Der Regressionstest gehört zu den dynamischen Testtechniken. Aufgrund des Wiederholungscharakters und der Häufigkeit dieser Wiederholungen ist es sinnvoll, wenn für Regressionstests eine Testautomatisierung zum Einsatz kommt. In der Praxis steht der Begriff des Regressionstests für die reine Wiederholung von Testfällen. Die Testfälle selbst müssen spezifiziert und mit einem Soll-Ergebnis versehen sein, welches mit dem Ist-Ergebnis eines Testfalls verglichen wird. Ein direkter Bezug auf die Ergebnisse eines vorherigen Testdurchlaufs findet nicht statt.

Im Gegensatz dazu kann der Regressionstest auch in die Gruppe der diversifizierenden Tests eingeordnet werden. Hierbei werden die verschiedenen Versionen einer Software gegeneinander getestet. Es findet kein Vergleich zwischen den Testergebnissen und der Spezifikation, sondern ein Vergleich der Testergebnisse der verschiedenen Versionen statt. Ein Testfall gilt als erfolgreich absolviert, wenn die Ausgaben der unterschiedlichen Versionen (i.d.R. aktuelle Version versus Vorgängerversion) identisch sind. Im Gegensatz zu den funktions- und strukturorientierten Testmethoden wird kein Vollständigkeitskriterium spezifiziert. Die notwendigen Testdaten werden mittels einer der anderen Techniken per Zufall oder Aufzeichnung einer Benutzer-Session erstellt. Die diversifizierenden Tests umgehen damit die oft aufwändige Beurteilung der Testergebnisse anhand der Spezifikation. Dies birgt die Gefahr, dass ein Fehler, der in den zu vergleichenden Versionen das gleiche Ergebnis produziert, nicht erkannt wird. Auf Grund des einfachen Vergleichens lassen sich solche Tests sehr gut automatisieren.

Regressionstests machen Software bezüglich ihrer Qualität erst messbar und zeigen mögliche Nebeneffekte von vorgenommenen Änderungen auf und dienen als direkte Rückkopplung für Entwickler und Tester. Diese sind meistens nicht in der Lage, das Gesamtsoftwaresystem bzgl. der Erkennung von Nebeneffekten und Folgefehlern zu überblicken. Die Testautomatisierung liefert demnach eine Metrik: die Anzahl erfolgreicher Testfälle pro Testlauf. Wenn sich eine Software (z.B. in der Anfangsphase des Entwicklungsprozesses) sehr stark und ständig ändert, kann eine Testautomatisierung nicht die beste Wahl sein, da der Aufwand der Wartung und Anpassung der Testautomatisierung dann zu hoch sein könnte.

Fazit

Das Thema Testautomatisierung hat in den letzten Jahren massiv an Aufmerksamkeit gewonnen und ist eines der zentralen, aktuellen (und sicher auch zukünftigen) Themen im Bereich der Softwareentwicklung. Der wesentlichste Treiber für die ansteigende Bedeutung der Testautomatisierung ist der kontinuierlich steigende Kostendruck. Ein hohes Qualitätsbewusstsein und die zunehmende Verbreitung von agiler Softwareentwicklung unterstreichen die Wichtigkeit eines umfassenden und regelmäßig durchzuführenden Regressionstest. Für ein erfolgreiches agiles Projekt ist der effiziente Einsatz von Testautomatisierung eine zwingende Voraussetzung.

Die Standardisierung von Schnittstellen der zu testenden Systeme erleichtert die Einführung von automatisierten Tests erheblich. Da aber oft nicht ausschließlich standardisierte Schnittstellen für den Test verwendet werden können (z.B. Altsysteme wie Host-Anwendungen), kann die Komplexität der Automatisierung erheblich erhöht werden. Bis zur industriellen Fertigung von Software und insbesondere bis zur industriellen Testautomatisierung ist es noch ein weiter Weg. Wichtig ist aber dabei, die Grenzen der Automatisierung anzuerkennen. Der manuelle Test muss und wird weiterhin seine Daseinsberechtigung haben.

Ausblick

Im zweiten Teil der RFC Blogreihe zum Thema Testautomatisierung geht es um den Testprozess. Wir beschäftigen uns dabei mit den Aktivitäten in den einzelnen Projektphasen und den Möglichkeiten der Automatisierung.

_________________________________________________________________

Übersicht aller Blogs unserer RFC Blogreihe Agiles Projektmanagement

Blog 1: Einleitung der Blogreihe: Testautomatisierung – Was ist die Motivation für den Einsatz von automatisierten Testverfahren?

Blog 2: Einleitung der Blogreihe: Testautomatisierung – Was ist die Motivation für den Einsatz von automatisierten Testverfahren?

Gefällt ihnen unsere Blogreihe, haben sie Anmerkungen oder neue Ideen? Dann freuen wir uns, wenn sie uns kontaktieren.

Steffen Hahn

Steffen Hahn

Hans Willhoeft

Hans Willhöft

Quelle: Basiswissen Testautomatisierung, dpunkt.verlag