Ist scriptbasiertes Testen sinnbefreit?

Dieser Artikel stammt aus unserem Blog, der nicht mehr betreut wird. Für Neuigkeiten zu oose und interessante Inhalte zu unseren Themen, folgt uns gerne auf LinkedIn.

Wie aus einem vorherigen Blogbeitrag zu entnehmen, war ich kürzlich bei den Software Quality Days in Wien. Dieser Besuch inspirierte mich, wieder auf meiner Lieblingsfrage herumzudenken: Ist es in der heutigen Tool-Landschaft noch sinnvoll Testfälle zu scripten? Soll ein Tester überhaupt noch mit der aktuell zur Verfügung stehenden Toollandschaft in Kontakt mit dem Test-Scripten kommen? Ich spreche hier nicht von den notwendigen und leider oft vernachlässigten Unittests. Sondern vielmehr meine ich die Intergrations- und Systemtests. Je nach Größe des Testobjekts sind 10.000 Testfälle heutzutage keine Seltenheit mehr. Wenn diese alle per Script ausgeführt werden ist die Anzahl der Fehler im Testscript (Faustregel, 10 Fehler pro 1000 Zeilen Code) bald so hoch, dass die Testergebnisse an Glaubwürdigkeit verlieren. Bald stellt sich die Frage, war das Huhn oder das Ei zuerst da? Oder im Testkontext: Ist der gefundene Fehler jetzt im Testobjekt oder im Testfall?

Außerdem ist die Wartung von Testscripten ab einer gewissen Größe sehr aufwendig. Ein besonderes Argument gegen script- und für modulbasierendes Testen ist die notwendige Ausbildung der Tester. Scripte in hoher Qualität schreiben nur Entwickler mit Coder-Erfahrung. Aber dies sind nach aller Erfahrung nicht unbedingt die findigsten Tester. Vielmehr sind die Servicemitarbeiter, IT-Berater oder auch Fachabteilungen die besseren Tester. Denn sie haben die Sicht des Anwenders und sind nicht „verdorben“ mit einem Wissen über den Code. Leider können die wenigsten von ihnen Scripte schreiben. Da ist es sinnvoll ein Werkzeug zu nutzen, dass Oberflächen oder Schnittstellen scannt und daraus grafische Module macht, ohne auch nur eine Zeile Code anpassen zu müssen. So kann theoretisch jeder Tests automatisieren.  Ich stehe mit dieser Meinung nicht alleine da. Wie mir viele Testerkollegen bei Gesprächen während der Software Quality Days bestätigten.

Sehr eindrucksvoll war hierzu auch die dortige Tool Challenge. Die Herausforderung für die Kontrahenten war  „Testing Strategies in a Microservice Architecture“. Teilgenommen haben CA Technologies, Microsoft und Tricentis.  Bei der Challenge hatten die Kontrahenten sieben Minuten zur Präsentationszeit auf der Bühne. Sie sollten mit ihrem Testwerkzeug die vorbereiteten Lösungen von vorab gestellten Testaufgaben zeigen.  Tricentis mit ihrem Werkzeug TOSCA war der einzige Challenge-Teilnehmer, der rein modulbasierend testete und keine einzige Zeile Testcode zeigte. Anscheinend beeindruckte dies die Jury (das Publikum der  Software Quality Days 2017), so dass  TOSCA mit dem „Best Quality Tool Award 2017“ gekürt wurde.

[caption id="attachment_44055" align="alignnone" width="522"] Die Tool Challange-Teilnehmer (Foto: Marko Kovic, 2017)[/caption]

Aus meiner Sicht ist es heutzutage nicht mehr notwendig scriptbasiert zu testen. Ja ich halte es sogar für komplexe Systeme für gefährlich. Moderne modulbasierende Werkzeuge sind für mich die bessere Wahl.

In meiner Veranstaltung im Rahmen von open oose können Interessierte über Alternativen und Schwächen von scriptbasierter Tests am 8. Juni 2017 in Hamburg mehr erfahren und sich mit anderern austauschen.