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 Vergangenheit 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
- zum einen durch die Entwickler selbst (sog. White Box Test),
- mehr und mehr aber auch durch Personen, die nur wissen, WAS das System zu leisten hat aber nicht WIE es diese Leistung
erbringt (sog. Black Box Test).
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 sichergestellt, 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 Skriptsprachen 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 verfügbar) — ist TestNG, eine Verallgemeinerung von JUnit.
Automatisierter Black Box Test — dazu benötigt man Experten
In Kombination mit der Protokollierung von Testabdeckung (wie unter Sprich ein Machtwort beschrieben) 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 Tester 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 einsetzbar. Wirklich genutzt sieht man sie deswegen nur dort, wo große, finanzkräftige Firmen (Banken, Versicherungen, 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 automatisieren 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:
- Was genau geprüft wird, kann nur erkennen, wer den Code in allen Details nachliest.
- Die Testtreiber zu pflegen wird entsprechenden schwierig und zeitraubend.
- Mehr zu prüfen, als zunächst vorgesehen war, ist nur möglich, nachdem der gesamte Test komplett wiederholt wurde (was Stunden oder gar Tage kosten kann und manchmal gar nicht erst
möglich ist, da der entsprechende Datenbestand nicht mehr zur Verfügung steht).
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 Bedienung nur noch ein Web Browser notwendig ist (und auch kein ganz bestimmter mehr), könnte es durchaus sein, dass demnächst das Open Source Werkzeug Selenium die alten Platzhirsche und ihre jüngst hinzu gekommenen 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 vergleichbar nützlich (Jan 2011) – mehr dazu in [1].
Siehe auch: Fakten und Umfrageergebnis 2011
Source: Abstracta's Test Automation eBook (2020)
stw6410TQTW — Testautomatisierung . QuickTest . Werkzeug — News?
Mehr + B G E + S H A + More
Automation Testing for Beginners – The Ultimate Guide