Planungsstrategien für gezielte Testautomatisierung
"Wir müssen automatisieren!" Testautomatisierung wird im modernen Entwicklungsprozess gerne als vielversprechende Methode und Lösung für qualitätsbezogene Probleme genannt. Ohne die richtige Motivation, ein beständiges Testkonzept und ohne ein konkretes Qualitätsziel vor Augen zu haben, wird eine Automatisierung jedoch zu einem schwierigen Unterfangen. Denn automatisierte Tests aufzusetzen, insbesondere auf höheren Ebenen der Testpyramide, erfordert nicht nur technologische Kenntnisse, sondern auch eine nahtlose Integration in den Entwicklungsprozess, um klassische Fallen zu vermeiden.
Die Wahl eines Tools wird hierbei häufig als erster und offensichtlichster Ansatzpunkt gesehen. Der Prozess hin zur erfolgreichen Testautomatisierung beinhaltet jedoch eine Reihe weiterer Schritte, welche vorher gegangen und Fragen, welche vorher beantwortet werden müssen. Dieser Artikel soll Ideen zu folgender Problematik geben: Wie können Teams Testautomatisierung gezielt einsetzen, sodass sie auch als wertvoll empfunden wird? Wie plant man die Anwendung von Beginn an, wie passt sie ins Testkonzept und in den
Entwicklungsprozess?
Zu diesem Zweck stelle ich verschiedene Hilfsmittel vor, um an die notwendigen Informationen zu gelangen und diese so zu sortieren, dass sich daraus eine gute Strategie für erfolgreiche Testautomatisierung entwickeln lässt.
Ein aktueller Blick auf das Thema Testautomatisierung
Testautomatisierung ist bei weitem keine neue oder als revolutionär angesehene Methode mehr. Auf Ebene von Unit-Tests ist sie in vielen Firmen mittlerweile zu einem festen Teil des Entwicklungsprozesses und der Quality Gates geworden. In höher angesiedelten Testebenen, insbesondere im Bereich der UI-Tests, galten automatisierte Tests jedoch lange als instabil, aufwändig und schlecht wartbar. Die eigene Erfahrung bei Anbahnung neuer Projekte zeigt, dass in diesem Thema entsprechend größere Vorsicht und Zurückhaltung herrscht. In Vorbereitung auf diesen Artikel habe ich daher begonnen zu recherchieren, ob sich dieses Bild in der Industrie noch immer hält oder die Akzeptanz dem Thema gegenüber gewachsen ist.
Der World Quality Report 2023 bietet interessante Einblicke zum Thema Testautomatisierung [1]. Auf der einen Seite ist der Bedarf dafür aufgrund der weit vorangeschrittenen agilen Transformation und damit einhergehenden immer kürzer werdenden Releasezyklen hoch. Umfangreiche manuelle Tests können in weiten Teilen nicht mehr mit der Geschwindigkeit in der Entwicklung Schritt halten. Auf der anderen Seite hingegen scheitern viele Unternehmen noch immer daran, die Entwicklung automatisierter Tests in den Entwicklungs- und Testprozess zu integrieren. Stattdessen wird ein starker Fokus auf das Tooling gelegt und andere Aspekte eines Testkonzepts, wie Festlegung von Qualitätszielen oder Testplanung, vernachlässigt. Eine positive Auffälligkeit innerhalb des Reports ist, dass für die meisten Firmen Return of Investment kein ausschlaggebendes Argument mehr bei der Entscheidung für Testautomatisierung ist, sondern primär Wartbarkeit und Berücksichtigung der Business Needs. Diese Entwicklung lässt sich so interpretieren, dass automatisierte Tests nicht mehr nur als Option zur Einsparung von Testkosten gesehen, sondern als eigenständige Testmethode anerkannt werden. Entsprechend müssen diese auch wie andere Hilfsmittel während der Softwareentwicklung gewartet und gepflegt werden.
Viele der Beobachtungen dieses Berichts spiegeln sich auch in Erfahrungen aus unserem Arbeitsalltag wider: Wenden sich Projektteams an unsere Experten mit dem Wunsch, Testautomatisierung zu etablieren, zielt die erste Frage in den meisten Fällen auf die Empfehlung eines geeigneten Test-Tools ab. Während dieses einen wichtigen Aspekt auf technologischer Ebene darstellt, wird keine noch so durchdachte Wahl eines Test-Tools die mit einer Testautomatisierung häufig noch einhergehenden Probleme lösen und für mehr Akzeptanz sorgen können. Was also macht erfolgreiche Testautomatisierung aus?
Automatisierte Tests sind dann gut umgesetzt, wenn sie vom Entwicklungsteam akzeptiert, integriert und als Mehrwert und Hilfe betrachtet werden. Auswirkungen können früher aufgedeckte Regressionen, geringere manuelle Testlast und höhere Stabilität und Testbarkeit der Anwendung sein [2]. Wie dieses Ziel real in der Umsetzung aussieht, hängt von den individuellen Faktoren der zu entwickelnden Anwendung ab, beispielsweise Entwicklungsmodell, Teamgröße und -zusammensetzung oder regulatorische Vorgaben.
Der Fokus dieses Artikels liegt darauf,
- Methoden zur Visualisierung von Testautomatisierungskonzepten und Qualitätszielen und
- einen Leitfaden zum Aufsetzen von Testautomatisierung vorzustellen.
Auch bei bereits fortgeschrittener Testentwicklung können diese Punkte Anregungen für Review oder Evaluation des eigenen Ansatzes bieten.
Die Faktenlage als Fundament für das Testkonzept
Erhalten wir als Software Quality Engineer eine Anfrage der Art: "Wir wollen Testautomatisierung einführen. Welches Tool empfehlt ihr?", kristallisieren sich häufig zwei verschiedene Ausgangslagen heraus.
- Im ersten Szenario handelt es sich um ein Team mit hohem Reifegrad, guten Kenntnissen der zu testenden Anwendung und einer konkreten Vorstellung der zu erreichenden Qualitätsziele.
- Szenario B stellt die Gegenseite dazu dar: Die Testautomatisierer:innen sind nicht fest in das Projektteam integriert, es ist kein einheitliches Verständnis über Anwendung und Testziele vorhanden und es herrscht keine klare Anforderungslage. Möglicherweise liegt nicht einmal eine intrinsische Motivation des Teams vor, sondern es wurde top-down vorgegeben, dass Testautomatisierung eingesetzt werden soll.
In der Realität bilden diese oder ähnliche Situationen eher zwei Enden eines Spektrums aus einer Reihe möglicher Startpunkte ab. Die Kunst, um von diesem Punkt der ersten Anfrage aus zu einem guten und akzeptierten Ergebnis zu kommen, liegt nun zunächst darin zu erkennen, wo das dazugehörige Team und Projekt zu verorten sind. Handelt es sich um einen hohen Reifegrad, lässt sich der Beratungsfokus meist auf die rein technologischen Aspekte beschränken. Im gegenteiligen Fall muss grundsätzlich erst ein einheitliches Verständnis über Relevanz, Auswirkungen auf den Entwicklungsprozess sowie Testautomatisierung im Kontext des Testkonzepts entwickelt werden.
Der vermutlich wichtigste und erste Meilenstein bei Einführung von automatisierten Tests besteht darin, die Motivation hinter dieser Entscheidung für das gesamte Team sichtbar zu machen. Die Antwort auf das "Warum" liefert die Grundlage, um auch das "Was" und darauf aufbauend die Integration, das "Wie", der Testautomatisierung konzipieren zu können.
Die Motivation: Das "Warum?" hinter der Testautomatisierung
Eine vermeintlich trivial erscheinende Frage hat sich aus persönlicher Erfahrung als guter Einstiegspunkt in die Analyse und Beratung bewährt: "Mit welchem Ziel wollt ihr automatisieren?" Auch die offensichtlichen Gründe, beispielsweise reduzierte Testausführungszeit und -kosten sowie konsistentere Testergebnisse, wie sie auch ausführlich in der Grundlagenliteratur [2] oder im eingangs benannten World Quality Report behandelt werden, können hierbei schon interessante Erkenntnisse über das Verständnis des Teams zum Thema Testautomatisierung liefern. Implizit gibt eine entsprechende Antwort auf die Frage auch schon gute Einblicke in das Anwendungswissen der Beteiligten: Haben alle Beteiligten die funktionalen und nicht-funktionalen Anforderungen im Blick? Gibt es merkliche Unterschiede in der Wahrnehmung des Nutzens, Einsatzes und der Zielgruppe der Anwendung, lohnt es sich, im Team noch einen Schritt zurückzugehen und diese Differenzen auszugleichen. Dies kann durch einen gemeinsamen Entwurf einer Product Outline erfolgen [3].
Spätestens an diesem Punkt stellt sich auch schnell heraus, ob die Motivation intrinsisch oder durch externe Faktoren begründet ist. Liegt letzterer Fall vor, ist enge Zusammenarbeit und Betreuung beim Konzipieren bis zum Aufsetzen notwendig. So kann zunächst ein gesamtheitliches Verständnis für den Projektplan, die Teamaufgaben und die Domäne aufgebaut und damit Frust vermieden werden. In beiden Fällen arbeitet das "Warum" als Einstiegsfrage darauf hin, eine Basis für die bevorstehende Integration automatisierter Tests innerhalb des Teams zu schaffen. Anhand dieser Basis sollten mindestens folgende Fragen beantwortet werden können:
- Welche Qualitätsziele sollen erfüllt werden?
- Welche Risiken gilt es abzusichern?
- Welche Probleme sollen gelöst werden?
- Welche Qualitätskriterien sind aus welchem Grund für die Anwendung wichtig?
- Welche Ebenen, Komponenten und Schnittstellen besitzt die zu entwickelnde Software?
Antworten auf diese Fragen bilden die Entscheidungsgrundlage für ein projektspezifisches Testkonzept, welches alle geplanten qualitätssichernden Maßnahmen inklusive Automatisierung beinhaltet. Eine bei uns mehrfach erfolgreich eingesetzte Methode ist das gemeinsame Ausfüllen des QA-Oktanten bzw. der Qualitätsmatrix [4].
Egal, ob als Matrix, Oktant oder Spinnennetz dargestellt, bleibt die Funktionsweise gleich. Im besten Fall wird das ganze Team zur Bearbeitung hinzugezogen. Bei größeren Teams empfiehlt sich jedoch mindestens eine Person je beteiligter Disziplin. Eine Person, bevorzugt mit guten Kenntnissen der Software-Qualitätssicherung, moderiert die Diskussion. Es werden die Qualitätskriterien, welche die eine Dimension der Matrix ausmachen, nacheinander thematisiert: Die moderierende Person stellt das aktuelle Kriterium vor und erklärt, welche Aspekte dieses beinhaltet. Daraufhin diskutiert die Gruppe, welche Priorität (niedrigste Priorität 0 bis zur höchsten Priorität 4) dem Kriterium für das eigene zu entwickelnde System zugeordnet wird und warum. Es kann sein, dass die Gruppe sich direkt einig ist. Besonders interessant sind die Aspekte, welche größere Differenzen erkennen lassen. Hiermit lassen sich sehr gut unterschiedliche Wahrnehmungen oder Informationsstände identifizieren, beheben und somit zu einem Konsens über die Priorisierung von Qualitätszielen gelangen.
Ergebnis des Austauschs ist die Dokumentation der Priorität pro Qualitätskriterium und vor allem der Begründung für diese. So ist diese auch im späteren Projektverlauf nachvollziehbar. Jedem Qualitätskriterium lassen sich nach Lehrbuch qualitätssichernde Maßnahmen im Allgemeinen beziehungsweise spezifische Testarten zuordnen.
Liegen diese Informationen vor, lässt sich letztlich auch die Frage "Welche Teststufen und -arten sollten automatisiert werden?" beantworten und darauf aufbauend eine geeignete technologische Lösung finden.
Das "Was" der Testautomatisierung
"Was genau soll automatisiert werden?" In erster Linie zielt diese Frage auf Kenntnis der verschiedenen Testarten mit den damit verbundenen Testzielen ab. Letztlich ist Testautomatisierung eine Methode, um verschiedene Testarten ausführbar zu machen und somit gesteckte Qualitätsziele zu erreichen. Abseits der zusätzlich benötigten technischen Kenntnisse muss also genauso wie bei manueller Testausführung das dazugehörige Grundwissen und Vokabular zum Thema "Testen" verinnerlicht sein.
Besonders Teams, welche sich noch neu im Thema Testautomatisierung oder womöglich sogar im Testen selbst bewegen, neigen zum Wunsch nach einer One-size-fits-all-Lösung. Gerade in komplexen Systemen ist jedoch die Wahrscheinlichkeit hoch, dass ein breites Feld an vertikalen End-2-End-Tests, ohne die Einheiten zunächst separat und integrativ getestet zu haben, zum Paradebeispiel für unzuverlässige automatisierte Tests wird. Besonders sichtbar wird das in zusammenhängenden Systemen, die beispielsweise neben einem UI noch ein Backend, eine Hardware-Ebene und potenzielle Cloud-Anbindung involvieren. Mit jedem einbezogenen Endpunkt erhöht sich nicht nur der Wartungsaufwand, sondern auch der Analyseaufwand bei auftretenden Fehlern. Gleichzeitig verringert sich die Stabilität des Testsetups insgesamt. Meine Empfehlung ist, sauber abgesteckte Testziele und Testfokus als Grundlage und darauf aufbauend eine Entscheidung für mehrere Testarten – sowohl automatisiert als auch manuell – zu treffen. Wichtig ist Klarheit darüber, wo der jeweilige Scope liegt: Was und von wo bis wohin im System wird jeweils getestet? Die deutliche Abgrenzung erleichtert die Wartung der Testfälle und Analyse von auftretenden Fehlern, da sich das jeweilige Testsubjekt klarer eingrenzen lässt. Unterstützt wird dies durch den Einsatz von Simulation und Mockups nach außen hin. Zudem ermöglicht dies, bei Codeänderungen eine risikobasierte Auswahl kleinerer Subsets an Tests zur Überprüfung von möglichen Regressionen ausführen zu können. So muss nicht immer eine große Testsuite mit langer Laufzeit durchgeführt werden. Damit sei allerdings nicht von End-2-End-Tests komplett abgeraten! Stattdessen kann sich deren Fokus jedoch darauf beschränken, die wichtigsten und risikoreichsten Funktionen der Anwendung gegen Regressionen abzusichern: Besser sind wenige zuverlässige und fokussierte Tests als eine breite Masse an Tests mit potentiellen Instabilitäten.
An diesem Punkt der Planung kommen nun die im vorherigen Abschnitt thematisierten Informationen rund um das Testobjekt und den damit verbundenen Testzielen ins Spiel. Aus den priorisierten Qualitätskriterien lassen sich eine Reihe an möglichen einsetzbaren Testarten ableiten. Besteht möglicherweise ohnehin schon ein Testkonzept, findet sich dadurch ein guter Ansatzpunkt, um bisher eventuell manuell ausgeführte Tests nun in die Automatisierung zu überführen oder das bestehende Set um passende automatisierte Methoden zu ergänzen. Um das "Was soll automatisiert werden?" in beiden Fällen für den individuellen Fall besser einzugrenzen und evaluieren zu können, bietet sich als Visualisierungs- und Entscheidungshilfe beispielsweise die agile Testmatrix an [5].
Besser noch als die Testautomatisierungspyramide [6] bildet diese auf einen Blick gut ab, welche Testarten gut automatisierbar sind und stellt die Unterschiede zwischen diesen durch Bezug zu deren Rolle und Wert im Projekt sowie der technologischen Ebene, auf welcher diese sich bewegen, gut heraus. An diesem Punkt wird letztlich auch das erste Mal aktiv von Automatisierung und nicht nur Qualitätssicherung im Allgemeinen gesprochen: Sämtliche Vorarbeiten gelten der generellen Testkonzeption und damit einhergehenden Analyse notwendiger Testziele. Somit sind alle Ergebnisse dieser Auswertung für ein gesamtes und möglichst lückenloses Testkonzept relevant, sowohl manuell als auch automatisiert. Sie helfen, den Scope und die Ziele der zu automatisierenden Tests durch klare Abgrenzung zu anderen Tests und sonstigen qualitätssichernden Maßnahmen zu schärfen und darüber Verantwortlichkeiten innerhalb des Teams zu definieren.
Insbesondere wenn dieses "Was" im Team mit möglichst gesamtheitlichem Input aller Perspektiven diskutiert und beantwortet wird, macht dieser Prozess nicht nur deutlich, welche Abhängigkeiten und Voraussetzungen mit Testautomatisierungsaufgaben einhergehen. Zusätzlich kann dadurch auch insgesamt mehr Verständnis für die Aufgaben der Qualitätssicherung geschaffen und die Kommunikation zwischen den einzelnen Rollen verbessert werden, wenn klar ist, wer was zu welchem Zeitpunkt benötigt. Am Ende dieser Untersuchung sollten zumindest diese Fragen beantwortet und dokumentiert werden können:
- Wo liegen Abgrenzungen zwischen den Testarten?
- Welchen Aspekt der Software sprechen die Testarten jeweils an? Welches Ziel steht dahinter?
- Was wird durch die jeweiligen automatisierten Tests verifiziert und auf welcher Basis?
- Wo setzen manuelle Tests an, welche manuellen Aufgaben können durch Automatisierung erleichtert werden? Was wird nicht automatisiert?
- Welche Voraussetzungen müssen jeweils erfüllt sein, um die automatisierten Tests umsetzen zu können?
Technik und Prozess: Das "Wie" der Testautomatisierung
"Wie werden Tests automatisiert?" Das umfasst primär zwei Themenfelder: die Verankerung der Testautomatisierung im Entwicklungsprozess und die eigentliche technische Umsetzung. Ersteres beschäftigt sich vor allem mit der Frage "Wer automatisiert was und wann?". Die Antworten darauf können je nach Teamgröße, Teamkonstellation, Arbeitsmodus, Workflow und Status des Projektes (von Anbahnungsphase bis hin zum Legacy-Projekt) und nicht zuletzt Know-how der jeweiligen Teammitglieder sehr unterschiedlich ausfallen. Relevant ist hierzu die Frage: Wie funktioniert die technische Umsetzung? Im Folgenden gebe ich möglichst technologie-agnostische Ideen und Empfehlungen dazu, wie man zu einer für das eigene technologische Umfeld passenden Lösung zur Umsetzung der zuvor gesteckten Qualitätsziele und daraus abgeleiteten Testmethoden kommen kann.
Die technischen Rahmenbedingungen und Anforderungen für ein Test-Tool ergeben sich direkt aus dem jeweiligen Techstack, auf welchem das Testobjekt aufbaut, und aus dessen Entwicklungsumgebung. Sind diese klar, lässt sich der Markt auch sehr präzise durchsuchen: Mithilfe der Programmiersprache, in welcher entwickelt wird, der Testmethode und der gewünschten Sprache zur eigentlichen Testprogrammierung lässt sich das Angebot an Test-Frameworks gut eingrenzen. Die Auswahl ist mittlerweile groß, auch an frei verfügbaren Werkzeugen und vergleichenden Artikeln, sodass der hauptsächliche Recherchefokus auf deren Eignung für den geplanten Einsatzzweck liegen kann. Beispielsweise ist nicht bei allen Testframeworks im Webumfeld der Support verschiedener Browser gleich gut gegeben, im Kontext einer C++-Embedded-Anwendung kann es einen Unterschied machen, ob die zu testende UI QML, Qt Widgets oder wiederum andere Technologie nutzt. Gleichzeitig lassen sich möglicherweise API-Tests aber auch schon mit bereits zur API-Definition im Projekt etablierten Werkzeugen umsetzen, sodass hier kein Zusatzaufwand neben Entwurf und Umsetzung der funktionalen Testfälle investiert werden muss. An diesem Punkt lässt sich schlicht durch Ausprobieren und direkten Vergleich am besten evaluieren, welches Tooling am besten zum Techstack, der Arbeitsweise des Teams und dessen Erfahrungen passt. In diesem Punkt empfiehlt auch der World Quality Report, besser auf verschiedene Tools mit klarem Einsatzzweck statt auf ein Universal-Tool zu setzen.
Letztlich gilt: Eine entsprechende Entscheidung muss im Sinne der Wissensverteilung und langfristigen Wartbarkeit mit möglichst hoher Akzeptanz vom Entwicklungsteam getragen werden, um auch die allgemeine Akzeptanz der automatisierten Tests zu unterstützen. Eine vage Trennlinie lässt sich hier zwischen produktbasierter und projektbasierter Entwicklung ziehen: Erstere bringt meist lange Entwicklungs- und Supportzeiten mit sich. Daher lohnt es sich, hier langfristig gesehen ein mit möglichst vielen Beteiligten evaluiertes Tool als Standard zu etablieren. Im Projektumfeld hingegen sind meist Laufzeiten eines Projekts absehbar und die technologische Vielfalt im Unternehmen höher, weshalb es in diesem Kontext ratsamer sein kann, sich im Unternehmen mit der Zeit ein Portfolio an passenden Tools für unterschiedliche Technologien und Einsatzzwecke aufzubauen und daraus ein zum aktuellen Projekt passendes Set zu wählen. Test-Tools sind zwar ein wichtiger Faktor in der eigentlichen Realisierung der geplanten Tests, sollten aber nie des Tools wegen eingesetzt werden. Stattdessen sollte es als passendes Hilfsmittel zum Erreichen der gesteckten Qualitätsziele gesehen werden und weil es gut zur Arbeitsweise und dem Know-how des Teams passt.
Auch in Bezug auf die Tool-Landschaft hilft eine Visualisierung des bestehenden Setups, um Lücken zu identifizieren und den Einsatzzweck verschiedener Werkzeuge besser zu verdeutlichen. Darstellbar ist die ganze Infrastruktur beispielsweise durch das Testautomatisierungs-Framework nach ISTQB [2]. Wie auch bei anderen Visualisierungsmethoden stehen hier Übersichtlichkeit, Wissensvermittlung bzw. Wissensverteilung und Lückenerkennung im Fokus: "Wo finde ich was?" wird auch für Neueinsteigende deutlich überschaubarer.
Dieses Template ist je nach den benötigten Schichten individualisierbar und kann anschließend mit der eigenen Werkzeugkette ausgefüllt werden. Dafür werden die in den beiden vorherigen Abschnitten jeweils thematisierten Informationen benötigt: Insbesondere die Testadaptierungsschicht muss auf die für das vorliegende Testobjekt und die geplanten zu automatisierenden Testarten angepasst werden. Steht das auf die zu testende Anwendung zugeschnittene Template bereit, sollte pro Schicht für jeden Block ein Tool-Name, ein Ablageort (beispielsweise für Testdaten) oder eine Begründung für ein Fehlen dessen eingetragen werden können. Falls dies nicht der Fall sein sollte, könnten sich noch Lücken in der Werkzeugkette befinden. Wichtig ist: Es braucht kein dediziertes Tool pro Schicht und Einsatzzweck, wenn sich vieles ohnehin durch die bestehende Tool-Landschaft abdecken lässt. Beispielsweise könnte sowohl Testmanagement als auch Testdefinitions- und Testgenerierungsschicht in Jira mit entsprechenden Erweiterungen gehandhabt werden, während sich die hauptsächlichen Unterschiede im Tooling in der Testadaptierungsschicht abspielen.
Den erfahrenen Lesenden fällt an dieser Stelle möglicherweise bereits eine Modifikation zur ursprünglichen ISTQB-Vorlage auf. Ein gern vernachlässigter Aspekt bei der technischen Umsetzung automatisierter Tests ist, dass auch der Testcode qualitätssichernde Maßnahmen durchlaufen sollte. Um dieses Thema auch präsent zu machen, habe ich daher die zusätzliche Schicht "Testanalyse" eingefügt, welche Informationen bezüglich eingesetzter statischer Codeanalysen und Metriken (wie Code Coverage) bereitstellen soll. Das gilt übrigens nicht nur für die eigentlichen Funktionen und Skripte: Auch für Tests, welche im Sinne von Behaviour Driven Development (BDD) möglichst natürlichsprachlich beispielsweise mit Gherkin umgesetzt sind, gibt es frei verfügbare Formatter und Linter. Gerade in diesem Kontext, welcher darauf abzielt, von einfach lesbarer Testbeschreibung auf der einen Seite und von hoher Wiederverwendung von Testschritten auf der anderen Seite zu profitieren, ist einheitlicher Stil und saubere Architektur umso relevanter.
Insgesamt empfehle ich folgenden Grundsatz: Testcode wie Produktivcode behandeln! Konkret bedeutet das:
- Coding Conventions für die zur Testprogrammierung gewählte Sprache sollten definiert werden.
- Auch Testcode muss Reviews unterzogen werden und einem ähnlichen Releaseworkflow folgen.
- Statische Codeanalyse mit passenden Regeln sollte darauf angewendet und in der Pipeline ausgeführt werden.
- Allgemeingültige Programmierprinzipien und Best Practices der jeweiligen Programmiersprache sollten beachtet und angewendet werden.
- Es sollten Anleitungen und Dokumentation erstellt werden.
- Auch für den Testcode sollte eine Architektur festgelegt und durchgängig genutzt werden.
Unabhängig davon, ob Tests nun geskriptet, generiert oder aufgezeichnet werden, gilt das Stichwort "Nachhaltigkeit" für alle, um zu gewährleisten, dass diese auch durch unterschiedliche Personen mit der notwendigen technischen Expertise langfristig nutzbar und wartbar bleiben.
Die Umsetzung: Eine Planungsfrage für das gesamte Team
In meiner Erfahrung im Dienstleistungsbereich für Entwicklung von Individualsoftware für verschiedenste Branchen sind mir bisher keine zwei gleichartigen Projekte begegnet. Im Gegensatz zu produktbasierter Entwicklung hält projektbasierte Entwicklung üblicherweise mehr Varianz in Entwicklungslaufzeit, erwarteter Support-Zeit und Technologie bereit, sodass es in diesem Kontext schwieriger ist, Standards in Bezug auf Testprozesse und Testtools zu etablieren. Umso deutlicher wird dadurch, wie wichtig gute Kommunikationsstrukturen, Wissenstransfer und klare Verantwortlichkeiten gerade auch für das Thema Testautomatisierung sind, um Fallen wie schlechter Wartbarkeit oder instabilen Setups entgegen zu wirken. Das eigentliche Tooling zur Testprogrammierung verliert zugunsten dieser Faktoren dabei an Bedeutung und wird reines Mittel zum Zweck. Wichtiger als Tool-Erfahrungen nehme ich aus jedem Projekt neue Best Practices zum Thema allgemeiner Testarchitektur und -infrastruktur mit, die mit dem nächsten Einsatz bereits vorweg technische Fallstricke vermeidet. Dennoch sollten gerade zum Einstieg in das Thema genug Zeit, Meinungen und Versuche investiert werden, um ein passendes Testautomatisierungs-Framework zu finden, mit welchem alle Teammitglieder gut arbeiten können: Sämtliche Vorbereitung und Planung kann Scheitern an der technischen Hürde nur bedingt abfedern. Besonders bei hohen Einstiegshürden durch beispielsweise mangelnde Tool-Dokumentation oder eine dem Team fremde Technologie, die es zusätzlich zu erlernen gilt.
Diejenigen Projekte, in denen Tests und besonders Testautomatisierung am besten integriert waren, hatten vor allem zwei Gemeinsamkeiten. Zum einen war das Verständnis für die Tätigkeiten der anderen Rollen so hoch, dass auch durchaus rollenübergreifend Aufgaben mit übernommen werden konnten: Entwickler:innen kennen den Testcode gut genug, um Wartung daran vornehmen zu können, während Testautomatisierer:innen auch bei kleinen Anpassungen am Produktivcode aushelfen. Die zweite Maßnahme klingt verhältnismäßig trivial: Ich kann jedem Team nur empfehlen, sich (sofern möglich) mit allen Beteiligten zusammenzusetzen, alle im Projektalltag und zu Meilensteinen zu erledigenden Aufgaben aufzuschreiben und – je nach Teamgröße – Namen oder Rollen als Verantwortliche dazuzuschreiben und den Entwicklungsprozess inklusive der Testautomatisierungsaufgaben zu visualisieren. Das bietet sich nicht nur zu Beginn eines Projektes, sondern besonders auch zu Anlässen wie größeren Releases oder in Retrospektiven an und kann insbesondere auch neuen Teams mit weniger hohem Reifegrad viel an Erkenntnisgewinn und Verständnis bringen. Denn der Entwicklungs- und Testprozess, wie er gelebt wird und wie er einmal auf das Papier gebracht wurde, können sich mit der Zeit durchaus auseinanderentwickeln. Vor allem kann es aus Testsicht verdeutlichen, dass qualitätssichernde Maßnahmen nicht zwingend und exklusiv an der Rolle Tester:in hängen. Mehr noch als für manuellen Test gilt für Testautomatisierung, dass diese am besten funktioniert, wenn sie zeitlich und fachlich so eng wie möglich mit der Entwicklung zusammenarbeitet.
- Capgemini u.a. (2022): World Quality Report 2022-23.
- Baumgartner, Manfred u.a.: Basiswissen Testautomatisierung, dpunkt.verlag
- How to write a product outline
- Zeiss: Wie verwende ich den QA-Oktanten?
- Lisa Crispin: Using the Agile Testing Quadrants
- Tutorial: Testautomatisierung auf verschiedenen Stufen
Neuen Kommentar schreiben