Praktisches & Grundsätzliches zur Informatik

Test Automation, Software Test Methodik, Selenium, HP QuickTest

Testautomatisierung — Stand der Kunst 2011

Zwischen 30 und 40 Prozent aller Kosten für Software-Entwicklung sind Kosten für Test. Es lohnt sich also, darüber nachzudenken, wie man derart viel Geld wirkungsvoller einsetzt als das in der Ver­gan­genheit geschah – und heute immer noch geschieht, da Systemarchitekten i.A. viel zu wenig Vorgaben machen, optimale Testbarkeit entstehender Software zu garantieren (!).

Ganz prinzipiell wird Software getestet

xUnit – der Standard für White Box Test

Spätestens seitdem Java-Programmierer das Test Framework JUnit erfanden, gilt es als Stand der Kunst, dass aller Test, den noch die Entwickler selbst durchführen, in einheitlicher, standardisierter Form mit Teil des Produktes wird und so im Rahmen jedes Build-Prozesses stets neu komplett abzulaufen in der Lage ist.

Agile Software-Entwicklung etwa wird erst hierdurch wirklich praktikabel. Insbesondere aber ist so sicher­gestellt, dass aufgrund von Änderungen unbeabsichtigt neu entstehende Fehler zum frühest möglichen Zeitpunkt entdeckt und beseitigt werden. Inzwischen wird diese Technik keineswegs nur in Java-basierter Software angewandt: JUnit ist längst in zahlreiche andere Programmiersprachen portiert (sogar in Skript­sprachen wie etwa JavaScript) und ist als NUnit auch für .NET verfügbar.

Vom Konzept her noch flexibler einsetzbar — bislang aber wenig verbreitet (und derzeit nur für Java ver­fügbar) — ist TestNG, eine Verallge­meinerung von JUnit.


Automatisierter Black Box Test — dazu benötigt man Experten

In Kombination mit der Protokollierung von Testabdeckung (wie unter Sprich ein Machtwort beschrie­ben) kann White Box Test heute in jedem Projekt optimal organisiert sein: Der Weg ist da, auch wenn der Wille, ihn konsequent zu gehen, oft noch fehlt.



Black Box Test ähnlich zu standardisieren ist weit schwieriger: Das liegt zum einen daran, dass die Tes­ter hier nicht unbedingt erfahrene Programmierer sind, ist aber vor allem auch deswegen so, weil ein Großteil der zu testenden Funktionalität vom Tester nur über Dialogschnittstellen abrufbar ist.

Werkzeuge wie z.B. HP Quick Test versprechen hier schon seit vielen Jahren Abhilfe, sind aber zu teuer, sind entsprechend wenig verbreitet und sind vor allem nur durch wirkliche Testexperten sinnvoll einsetz­bar. Wirklich genutzt sieht man sie deswegen nur dort, wo große, finanzkräftige Firmen (Banken, Ver­sicherungen, Autohersteller u.Ä.) eigene, regressionsfähige Testsuiten über Jahre hinweg benötigen und entsprechend zu pflegen haben.

Verschlimmert wird die Sache dadurch, dass die Hersteller solcher Werkzeuge – im Bestreben, so ein Produkt als Wunderwaffe anpreisen zu können – methodisch in eine Richtung steuern, die sich als Sackgasse herausstellt, sobald man mehr als nicht nur völlig trivialen Test zu auto­matisieren versucht. Insbesondere ihr Ratschlag, den Code, der als Testtreiber fungiert, zu vermischen mit dem Code, der SOLL/IST-Vergleich zu machen hat, weist in eine völlig falsche Richtung. Nachteile dieses Ansatzes sind nämlich mindestens:

Vor Auswahl und Einführung von Werkzeug für Testautomatisierung sollte man genau unter­su­chen, wie einfach oder schwierig es werden könnte, einmal existierende Testtreiber neuen Versionen der zu testen­den Software anzupassen. Mit anderen Worten: Wie einfach oder schwierig wird es sein, Test­treiber, die stecken bleiben, so zu modifizieren, dass sie erneut klaglos arbeiten?



HP QuickTest zeigt sehr schön, wie Werkzeug erfolgreich so gestaltet wird, solche Arbeiten gut zu unterstützen. Ranorex, ein erst kürzlich entstandener Konkurrent von HP QuickTest, steuert da eher in die falsche Richtung (der die Testtreiber darstellende Code ist – anders als bei HP QuickTest – wirklich nur durch geübte Programmierer beherrschbar).

Da klassische GUI Clients heute zunehmend durch Dialogschnittstellen ersetzt werden, für deren Bedie­nung nur noch ein Web Browser notwendig ist (und auch kein ganz bestimmter mehr), könnte es durch­aus sein, dass demnächst das Open Source Werkzeug Selenium die alten Platzhirsche und ihre jüngst hinzu ge­kommenen Nachahmer vom Markt verdrängen wird. Nachteil von Selenium scheint einzig und allein die Tatsache, dass es nicht in der Lage ist, klassisch implementierte GUI Clients zu unterstützen.

Meine Empfehlung daher: Wer Werkzeug für Testautomatisierung sucht, der evaluiere besonders genau Sahi oder Selenium einerseits und HP QuickTest andererseits. Kein anderes Produkt scheint vergleich­bar nützlich (Jan 2011) – mehr dazu in [1].

Siehe auch: Fakten und Umfrageergebnis 2011





Testautomatisierung in 2011 (Deutschland)


Test Approaches
Source: Abstracta's Test Automation eBook (2016)
Wissenswertes zu "HP QuickTest, Selenium, Software Test Methodik, Test Automation" zusammengestellt durch Gebhard Greiter.
tags: QuickTest1gegreit Selenium1gegreit Werkzeug1gegreit