menu Navigation
Ist scriptbasiertes Testen sinnbefreit?

Testen & Qualitätssicherung

Ist scriptbasiertes Testen sinnbefreit?

14. Februar 2017

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.

Die Tool Challange-Teilnehmer (Foto: Marko Kovic, 2017)

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.

2 Antworten zu “Ist scriptbasiertes Testen sinnbefreit?”

  1. Kaufe ich ein Produkt (Auto, Haus, selbst Dienstleistung), mache ich als Abnehmer einen Abnahmetest, nicht auf Modulen, sondern im Ganzen. Ich möchte als Kunde sehen, ob das was ich forderte auch umgesetzt wurde. Man kann sicherlich im kontinuierlichem Entwicklungsprozess eines jeden Produktes Prüfmarken setzen, wo man in kleinen Happen den Zustand verifiziert, aber am Ende möchte ich das ein Auto fährt und nicht nur die Reifen rollen, der Motor startet und die Türen auf- und zugehen, sondern die sollen auch in sich geschlossen ein Gesamtprodukt werden. Der Versuch alles für sich zu testen ist weder neu noch atemberaubende Raketentechnologie, aber leider müssen die Übergänge auch geprüft werden – am Ende eben das Große Ganze. Insofern ergänzen sich die Ansätze, aber man wird ohne übergreifende Ende-zu-Ende-Tests nicht erfolgreich sein.

    • Georg Haupt sagt:

      Hallo Jörg
      Um Missverständnisse zu vermeiden, möchte ich ergänzend deutlich machen, dass ich nicht von der Teststufe „Modultest“ rede, sondern von „Modulbasierten Testwerkzeugen“ für „Modulbasierte Testfälle“ . Diese Testfälle basieren auf einer Methode zum Automatisieren, die ich besonders in den Test für die Teststufen Intergrations- und Systemtests sehe. Was Deinen Einwand bezüglich der End2End-Tests betrifft, stimme ich Dir voll zu. Die dabei gestellte Problematik ist nicht unbedingt eine Tool-Frage, sondern häufig eine organisatorische und methodische. Da geht es um Verantwortlichkeiten, Fachlichkeit und (Business-)Prozesse. Besonders die letztendliche Abnahme des Kunden ist meistens frei von Testautomatisierungswerkzeugen. Ich mag übrigens dein Beispiel mit dem Auto. Danke hierfür.

Schreibe einen Kommentar

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