Testautomatisierung: Kritik an die blinde Automatsierungswut
Automatisch ausgeführte Checks sind von Anfang an automatisch, nicht automatisiert. Echtes Testen jedoch ist bildend, explorativ und kreativ. Ein Überführen vom einen in den anderen Bereich ist a priori nicht sinnvoll.
Testautomatisierung kritisch betrachtet.
Testautomatisierung im herkömmlichen Sinne versteht sich leider als Stütze vom “manuellen Testen“, in dem man Tests, die mehrmals ausgeführt werden mussten, durch Automaten ausführen lässt und so vermeintlich wiederholbar werden lässt und Personal einspart.
Dabei nimmt man oft – insbesondere bei Legacy Projekten – ohne besseres Wissen schwergewichtige Werkzeuge zur Hand, die alles tun, was vom menschlichen Clickthrough herrührt – und vergisst oder ahnt nicht, dass dabei etliche Probleme erst entstehen.
- Solche Tests sind in der Regel Langläufer, deren Zweck mit schnellen Units auch erfüllt werden könnte, ohne den ganzen Applikationskontext hochzufahren.
- Sie hinken dem Entwicklungsprozess hinterher, werden unkompatibel zur Funktionalität und müssen neu geschrieben werden, ohne dass sie Fehler finden.
- Sie spiegeln nicht reproduzierbare oder nicht deterministische Verhalten (flakey Tests). Dadurch sind Testläufe selten bis nie grün.
- Sie sind äusserst redundant und jeder neue Test trägt immer weniger zu einer echten Abdeckung bei.
- Sie dokumentieren alte Bugs, die nie wieder kommen und exponenzieren die Menge an Tests, obwohl Bugs eigentlich nicht wieder kommen, wenn man versionieren kann. Der Glaube, man müsse für jeden gefundenen Fehler einen funktionalen Test schreiben, ist so etwas wie der Eisengehalt vom Spinat.
Das alles führt dazu, dass man die notwendige Schnelligkeit nicht erreicht, ja zum Teil die Ausführung länger geht als die Zeit zwischen zwei Releases.
Professionelles Test Management ist sich dessen bewusst und erspart den Projekten Lizenz-, Herstellungs- und Betriebskosten.
Gute Tester:innen sind Menschen mit Fachverständnis von Business Analysierenden oder Superusern und mit Erfindergeist, um dort zu stören, wo man es bisher nicht erwartet hatte. Das echte Testing ist eine lernende, evolutionäre und kreative Disziplin und kann (noch?) nicht von Automaten erledigt werden. Auch nicht von künstlichen Intelligenzen, obwohl man letztere durchaus als Werkzeug einsetzen soll, wo es hilfreich ist.
Wo – also – automatisieren?
Automatische Tests (oder besser: Checks) sind von Anfang an automatisch. Hier ein Auszug der Möglichkeiten:
-
Unit Tests: Diese werden von den Entwickelnden in der Umsetzung erstellt, vorzugsweise mit Test Driven Development (TDD) und Abdeckungskriterien. Sie sind schnell und können beim Kompilieren oder spätestens beim Rückführen der Änderungen des Programms ausgeführt werden, ohne dass es Wartezeiten erzeugt.
-
Funktionale Tests: Im Optimalfall basieren sie auf Use Cases oder Business Cases. Sie sind soweit abstrahierbar, dass man daraus direkt Tests generieren kann. Sie sind Schnittstellen basiert und bringen erwartete Ausgaben mit sich, die man mit dem Code versionieren kann. Respektive, man lässt sie gegen mehrere Versionen laufen und prüft damit die getroffenen Annahmen und die Rückwärtskompatibilität. In der Grundfunktion sind diese Tests nicht integrativ.
Durch Ein- und Ausschalten der Umsysteme wird ermöglicht, deren Simulation (Mock Ups) über die mehrfache Versionierung zu speichern. -
Generative Tests: Der Automat kann dort am besten helfen, wo der Mensch sich besser mit intelligenteren Aufgaben beschäftigt. Durch systematische, teilzufällige Proben (z.B. mit Quickcheck) werden Fehler aufgedeckt, die man durch überlegtes Handeln allein nicht gefunden hatte.
Zusammenfassend erzeugt das Nutzen von big time Testing Tools mit tausenden von „Langläufern“ eine falsche Sicherheit bei den Verantwortlichen. Eine Abdeckung wird nicht erreicht, die Redundanz der Tests ist sehr hoch. Die Tests sind dabei selten grün, werden dadurch bald nicht mehr beachtet und die Qualität wird am Ende verschlechtert. Neue Fehler werden nicht bemerkt, da man keine Veränderung feststellt und schnell zum Resignieren neigt: „Ach, das war gestern schon rot“. Zusätzlich frustriert es alle Mitarbeitenden, was das Problem verstärkt. Testen wird immer noch mehr zur unbeliebten Disziplin, die man lieber delegiert, statt integriert. Wichtige Grundlagen für agiles Arbeiten sind dadurch vernichtet. Die Qualität wird verunmöglicht.
Bei Unklarheiten oder Fragen zum Thema sind wir selbstverständlich jederzeit für ein Gespräch verfügbar.
Autor
Danilo Biella, Agile & Quality Professional
E-Mail: danilo.biella@spf-consulting.ch
LinkedIn: https://www.linkedin.com/in/danilobiella/
