Die Fallstricke der Testautomatisierung
Automatisierung, in dünne Scheiben geschnitten
Es ist unbestreitbar, dass Testautomatisierung das Softwaretesten revolutioniert hat. Und das auch gerade rechtzeitig! In der heutigen Welt der extrem verteilten, containerisierten und kontinuierlich aktualisierten Dienste wäre sinnvolles Softwaretesten ohne sie unmöglich.
Wir können uns glücklich schätzen, dass uns so viele ausgeklügelte automatisierte Testwerkzeuge zur Verfügung stehen. Und, wenn ich das hinzufügen darf, die gut ausgebildeten QA-Ingenieure, die sie zum Nutzen aller im Entwicklungsprozess einsetzen.
Aus irgendeinem Grund neigt unsere Branche jedoch dazu, bedeutsame Fortschritte wie diese immer wieder auf Modeerscheinungen zu reduzieren, und diese Moden dann in sinnentleerte Worthülsen und Slogans zu verwandeln, die von oberen Managern, Experten und Beratern stereotyp wiederholt werden, die nur eine Ausrede suchen, um nicht weiter über das Problem nachdenken zu müssen. Oder um schnell Geld zu verdienen.
Want more from The CTO Club?
Create a free account to finish this piece and join a community of CTOs and engineering leaders sharing real-world frameworks, tools, and insights for designing, deploying, and scaling AI-driven technology.
Have an account? Log In
So ist es auch mit den Durchbrüchen in der Testautomatisierung, die schnell in die reduktive Erzählung eingebunden werden: „Wir müssen einfach alle unsere Tests automatisieren! Sofort! Dann sind alle unsere Testprobleme gelöst!“
Das ist nicht nur eine schreckliche Idee – selbst wenn sie von Leuten vorgeschlagen würde, die das Problem wirklich ernst nehmen und nicht nur vermeiden wollen. Es ist auch deshalb gefährlich, weil diese Erzählung die Möglichkeit verhindert, gründlich darüber nachzudenken, wie Automatisierung sinnvoll in Testinitiativen integriert werden kann, und damit deren Scheitern praktisch vorprogrammiert. Was all den Menschen (auch Kunden) gegenüber unfair ist, die von ihrem Erfolg abhängen.
In dieser Hinsicht übernimmt die Testautomatisierung nur ein spezielles Beispiel für den generellen Umgang mit SQA durch diejenigen, die sie nicht verstehen – und auch nicht verstehen wollen. Sie wird wie eine Massenware behandelt und nicht als komplexe Expertise. Deshalb hören Leute im QA-Bereich immer wieder von oberen Managern: „Wir brauchen einfach mehr QA!“, als gäbe es irgendwo einen Software-Feinkostladen, wo man QA dünn geschnitten pro Kilo bestellen kann.
Deshalb ist das neue Mantra jetzt: „Wir brauchen einfach mehr Automatisierung!“, ohne dass darüber nachgedacht wird, was das im Kontext Ihrer Softwareentwicklung eigentlich bedeuten würde. Diese Diskussion verstärkt die Dysfunktion in Ihrer Organisation – sie beseitigt sie nicht.
Dem Trend zu solchen Modeerscheinungen direkt entgegenzutreten, ist so aussichtslos, wie zu versuchen, den Sonnenauf- oder -untergang aufzuhalten. Der beste Weg des Widerstands ist es, den Vizepräsidenten und Beratern einfach freundlich zuzunicken, dann an den Arbeitsplatz zurückzugehen, selbst die richtige Herangehensweise für die Automatisierung zu finden und diese Ideen später als brillante Einfälle der eigenen Chefs zu präsentieren. Aber vermutlich haben Sie diese Lektion bei anderen Themen schon längst gelernt.
Also tun wir das doch einfach. Hier ist meine Liste der Fallstricke bei der Implementierung von Testautomatisierung – und wie man sie umgeht, damit die Automatisierung ihr großes Potenzial bei Ihren eigenen Testinitiativen entfalten kann.
Automatisierungsumfang
Die wichtigste Frage zu Beginn ist, wo automatisierte Tests im Testprozess am meisten Nutzen – sprich: Mehrwert – bringen. Sich die Zeit dafür zu nehmen, erspart Ihnen später viele, viele Kopfschmerzen.
Im Kern geht es bei der Beantwortung dieser Frage darum, wie viel Ihrer Tests automatisiert werden sollten – und wie viel weiterhin manuell ablaufen muss. Das mag all jene überraschen, die unaufhörlich dem „Evangelium der vollständigen Automatisierung“ ausgesetzt sind. Aber schenken Sie diesem Unsinn keinerlei Aufmerksamkeit – diese Menschen wissen schlicht nicht, wovon sie sprechen.
Alle Tests zu automatisieren – sofern das überhaupt möglich wäre – wäre eine katastrophale Entscheidung, die unweigerlich im Desaster für Ihre Testinitiativen enden müsste.
Es gibt großartige Dinge, die Automatisierung leisten kann und die manuelles Testen entweder gar nicht oder zumindest nicht so schnell und wiederholt leisten kann. Aber das Gegenteil stimmt ebenso. Es gibt Dinge, die ausschließlich durch manuelles Testen sinnvoll möglich sind – daran scheitert die Automatisierung. Was sind diese Dinge in beiden Fällen?
Der Bereich, in dem manuelles Testen den automatisierten Ansätzen überlegen ist, ist schlicht der menschliche Faktor. Den Vorteil, den ein echter Mensch mit Geduld und tiefgehender Explorationsarbeit beim Testen mitbringt, kann kein automatisiertes System ersetzen. Und ich spreche hier nicht nur von der Fehlersuche.
Fehler finden kann jeder – Kunden machen das kostenlos ständig. Der Mehrwert, den ein professioneller QA einbringt, ist das intuitive Gespür dafür, wie man eine Software kaputt bekommt – insbesondere dafür, wie Software von Nutzern auf unerwartete Weisen eingesetzt werden kann, für die sie nie entworfen wurde – was oftmals mit katastrophalen Folgen passiert.
Ein weiterer Vorteil des manuellen Testens besteht darin, dass ein Tester, der einen Bug findet, sofort damit beginnen kann, dessen Umfang und Schwere einzuschätzen. Also zu klären, in welchen Testkontexten (Betriebssysteme, Workflows, Interaktionen und Abhängigkeiten zwischen Diensten) er konkret auftritt und in welchen nicht.
Automatisierte Testscripte können das nur sehr schlecht abbilden – und genau diese Information ist aus Sicht der Softwareentwickler entscheidend, um Fehler zu diagnostizieren und zu beheben. Ein Fehlerbericht, der bloß sagt: „Ich habe dies gemacht und das ist passiert“, ist für sie nutzlos.
Manuelles Testen ist tatsächlich viel zeiteffizienter, um diese Informationen bereitzustellen. Da es zudem interaktiv abläuft und direkt im Austausch mit der Entwicklung steht, ist das Feedback auch viel informationsreicher für die Ursachenanalyse.
Ja, Virginia, manuelles Testen ist nicht immer der ineffizienteste und zeitaufwendigste Weg, um Fehler zu finden, zu analysieren, zu beheben – und deren Behebung zu überprüfen (oder eben nicht).
Ein klarer Vorteil der Automatisierung liegt jedoch beim kontinuierlichen Testen von Betriebszeit und Stabilität – insbesondere in verteilten Systemen. Dies ist heute umso zentraler, da wir uns in einer Entwicklungsumgebung mit Continuous Integration und Deployment in verteilte Systeme in Echtzeit bewegen.
Automatisierung ist auch effizienter beim sogenannten „Massentesten“, bei dem Sie eine riesige Matrix aus Tausenden von Systemzuständen und deren Variablen abdecken müssen, um herauszufinden, ob einer davon komplett fehlerhaft ist oder das System zum Absturz bringen kann.
Die Faustregel, die Sie zur Orientierung verwenden sollten, um manuelle oder automatisierte Tests zu priorisieren, lautet:
Manuelles Testen ist in der Regel für die Erstprüfung neuer Funktionen und Fähigkeiten vorzuziehen. Automatisiertes Testen ist eindeutig am besten geeignet für kontinuierliches allgemeines Regressionstesten sowie für Last- und Performancetests.
Im Laufe des Lebenszyklus eines Produkts oder einer Dienstleistung sollte das Testen derselben Fähigkeit von manuell zu automatisiert übergehen. Es handelt sich um ein Kontinuum im Fähigkeitslebenszyklus. Es ist keine chinesische Mauer, die nie überschritten wird, bei der jede Seite nicht weiß, was auf der anderen geschieht. Die Standardannahme sollte sein, dass das, was heute manuell getestet wird, im Laufe der Zeit in automatisierte Tests überführt werden sollte.
Qualifikationen für Automatisierungsingenieure
Es ist vielleicht unvermeidlich, dass bei der Einstellung von Ingenieuren für automatisierte Tests die wichtigsten Qualifikationen die Kenntnisse der Bewerbenden in (a) den Automatisierungstools, die sie verwenden sollen, und (b) den in diesen Tools eingesetzten Testskriptsprachen sind.
Wenn Sie sich jedoch ausschließlich auf diese Qualifikationen konzentrieren, begehen Sie einen großen Fehler. Sie sind notwendig, aber bei weitem nicht ausreichend für die Rolle des Automatisierungsingenieurs.
Warum? Aus dem einfachen Grund, dass das Wissen, wie man ein Automatisierungstool benutzt und wie man Skripte in seiner Sprache erstellt, genau nichts über das Verständnis für Qualitätssicherung an sich aussagt.
Leider sehe ich fast nie Automatisierungsingenieure mit dieser Ausbildung oder diesem Hintergrund. Sie werden schlicht deshalb eingestellt, weil sie wahre Skriptkünstler sind, nicht weil sie über Erfahrung im Entwerfen effektiver und aussagekräftiger Tests verfügen.
Diese Qualifikationen sind eigentlich wichtiger als die Erfahrung mit den Automatisierungstools und -sprachen, die sie verwenden werden. Diese können sie bei Bedarf leicht erlernen. Aber jemanden auszubilden, Tests zu entwerfen und deren Ergebnisse zu interpretieren, erfordert sehr viel Zeit und Mühe.
Tatsächlich wäre es oft besser, einfach eine erfahrene Analysefachkraft aus dem eigenen Team zu nehmen und sie auf die notwendigen Automatisierungswerkzeuge zu schulen. Diese Automatisierungsfähigkeiten sind heute schließlich eine Ware. Die Intuition und das Gespür eines erfahrenen Testers hingegen nicht.
Ignoranz zu automatisieren bedeutet nur, dass man Unwissenheit schneller und reproduzierbarer erhält und damit die Effizienz untergräbt, die man sich eigentlich von der Testautomatisierung erhofft.
Standards für die Automatisierungsgestaltung
Es liegt auf der Hand, dass Sie, wenn Sie ein groß angelegtes Testautomatisierungsprojekt beginnen, zunächst allgemeine Standards definieren müssen, denen jede Automatisierung genügen muss, um im Testbetrieb akzeptiert zu werden. Doch wie bei vielen Selbstverständlichkeiten scheint es weniger gesunden Menschenverstand zu geben, als man erwarten würde.
Das sollten diese Standards abdecken.
Verständlichkeit
Eines der frustrierenden Rätsel der Softwareentwicklung ist, wie handwerklich sie letztlich ist. Es ist leider gar nicht selten, von einem Softwareentwickler zu hören, dass er einen Fehler nicht beheben kann, weil er den betreffenden Code nicht selbst geschrieben hat. Es ist, als sei der Code eines anderen Entwicklers in einer fremden Sprache verfasst, die er nicht versteht.
Das ist leider ebenso häufig im Bereich Testautomatisierung der Fall. Ich kann kaum zählen, wie oft mir ein QS-Ingenieur gesagt hat, dass er ein Automatisierungsskript für ein wichtiges Produkt-Upgrade nicht aktualisieren kann, weil er es nicht geschrieben hat und es daher nicht versteht. Und der ursprüngliche Verfasser hat das Unternehmen vor zwei Monaten verlassen.
Das ist im Falle automatisierter Testscripte sogar noch weniger akzeptabel als bei neuer Software, die Logik implementiert, anstatt bloß Abläufe abzubilden. Dennoch ist das verblüffend verbreitet.
Das bedeutet: Bevor Sie ein ganzes Dutzend Qualitätsingenieure einstellen und sie hunderte von Automatisierungsskripten programmieren lassen, sollten Sie zuerst allgemeine Verständlichkeitsstandards definieren und schulen.
Es muss zur Anforderung werden, dass alle Testskripte für alle Ihre QA-Ingenieure verständlich sind, damit Sie sich nicht in der Wartung auf eine einzige, oft nur kurzfristig verfügbare Person verlassen müssen.
Definieren und erzwingen Sie einen Review-/Abnahmeprozess für alle automatisierten Skriptkandidaten basierend auf diesen Standards, bevor sie im Testbetrieb eingesetzt werden dürfen.
Wartbarkeit
Wartbarkeit steht in engem Zusammenhang mit dem Problem der Verständlichkeit, jedoch sind beide logisch und operativ voneinander getrennt. Ein Testskript kann von Testingenieur:innen, die es nicht geschrieben haben, leicht verstanden werden und dennoch so strukturiert sein, dass es eine Qual ist, es zu aktualisieren oder zu modifizieren.
Hier ein Beispiel aus der Praxis.
Bei einem meiner ehemaligen Arbeitgeber bereiteten wir gerade den Testaufwand für ein mittleres Upgrade ihres Vorzeigeprodukts vor. Es war ein vierwöchiger Release-Zyklus geplant; in diesem Fall war das tatsächlich realistisch.
Während ich den dafür nötigen Testaufwand plante, fiel mir auf, dass wir auch das Hauptskript für den automatisierten Regressionstest aktualisieren müssten. Als ich den leitenden QA-Ingenieur fragte, wie lange dieses Update dauern würde, antwortete er: „Acht Wochen“. Doppelt so lange wie der gesamte Release! Selbst mit dem üblichen Ingenieur-Laster, Schätzungen aufzublähen, war das extrem.
Ich ließ das Skript sowie die Schätzung von ein paar anderen Testingenieur:innen überprüfen. Sie stimmten alle darin überein, dass das Skript derart umständlich und ineffizient geschrieben war, dass es viele Wochen mühsamer Umschreibungen des gesamten Skripts erfordern würde, um es für das nächste Release zu aktualisieren – selbst wenn die eigentlichen Änderungen keine grundlegende Überarbeitung des Produkts bedeuteten.
Diese Situation war ein klassisches Beispiel dafür, wie eine Software-Engineering-Sünde ins Test-Engineering hinübertransportiert wurde. Es ist Zeit, dem Wahnsinn ein Ende zu setzen.
Mein Rat hier ist derselbe wie oben beim Thema Verständlichkeit: Lassen Sie Ihre QA-Ingenieur:innen unter keinen Umständen in ihren Test-Ingenieurshöhlen verschwinden und nach ein oder zwei Wochen mit etwas herauskommen, das zwar als Test funktioniert, aber zum Albtraum wird, wenn es rechtzeitig angepasst werden muss.
Führen Sie Standards für zeitnahe Wartbarkeit ein und etablieren Sie einen Überprüfungs- und Abnahmeprozess, um diese sicherzustellen. Dies lässt sich problemlos mit den Bemühungen um Verständlichkeit verbinden, sodass alles Teil eines gemeinsamen Prüfprozesses werden kann.
Ihre QA-Ingenieur:innen sind keine Renaissancemaler, und Sie verlangen nicht von ihnen, die Sixtinische Kapelle neu zu malen. Das sollte kein Lebenswerk sein.
Testrollen und Testautomatisierung
Eines der Effizienzmuster, welches die reibungslose und erfolgreiche Integration von Automatisierung in die Gesamt-Teststrategie hemmt, ist die irrige Annahme, dass jeder Schritt im automatisierten Testprozess zwingend durch die Automatisierungsgruppe selbst erfolgen muss.
Auch das ist ein Fehler – wenn auch in diesem Fall kein ganz offensichtlicher.
Automatisierungsingenieur:innen sind vermutlich die am höchsten bezahlten Ressourcen in Ihrem Team; ihre Zeit ist also kostbar. Darüber hinaus wird das Volumen an Testskripten, das dieses Team erstellen und laufend aktualisieren muss, mit der Zeit immer weiter wachsen, während Ihre Testingenieur:innen zahlenmäßig nicht einmal annähernd so schnell mitwachsen können. Nicht einmal, wenn Sie bei Google arbeiten.
Es ist daher aus operativer Sicht sinnvoll, eine gewisse Arbeitsteilung zwischen dem Automatisierungsteam und dem Rest Ihres Teams einzuführen. Konkret: die Trennung zwischen denen, die automatisierte Skripte und Tools erstellen sowie pflegen, und jenen, die die automatisierten Tests tatsächlich ausführen.
Offensichtlich können die erstgenannten Aufgaben nur vom Automatisierungsteam selbst übernommen werden. Dafür wurden sie schließlich eingestellt. Für die zuletzt genannten gilt das jedoch nicht.
Es gibt keinen Grund, warum Analyst:innen nicht auch in der Lage sein sollten, automatisierte Tests selbstständig auszuführen und deren Ergebnisse zu interpretieren.
Nur sehr wenige denken bislang in diesen Begriffen, doch diese Arbeitsteilung ist in jeder Hinsicht sinnvoll. Sie gibt den Automatisierungsingenieur:innen viel Zeit zurück, um sich auf die Entwicklung neuer Automatisierungen zu konzentrieren.
Zudem wird sie das oben definierte Kriterium der Verständlichkeit stärken. Wenn Automatisierung zentraler Bestandteil der Teststrategie ist, muss es ebenso zentral sein, dass alle Teammitglieder – ob Automatisierungsingenieur:in oder nicht – automatisierte Tests verstehen und anwenden können. Auch manuelle Tester:innen.
Ein solches System der Rollendefinition erhöht die Flexibilität aller Ressourcen Ihres QA-Teams erheblich und ermöglicht so Effizienzen bei Zeit und Planung, die sonst unerreichbar wären.
Abschließende Gedanken
Eine robuste Fähigkeit zur Testautomatisierung, wie oben beschrieben, ist heutzutage schlichtweg eine Notwendigkeit. Professionelle, effektive Qualitätssicherung ist ohne sie undenkbar.
Dennoch beginnen viele erfolgversprechende Unternehmungen in Enthusiasmus und Freude, nur um am Ende des Weges in Niederlage zu enden. Ich habe dies im Bereich Testautomatisierung im QA-Umfeld vielfach beobachtet.
Das Problem ist: Automatisiertes Testen ist relativ einfach anzufangen. Teuer, aber es ist recht einfach, zumindest so zu tun, als würde man sich bemühen. Allerdings kann die Testautomatisierung auch zur Klippe werden, wenn man – wie der Koyote in den Roadrunner-Cartoons – achtlos darüberhinausläuft und erst dann in die Tiefe stürzt, wenn man nach unten blickt.
Es muss von Anfang an klar sein, dass Testautomatisierung einen Lebenszyklus hat. Jedes Testskript hat einen Lebenszyklus von Monaten, wenn nicht Jahren.
Es geht nicht einfach darum, eine Reihe automatisierter Testskripte zu schreiben, die den aktuellen Bedarf für das Produkt in seinem gegenwärtigen Entwicklungsstand abdecken. Es geht darum, wie Sie all diese Automatisierung nahtlos weiterentwickeln können, während das Produkt seinen eigenen Lebenszyklus durchläuft.
Wenn Sie die Probleme des Automatisierungsumfangs, der Qualifikationen der QA-Ingenieure, der Verständlichkeit, Wartbarkeit und der Rollendefinition ignorieren, werden Sie mit der Zeit feststellen, dass all dieser Automatisierungsaufwand zu einem weißen Elefanten und einem Fass ohne Boden geworden ist, das weder zu verstehen noch zu warten ist.
Und all das Geld, das Sie dafür ausgegeben haben, war umsonst. Etwas, das Ihren Vorgesetzten ganz bestimmt nicht entgehen wird.
Wenn Sie jedoch die oben genannten Ratschläge befolgen und selbstverständlich an die Besonderheiten Ihrer eigenen Herausforderungen und Situation anpassen, werden Sie diese Krise der Obsoleszenz weitgehend vermeiden und jahrelang von den Vorteilen produktiver Testautomatisierung profitieren können.
Wie immer, viel Erfolg.
Empfohlene Lektüre:
- 10 BESTE WEB-SERVER ÜBERWACHUNGSWERKZEUGE
- BESTE PRAKTIKEN FÜR AUTOMATISIERUNG IN DER DIGITALEN TRANSFORMATION
Empfehlung: WAS IST MABL? ÜBERSICHT & FUNKTIONSÜBERBLICK
