Basiswissen Testautomatisierung E-Book

Manfred Baumgartner

• Herausgeber: dpunkt.verlag
• Kategorie: Wissenschaft und neue Technologien
• Serie: Basiswissen
• Sprache: Deutsch
• Veröffentlichungsjahr: 2021

Seitenzahl: 496

Beschreibung

Testautomatisierung ist ein mächtiges Werkzeug, um Tests wiederholbar zu machen und effizienter zu gestalten. Dieses Buch erklärt, wie Testautomatisierung mit Fokus auf den funktionalen Systemtest konzipiert und in bestehende Projekte und die Organisation eingegliedert wird. Dabei werden sowohl fachliche als auch technische Konzepte vorgestellt. Beispiele aus verschiedenen Einsatzgebieten (z.B. Webapplikationen, Data-Warehouse-Systeme) und Projektarten (z.B. Scrum, V-Modell) erläutern die methodischen Grundlagen. Auch auf Werkzeuge sowie Qualitätsgewinne und Einsparpotenziale durch Testautomatisierung wird eingegangen.

Aus dem Inhalt:

- Testprozess und Entwicklungsvorgehen
- Testfallspezifikation und -durchführung
- Konzeption eines Automatisierungsframeworks
- Einsatzgebiete nach System-, Test- und Projektart
- Testdurchführungswerkzeuge
- Integration in die Organisation

Im Anhang finden sich Beispiele zur Erstellung von daten- und schlüsselwortgetriebenen Testfällen sowie beispielhaft ein Kriterienkatalog zur Auswahl eines Testwerkzeugs aus der Praxis.

Leseprobe

Manfred Baumgartner verfügt über mehr als 30 Jahre Erfahrung in den Bereichen Softwaretest und Qualitätssicherung. Seit 2001 hat er das QS-Beratungs- und Schulungsangebot der Nagarro GmbH (ehemals ANECON), eines der führenden Dienstleistungsunternehmen im Bereich Softwaretest, auf- und ausgebaut. Er ist Präsidiumsmitglied des Vereins für Softwarequalität und Weiterbildung (ASQF) und des Vereins für Software-Qualitätsmanagement Österreich (STEV) sowie Mitglied des Austrian Testing Board (ATB). Seine umfangreichen Erfahrungen bringt er in viele Präsentationen auf Konferenzen im gesamten deutschsprachigen Raum und in Artikeln und Büchern zum Thema Softwaretest ein.

Stefan Gwihs ist als begeisterter Softwareentwickler, Softwaretester und Testautomatisierungsarchitekt für die Nagarro GmbH (ehemals ANECON) tätig, wo er sich aktuell vor allem mit Themen im Bereich Testautomatisierung agiler Softwareentwicklung und DevOps beschäftigt.

Richard Seidl hat in seiner beruflichen Laufbahn schon viel Software gesehen und getestet: gute und schlechte, große und kleine, alte und neue, Schokolade und Grütze. Sein Credo: Qualität ist eine Haltung. Wer heute exzellente Software kreieren möchte, denkt den Entwicklungsprozess ganzheitlich: Menschen, Methoden, Tools und Mindset. Als Berater und Coach unterstützt er Unternehmen dabei, Agilität und Qualität zu leben und in der Unternehmens-DNA zu verankern.

Thomas Steirer (ehem. Bucsics) leitet als Automatisierungsexperte, Testmanager und Trainer für die Nagarro GmbH (ehemals ANECON) die globale Einheit für Testautomatisierung. Seit 2010 ist er als ISTQB® Certified Tester – Full Advanced Level zertifiziert. Er ist Vortragender einer Vorlesung für Testautomatisierung im Masterstudiengang Software-Engineering am Technikum Wien und forscht an der Nutzung von künstlicher Intelligenz mit dem Ziel, Testautomatisierung noch effizienter zu gestalten.

Marc-Florian Wendland ist wissenschaftlicher Mitarbeiter am Fraunhofer-Institut FOKUS in Berlin. Seit über 10 Jahren beschäftigt er sich in nationalen und internationalen, branchenübergreifenden Forschungs- und Industrieprojekten mit Themen der Testautomatisierung in Entwurf und Ausführung. Er ist Mitglied des German Testing Board (GTB) und auch als Trainer für die verschiedenen ISTQB-Programme unterwegs.

Zu diesem Buch – sowie zu vielen weiteren dpunkt.büchern – können Sie auch das entsprechende E-Book im PDF-Format herunterladen. Werden Sie dazu einfach Mitglied bei dpunkt.plus+:

www.dpunkt.plus

Manfred Baumgartner · Stefan Gwihs · Richard Seidl · Thomas Steirer · Marc-Florian Wendland

Basiswissen Testautomatisierung

Aus- und Weiterbildung zum ISTQB® Advanced Level Specialist – Certified Test Automation Engineer

3., aktualisierte und überarbeitete Auflage

Manfred Baumgartner · [email protected]

Stefan Gwihs · [email protected]

Richard Seidl · [email protected]

Thomas Steirer · [email protected]

Marc-Florian Wendland · [email protected]

Lektorat: Christa Preisendanz

Copy-Editing: Ursula Zimpfer, Herrenberg

Satz & Layout: Birgit Bäuerlein

Herstellung: Stefanie Weidner

Umschlaggestaltung: Helmut Kraus, www.exclam.de

Bibliografische Information der Deutschen Nationalbibliothek Die Deutsche Nationalbibliothek verzeichnet diese Publikation in der Deutschen Nationalbibliografie; detaillierte bibliografische Daten sind im Internet über http://dnb.d-nb.de abrufbar.

Fachliche Beratung und Herausgabe von dpunkt.büchern zum Thema »ISTQB® Certified Tester«: Prof. Dr. Andreas Spillner · [email protected]

ISBN:

Print   978-3-86490-675-6

PDF    978-3-96088-787-4

ePub  978-3-96088-788-1

mobi   978-3-96088-789-8

3., aktualisierte und überarbeitete Auflage

Copyright © 2021 dpunkt.verlag GmbH

Wieblinger Weg 17

69123 Heidelberg

Hinweis:

Dieses Buch wurde auf PEFC-zertifiziertem Papier aus nachhaltiger Waldwirtschaft gedruckt. Der Umwelt zuliebe verzichten wir zusätzlich auf die Einschweißfolie.

Schreiben Sie uns:

Falls Sie Anregungen, Wünsche und Kommentare haben, lassen Sie es uns wissen: [email protected].

Die vorliegende Publikation ist urheberrechtlich geschützt. Alle Rechte vorbehalten. Die Verwendung der Texte und Abbildungen, auch auszugsweise, ist ohne die schriftliche Zustimmung des Verlags urheberrechtswidrig und daher strafbar. Dies gilt insbesondere für die Vervielfältigung, Übersetzung oder die Verwendung in elektronischen Systemen.

Es wird darauf hingewiesen, dass die im Buch verwendeten Soft- und Hardware-Bezeichnungen sowie Markennamen und Produktbezeichnungen der jeweiligen Firmen im Allgemeinen warenzeichen-, marken- oder patentrechtlichem Schutz unterliegen.

Alle Angaben und Programme in diesem Buch wurden mit größter Sorgfalt kontrolliert. Weder Autor noch Verlag können jedoch für Schäden haftbar gemacht werden, die in Zusammenhang mit der Verwendung dieses Buches stehen.

5 4 3 2 1 0

Vorwort zur 3. Auflage

»Mit Testautomatisierung automatisch besser!?«

100% Testüberdeckung, 400% Effizienzsteigerung, deutlich reduziertes Risiko, schnellere Time to Market und stabile Qualität – das waren und sind die Versprechen der Testautomatisierung oder, besser gesagt, jener, die mit Werkzeugen und Beratungsleistungen rund um dieses Thema ihr Geld verdienen. Und seit dem Erscheinen der ersten Auflage dieses Buches steht der Einsatz von Testautomatisierung auf der To-do-Liste von vielen, in Wirklichkeit fast allen Unternehmen, die Software produzieren oder implementierten. Die versprochenen und erwarteten Ziele wurden aber kaum erreicht. Im Gegenteil: Es gibt eine große Diskrepanz zwischen den in den Hochglanzprospekten der Werkzeughersteller dargestellten Errungenschaften und der in vielen Unternehmen vorhandenen Unsicherheit bezüglich des erfolgreichen und nachhaltigen Einsatzes von Testautomatisierung.

Dieses Buch soll eine umfassende, praktische Einführung mit ausreichendem Tiefgang geben und somit einen Leitfaden durch das Thema »Testautomatisierung« für eine Vielzahl von Rollen in diesem Tätigkeitsfeld bieten. Auch im Hinblick auf den schnelllebigen IT-Markt hat sich die Testautomatisierung in den letzten Jahren sowohl als technische als auch als inhaltliche Disziplin rasant entwickelt. Skalierbare Agilität, Continuous Deployment und DevOps machen das Thema zu einer erfolgskritischen Komponente der Softwareentwicklung.

Diese Dynamik betrifft insbesondere auch die Testautomatisierungswerkzeuge – ob kommerziell oder Open Source. Daher verzichten wir in dieser Auflage darauf, in einem eigenen Kapitel auf konkrete Werkzeuge näher einzugehen, denn deren funktionale Beschreibung und Bewertung durch die Autoren würden bereits zwischen der Finalisierung des Textes und der Drucklegung an Aktualität verlieren. Hinzu kommt, dass es mittlerweile sowohl im Open-Source-Umfeld als auch im kommerziellen Bereich so viele wertvolle Werkzeuge gibt, dass jede Selektion der Autoren gegenüber anderen Herstellern und Communitys unfair wäre. Stattdessen listen wir einige passende Werkzeuge in den jeweiligen Kapiteln über die Testautomatisierungsarchitektur auf, in denen auf ihre Hauptrolle in einer Testautomatisierungslösung Bezug genommen wird. Werkzeugvergleiche und Marktanalysen finden sich rasch und in großer Menge im Internet – wobei selbst diese oft nicht tagesaktuell gepflegt sind.

Der Bedeutung der Disziplin Testautomatisierung trägt auch die internationale Tester-Community Rechnung: Ende 2019 wurde die deutsche Fassung des »ISTQB® Certified Tester Advanced Level Testautomatisierungsentwickler« [ISTQB 19c] freigegeben. Damit ist Testautomatisierung noch mehr als zuvor und endgültig Kernbestandteil der Disziplin »Softwaretest« mit einer eigenen Zertifizierung und dem dazugehörigen Lehrplan. Die dritte Auflage unseres Buches ist nicht nur eine Aktualisierung und Erweiterung der vorhergehenden Versionen. Vielmehr ist es eine komplette Neugestaltung entlang der Struktur dieses jungen und sich weiterentwickelnden Lehrplans. Auch die Kernkapitel über die Testautomatisierungsarchitektur und über den Umgang mit Testautomatisierung in Projekten und Organisation wurden wesentlich überarbeitet. Sie halten also quasi die Erstauflage eines neuen Buches in den Händen.

Gründe für diese Neugestaltung gibt es mehrere: Die erste Auflage des Buches »Basiswissen Softwaretest« erschien im Jahr 2011, also fünf Jahre vor der Veröffentlichung der ersten englischen Fassung des ISTQB® Advanced Level Syllabus Test Automation Engineer Version 2016. Die zweite Auflage unseres Buches, 2015, war diesem Standard ebenfalls der Zeit voraus. Mit der Freigabe der deutschen Fassung 2019 sahen wir nun die Zeit gekommen, uns an diesem internationalen Standard zu orientieren, der die gemeinsame Sprache und den Wissensaustausch im Bereich Testautomatisierung unterstützen soll. Des Weiteren verfolgen wir auch das Ziel, unsere Leser bestmöglich in die Inhalte des Lehrplans einzuführen und sie auf die Zertifizierungsprüfung vorzubereiten. Der Lehrplan ist umfangreich und ausführlich und für sich ein eigenständiges Nachschlagewerk – wir sind aber überzeugt, mit unserem Buch einen deutlichen Mehrwert zu geben. Und zwar dadurch, dass wir mit praxisbezogenem Kontext, einer leicht lesbaren Form und praktischen Beispielen das Erfassen der Lehrinhalte deutlich einfacher und nachhaltiger ermöglichen, als es das Studium des Lehrplans allein zulässt.

Daher bereitet dieses Buch nicht nur auf die relevanten Inhalte für die Zertifizierungsprüfung vor, sondern vermittelt dem Leser auch die praktische Anwendung der Testautomatisierung.

Die Inhalte des Lehrplans (Version 2019) sind in diesem Buch in abweichender Reihenfolge und mit unterschiedlichen Schwerpunktsetzungen aufgearbeitet und durch viele essenzielle Themen ergänzt, die wir als Exkurse deutlich ausweisen.

Die Grundlage für die Zertifizierungsprüfung ist jedoch immer der zum jeweiligen Zeitpunkt offizielle Lehrplan.

Daher empfehlen die Autoren für die Vorbereitung auf die Prüfung neben der Lektüre des vorliegenden Werkes den Besuch eines entsprechenden Trainings sowie einen Blick in die aktuelle Version des Lehrplans [ISTQB 19c].

Die Abdeckung des Lehrplans ist nur einer von mehreren Aspekten, die wir in diesem Buch behandeln wollen – die drei Hauptziele, die wir uns bereits in der ersten und zweiten Auflage von »Basiswissen Testautomatisierung« gesetzt hatten, behalten ihre Gültigkeit:

Erstens wollen wir Sie davor bewahren, dass Sie aufgrund überzogener Erwartungshaltungen enttäuscht werden. Testautomatisierung ist nicht eine Frage der Werkzeuge, nicht ein Auftrag, die Marketing-Schlagworte diverser Hersteller umzusetzen, sondern lediglich ein Instrument, das es Ihnen ermöglicht, die stetig wachsenden Anforderungen an den Softwaretest besser zu bewältigen.

Zweitens wollen wir Ihnen eine Anleitung geben, wie Sie dieses Instrument bestmöglich nutzen können. Dabei stehen insbesondere die Langfristbetrachtung, die Nachhaltigkeit der Investition und der tatsächliche Business Value im Vordergrund. Diese Aspekte messen sich nicht in einer Codeüberdeckung oder in einer Anzahl von Testskripten, sondern an der Total Cost of Ownership der Applikationsentwicklung und -evolution sowie am Nutzen und Anwenderfeedback am Markt.

Drittens haben wir erneut wesentliche Aspekte der Testautomatisierung eingearbeitet, wie zum Beispiel die Rolle von Testautomatisierung im Kontext von Systemen mit künstlicher Intelligenz oder im DevOps-Umfeld.

Wird mit Testautomatisierung automatisch alles besser? Nein! Eine Fertigungsmaschine, die falsch justiert ist, liefert nur Ausschuss. Wenn sie unzulänglich bedient wird, erzeugt sie zufällige und unbrauchbare Ergebnisse. Wenn sie nicht oder unpassend gewartet wird, kommt sie zum Stillstand oder wird gar unbrauchbar. Ausgebildete Mitarbeiterinnen und Mitarbeiter, nachhaltige Konzepte, das Bewusstsein, dass Testautomatisierung ein wesentlicher Produktionsfaktor ist, und der verantwortungsvolle Umgang mit diesem sind Voraussetzungen dafür, dass die Potenziale und Möglichkeiten dieser Technologie auch tatsächlich realisiert werden können. Und dies ist in den meisten Fällen auch erfolgskritisch, denn Testautomatisierung ist unabdingbar, um in agilen Projektumwelten stabile Qualität liefern zu können, um mit der Geschwindigkeit moderner Continuous-Delivery-Verfahren Schritt zu halten und gleichzeitig die langfristige Wirtschaftlichkeit von Softwareentwicklungsprojekten insgesamt zu gewährleisten.

Für die Umsetzung in Ihrem Unternehmen wünschen wir Ihnen viel Erfolg. Begleitende Informationen zu diesem Buch und weitere wertvolle Hinweise zum Thema Testautomatisierung finden Sie auf unserer Internetseite www.software-test-automation.at.

Danksagung

Die Autoren danken den tatkräftigen Unterstützern Michael Hombauer, Sonja Baumgartner, Dominik Schildorfer, Anita Bogner, Christian Mastnak, Roman Rohrer, Martin Schweinberger, Stefan Denner, Stephan Posch, Yasser Aranian, Georg Russe, Vincent Bayer, Andreas Lenich, Cayetano Lopez-Leiva, Bernhard König, Jürgen Pointinger sowie dem Unternehmen Nagarro.

Manfred Baumgartner, Wien 2020

Stefan Gwihs, Wien 2020

Richard Seidl, Essen 2020

Thomas Steirer, Brunn am Gebirge 2020

Marc-Florian Wendland, Berlin 2020

Geleitwort zur 3. Auflage

Die zweite Welle ist da! Ich denke, wir befinden uns gerade mitten in der zweiten Welle der Testautomatisierung. Die große erste Welle habe ich in den ersten Jahren der 2000er-Jahre beobachten können. Die Projekte hatten zunächst große Erfolge zu verbuchen im Sinne einer Verbesserung von Effektivität und vor allem Effizienz der Testprozesse in punktuellen Einsatzbereichen. Allerdings, ganz im Sinne des Gartner-Zyklus: Das »Tal der Enttäuschungen« war schnell erreicht und das »Plateau der Produktivität« wurde – in meinem Sichtfeld – von der Mehrheit dann nicht erklommen.

Was ich damals beobachten konnte, waren Projekte, die sich über mehrere Jahre und mit enormem Aufwand zu einem hohen Grad an Testautomatisierung vorgearbeitet hatten. Und dann kamen Technologiewechsel wie der Umstieg zu .NET-Plattformen oder Prozesswechsel wie die Umstellung auf Agile. Und viele der Testautomatisierungsframeworks haben diese Umstellungen nicht überstanden. Also bin ich in dieser Zeit gerne mit Vorträgen an die Öffentlichkeit gegangen, die provokante Titel trugen, wie »Testautomatisierung schlägt immer fehl«.

Zwei Kernprobleme waren zu beobachten: Erstens sind Organisationen daran gescheitert, die punktuellen Erfolge auf das gesamte Projekt oder die Organisation zu skalieren. Und zweitens waren Testautomatisierungs-Plattformen nicht adäquat in der Lage, disruptive Änderungen an der technologischen Basis flexibel aufzufangen.

Kein Wunder also, dass das Thema Testautomatisierung mit der Zeit an Akzeptanz verlor. Hier spielen dann auch Managementaspekte eine tragende Rolle. Auf lange Sicht konnten die hohen wirtschaftlichen Erwartungen einer einmaligen Investition, die dann Regressionsaufwände deutlich reduziert, oft nicht erfüllt werden.

Seit Mitte des 2. Jahrzehnts können wir nun eine weitere Trendwelle der Testautomatisierung in den Projekten beobachten. Wird die Testautomatisierung nun wieder unter ihren Erwartungen bleiben? Ich glaube nein. Einerseits haben sich die Rahmenbedingungen für die Automatisierung von Tests geändert und andererseits die Erwartungen, die daran gestellt werden. Testautomatisierung hat sich inzwischen wieder als unverzichtbarer Erfolgsfaktor von Projekten in den aktuellen technologischen Szenarien etabliert. Warum dieser Unterschied?

Mit dem Einzug von agilen Prozessen haben sich hoch automatisierte und werkzeuggestützte Entwicklungsprozesse mittlerweile als Standard etabliert und deutlich weiterentwickelt. Continuous-Integration-Konzepte werden stetig zu DevOps-Prozessen weiterentwickelt, um eine nahtlose Plattform für die Integration automatisierter Projektschritte von der Idee bis zur Produktion und zum Betrieb zu schaffen. Die durchgehende Automatisierung von Prozessen bildet damit in natürlicher Weise eine hervorragende Basis zur Integration der Testautomatisierung in den Gesamtprozess. Die Skalierung von Prozessen hat mit dem agilen Vorgehen einen neuen, hohen Stellenwert erreicht. Dies ist eine Entwicklung, die für die Einführung und langfristige Etablierung von Testautomatisierungslösungen ein essenzieller Erfolgsfaktor ist.

Ein wesentlicher Faktor für die Bedeutung und Notwendigkeit der Testautomatisierung ist aber die technologische Plattform, auf der wir uns derzeit bewegen. Disruptive Technologien wie IoT und künstliche Intelligenz drängen aus ihren jahrzehntelangen Nischen rasant in die Breite in unsere Produkte. Dies bringt eine deutliche Verschiebung der Prioritäten für die Qualitätsmerkmale mit sich, die wir testen müssen. Während vor 20 Jahren noch 90% aller Tests funktionale Tests waren, setzt sich die Bedeutung der nicht funktionalen Tests wie Usability, Performanz, IT-Sicherheit usw. langsam, aber sicher durch. Die Anzahl der Testfälle, die zur Bewertung der Produktqualität erforderlich sind, steigt daher rapide an, und nur mit automatisierten Tests können Qualitätsmerkmale wie die Performanz effektiv abgesichert werden.

Die Entwicklung und Wartung von Produkten erfolgt in immer kürzer werdenden Zeitintervallen. Aufgrund der steigenden Varianz in den Hardware- und Softwarekonfigurationen müssen die (Gesamt-)Systeme in einer steigenden Anzahl an Varianten getestet werden. Ein nicht automatisierter Regressionstest wird somit zunehmend zu einer Belastung für das Projekt; beziehungsweise es wird immer schwieriger, die geforderte Testabdeckung mit adäquatem Aufwand zu erreichen.

Und glücklicherweise haben wir auch methodisch dazugelernt: Testarchitekturen als ein wichtiger, wenn nicht der wesentlichste Faktor für die Qualität in der Wartbarkeit der automatisierten Tests sind mittlerweile so gut etabliert, dass Organisationen die Rolle eines Testarchitekten einführen. Dies nur als Beispiel. Aber Vorsicht: Das richtige Vorgehen und das Wissen über Fallstricke und Best Practices bei der Einführung und Pflege der Testautomatisierung sind ein Schlüssel zum nachhaltigen Erfolg. Entsprechende Expertisen in die Projekte und die Organisation zu bringen, ist nicht immer einfach. Hier unterstützt das Zertifizierungsschema des Certified Tester, das in der Community schon seit Langem als Standard und als gemeinsames Glossar etabliert ist. Der für fortgeschrittene Tester gedachte »Test Automation Engineering«-Kurs, den dieses Buch begleitet, setzt die Schwerpunkte und Erfolgsfaktoren einer nachhaltig erfolgreichen Testautomatisierung in einen Kanon an Expertisen um – wie zum Beispiel über Testautomatisierungsarchitekturen. Und das vorliegende Buch mit seinen vielen Verbesserungen und Änderungen zur zweiten Auflage zeigt deutlich, dass sich dieser Kanon an Skills ständig weiterentwickelt.

Wir sind also gut gerüstet und meines Erachtens mit den Themen der Testautomatisierung einen deutlichen Schritt weiter, und ich wünsche Ihnen gutes Gelingen und auch kreativen Spaß dabei, Testautomatisierung als Schlüsselfaktor für Ihren professionellen Erfolg einzusetzen!

Dr. Armin Metzger

Geschäftsführung

German Testing Board, 2020

Geleitwort zur 2. Auflage1

Seit es uns Menschen auf diesem Planeten gibt, haben wir immer danach getrachtet, mithilfe von Werkzeugen unser Leben zu vereinfachen, Aufgaben schneller zu erledigen und unsere Fähigkeiten zu erweitern. Vom Faustkeil des Steinzeitmenschen über die Erfindung des Rades bis hin zu den hoch technisierten Produktionsmaschinen von heute: Werkzeuge sind ein integraler Bestandteil und Ausdruck unserer Evolutionsgeschichte. Daher ist es kein Wunder und nur ganz natürlich, dass wir solche auch beim Testen von Software einsetzen möchten. Allerdings gibt es über den natürlichen Instinkt hinaus noch weitaus überzeugendere Gründe für den Einsatz von Testwerkzeugen.

Das Erfordernis, Software in besserer Qualität immer schneller und billiger liefern zu können, treibt die Suche nach einfacheren Methoden des Testens voran. Werkzeuge sind dabei eine der effektivsten Möglichkeiten, genau diese Ziele zu erreichen.

Testen ist eine herausfordernde Tätigkeit, die sowohl Denken als auch Aufwand erfordert. Das Denken ist notwendig, um einerseits das zu testende System zu analysieren und andererseits zu identifizieren und zu priorisieren, was getestet werden soll. Darüber hinaus müssen Testfälle geschrieben werden, die Fehler aufzeigen, und der Tester muss entscheiden, wann diese Tests und etwaige Wiederholungen durchgeführt werden. Ohne entsprechende Gedankenarbeit wird der Test kaum erfolgreich Fehler finden und lediglich dazu führen, dass er als ineffektiv, zu teuer und aufwendig wahrgenommen wird.

Softwaresysteme sind immer größer und komplexer geworden. Dies gilt in gleicher Weise für die Anforderungen an das Testen. Das Wachstum für den Testbedarf verläuft somit nicht linear, sondern exponentiell. Wenn zu einem bestehenden System ein neues Feature hinzugefügt wird, ist nicht nur dieses Feature und seine Funktionsfähigkeit zu testen, sondern auch die kombinatorische Explosion der Interaktionen zwischen dem bestehenden System und dem neuen Feature. Und mit jeder Erweiterung wächst die Anzahl möglicher Interaktionen.

Eine Veränderung in einem Teil der Software kann zu neuen Fehlfunktionen führen bzw. bisher unbekannte Defekte in anderen Teilen der Software aufdecken. Daher darf sich der Testumfang nicht nur auf Regressionstests der Veränderung selbst beschränken, sondern muss das gesamte System, inklusive Interaktion zwischen bestehendem System und neuen Features, berücksichtigen. Darüber hinaus müssen viele Tests für mehrere Umgebungen wiederholt werden. Tests werden nicht nur einmal durchgeführt, sondern mehrmals mit jeder neuen Version der Software über die gesamte Nutzungsdauer hinweg.

Diese repetitive Arbeit kann einen solch großen Anteil am Testeinsatz einnehmen, dass für den kreativen Teil des Testens nur mehr wenig Raum bleibt. Darunter leidet die Qualität des Tests und in der Konsequenz die Qualität der Software.

Es ist daher nur verständlich, dass Werkzeuge insbesondere dort eingesetzt werden, wo Tests immer und immer wieder erneut durchgeführt werden müssen – und mag es nur dem Ziel dienen, ausreichendes Testen innerhalb eines akzeptablen Zeitrahmens sicherzustellen. Darüber hinaus vermag der Werkzeugeinsatz dabei zu helfen, immer gründlichere Regressionstests innerhalb eines vorgegebenen Zeitraums durchzuführen. Am reizvollsten ist jedoch der Aspekt, dass Werkzeuge die Regressionstests übernehmen und den Testern damit mehr Freiraum für die kreativen Aspekte des Testens verschaffen. Damit wird neben der Qualität des Tests auch die Effizienz und Effektivität vom Test als Gesamtheit erhöht (der Werkzeuggebrauch kann dabei helfen, mehr Fehler zu finden).

Testwerkzeuge für den Regressionstest zu nutzen, ist nur der erste und augenscheinlichste Schritt, wenn es darum geht, Werkzeuge einzuführen, die letztlich das gesamte Spektrum der Testaktivitäten unterstützen können.

Zusätzlich zu den Vorteilen, die durch die Automatisierung von Regressionstests erreicht werden können, helfen uns Testwerkzeuge dabei, Tests durchzuführen, die rein manuell nicht möglich sind. Damit unterstützen sie uns, detaillierter, tiefgreifender und vielfältiger zu testen.

Es ist leicht nachzuvollziehen, dass der Werkzeugeinsatz im Testbereich großes Potenzial hat. Die Verwendung von Werkzeugen ermöglicht es, Tests mit kürzeren Zeitaufwänden durchzuführen. Außerdem können Tests zu Zeiten erfolgen, zu denen menschliche Tester normalerweise nicht verfügbar sind – etwa in der Nacht und am Wochenende.

Bei all diesen überragenden Vorteilen, warum nutzt dann nicht jeder Werkzeuge für den Softwaretest?

Der Erfolg beim Einsatz von Testwerkzeugen ist nicht automatisch garantiert. In der Tat haben viele Organisationen versucht, Testwerkzeuge einzuführen, und sind dabei kläglich gescheitert. Der unzweckmäßige und uninformierte Werkzeugeinsatz kann großen Schaden anrichten. Selbst das einfachste Tool kann missbräuchlich verwendet werden. Halten Sie sich dafür ein dreijähriges Kind vor Augen, dem wir einen Hammer in die Hand geben – ein einfaches und effektives Werkzeug, das bei unsachgemäßer Handhabung jedoch sehr gefährlich und schädlich sein kann. Wenn wir nicht verstehen, wie wir Werkzeuge gut und adäquat einsetzen, kann das Endresultat darin bestehen, dass wir eher Zeit und Ressourcen verschwenden, als sie zu sparen. Falsch eingesetzte Tools können zudem falsche oder irreführende Informationen liefern.

Das Problem ist, dass Testwerkzeuge – trotz ihres Namens – uns das Testen nicht abnehmen. Sie sind letztlich Werkzeuge, leblose Dinge, des Denkens und der kreativen Analyse nicht fähig. Sie können nicht die Verantwortung für das Testen übernehmen. Sie können lediglich die Aktivität der handelnden Personen unterstützen. Ohne menschlichen Einsatz haben sie keinen Wert.

Um Testwerkzeuge erfolgreich einsetzen zu können, müssen Testautomatisierungsentwickler, Tester und Testmanager die Einsatzmöglichkeiten und Beschränkungen eines jeden verwendeten Werkzeugs kennen. Ein verbreiteter Grund von Testautomatisierungsversagen liegt in unrealistischen Erwartungen begründet. Beispielsweise wird ein Testmanager, der davon ausgeht, im ersten Monat nach Einführung eines Testwerkzeugs doppelt so effektiv bei lediglich der Hälfte der Kosten zu sein, sehr enttäuscht werden.

Testmanager müssen auch den Unterschied zwischen Test- und Automatisierungsfähigkeiten verstehen. Um automatisierte Testfälle zu schreiben braucht es Zeit, Wissen und Fähigkeiten, die sich grundlegend von jenen unterscheiden, die notwendig sind, um zu testen. In gleicher Weise sollten sich die Verantwortlichkeiten für das Testen und die Automatisierung unterscheiden. Testmanager müssen aus ihrer Rolle heraus sicherstellen, dass Einzelpersonen wissen, wann sie sich auf die Automatisierung von Tests und wann auf das Testen als solches konzentrieren sollen.

Testwerkzeuge einzuführen braucht Zeit und führt letztlich dazu, dass sich Testprozesse ändern. Diese Veränderung muss kontrolliert stattfinden, um zu gewährleisten, dass ein koordinierter und konsistenter Zugang die erwünschten Vorteile des Werkzeugeinsatzes sicherstellt und gleichzeitig Fallstricke vermeidet.

Erfolg in der Testautomatisierung bedeutet den Einsatz derselben im Rahmen einer gesamtheitlichen Teststrategie. Damit ist Werkzeugunterstützung und nicht die Übernahme der Testtätigkeiten durch Werkzeuge gemeint.

Qualifizierte Menschen werden immer ein integraler Bestandteil des Testprozesses sein. Jedoch führen die wachsende Größe und Komplexität unserer Systeme und der gestiegene Anspruch an hohe Qualität in kurzer Zeit und mit geringen Kosten dazu, dass der Einsatz von Testwerkzeugen nicht mehr optionaler, sondern essenzieller Bestandteil eines reifen Testprozesses ist.

Wie können wir sicherstellen, diese Werkzeuge gut und weise einzusetzen? Das ist der Sinn und Zweck des vorliegenden Buches.

Egal, ob Sie erst mit Testautomatisierung beginnen wollen oder nach Wegen zur Verbesserung bereits bestehender Automatisierungsansätze suchen – hier sind Sie richtig. Lesen Sie weiter und lernen Sie von den Autoren – erfinden Sie das Rad nicht neu. Nutzen Sie die aus jahrelanger Erfahrung destillierte Weisheit.

Ich wünsche Ihnen viel Erfolg bei Ihren Automatisierungsvorhaben!

Mark Fewster

Grove Software Testing Ltd., 2015

Inhaltsübersicht

1Einführung in die Testautomatisierung und ihre Ziele

2Vorbereitungen für die Testautomatisierung

3Die generische Testautomatisierungsarchitektur

4Risiken und Eventualitäten bei der Softwareverteilung

5Berichte und Metriken

6Überführung des manuellen Testens in eine automatisierte Umgebung

7Verifizierung der Testautomatisierungslösung

8Fortlaufende Optimierung

9Ausblick

Anhang

ASoftwarequalitätsmerkmale

BLast- und Performanztest

CKriterienkatalog zur Testwerkzeugauswahl

DGlossar

EAbkürzungen

FQuellen

Stichwortverzeichnis

Inhaltsverzeichnis

1Einführung in die Testautomatisierung und ihre Ziele

1.1Einleitung

1.1.1Standards und Normen

1.1.2Der Einsatz von Maschinen

1.1.3Mengen und Massen

1.2Was ist unter Testautomatisierung zu verstehen?

1.3Ziele der Testautomatisierung

1.4Erfolgsfaktoren für die Testautomatisierung

1.4.1Testautomatisierungsstrategie

1.4.2Testautomatisierungsarchitektur

1.4.3Testbarkeit des SUT

1.4.4Testautomatisierungsframework

1.5Exkurs: Teststufen und Projektarten

1.5.1Testautomatisierung auf unterschiedlichen Teststufen

1.5.2Einsatzgebiet nach Projektart

2Vorbereitungen für die Testautomatisierung

2.1SUT-Faktoren mit Einfluss auf die Testautomatisierung

2.2Bewertung und Auswahl von Werkzeugen

2.2.1Verantwortlichkeiten

2.2.2Exkurs: Evaluierung von Automatisierungswerkzeugen

2.2.3Exkurs: Evaluieren leicht gemacht

2.2.4Typische Herausforderungen

2.3Auslegung auf Testbarkeit und Automatisierung

3Die generische Testautomatisierungsarchitektur

3.1Einführung in die generische Testautomatisierungsarchitektur (gTAA)

3.1.1Warum eine gute Testautomatisierungsarchitektur so wichtig ist

3.1.2Entwicklung von Testautomatisierungslösungen

3.1.3Die Schichten der gTAA

3.1.4Projektmanagement einer TAS

3.1.5Konfigurationsmanagement einer TAS

3.1.6Unterstützung des Testmanagements und anderer Zielgruppen

3.2Der Entwurf einer TAA

3.2.1Grundlegende Fragestellungen

3.2.2Welcher Ansatz zur Automatisierung von Testfällen soll unterstützt werden?

3.2.3Welche technischen Überlegungen zum SUT sind zu beachten?

3.2.4Überlegungen zu Entwicklungs- und Qualitätssicherungsprozessen

3.3TAS-Entwicklung

3.3.1Kompatibilität zwischen TAS und SUT

3.3.2Synchronisierung zwischen TAS und SUT

3.3.3Wiederverwendbarkeit in einer TAS

3.3.4Unterstützung verschiedener Zielsysteme

3.3.5Exkurs: Realisierung in unterschiedlichen Vorgehensmodellen und Methoden

4Risiken und Eventualitäten bei der Softwareverteilung

4.1Auswahl des Testautomatisierungsansatzes und Planung von Verteilung/Rollout

4.1.1Die Erprobung oder der Pilotversuch

4.1.2Die Verteilung oder das Deployment

4.2Strategie für die Bewertung und Begrenzung von Risiken

4.2.1Spezifische Risiken bei der Erstverteilung

4.2.2Spezifische Risiken bei der Wartungsverteilung

4.3Wartung der Testautomatisierung

4.3.1Auslöser und Arten von Wartungsaktivitäten

4.3.2Überlegungen zur Dokumentation der automatisierten Testmittel

4.3.3Der Umfang von Wartungsaktivitäten

4.3.4Wartung von Fremdkomponenten

4.3.5Wartung von Schulungsmaterial

4.3.6Verbesserung der Wartbarkeit

4.4Exkurs: Einsatzgebiet nach Systemarten

4.4.1Desktop-Applikationen

4.4.2Client-Server-Systeme

4.4.3Webapplikationen

4.4.4Mobile Applikationen

4.4.5Webservices

4.4.6Data Warehouse

4.4.7Dynamische GUIs: Formularlösungen

4.4.8Cloud Based Systems

4.4.9Künstliche Intelligenz und Machine Learning

5Berichte und Metriken

5.1Exkurs: Metriken und Validität

5.2Beispiele für Metriken

5.3Konkrete Implementierung und Realisierbarkeit in einer TAS

5.3.1Exkurs: TAS und SUT als Quellen für Protokolle

5.3.2Exkurs: Zentralisierte Verwaltung und Auswertung von Protokollen

5.3.3Implementierung der Protokollierung in einer TAS

5.4Erstellung von Berichten zur Testautomatisierung

5.4.1Qualitätskriterien für Berichte

6Überführung des manuellen Testens in eine automatisierte Umgebung

6.1Kriterien für die Automatisierung

6.1.1Eignungskriterien für die Umstellung auf automatisierte Tests

6.1.2Vorbereitung der Umstellung auf automatisierte Tests

6.2Erforderliche Schritte zur Automatisierung von Regressionstests

6.3Faktoren bei der Automatisierung des Testens neuer oder geänderter Funktionen

6.4Faktoren bei der Automatisierung von Fehlernachtests

7Verifizierung der Testautomatisierungslösung

7.1Warum die Qualitätssicherung einer TAS wichtig ist

7.2Verifizieren der Komponenten der automatisierten Testumgebung

7.3Verifizieren der automatisierten Testsuite

8Fortlaufende Optimierung

8.1Möglichkeiten der Optimierung der Testautomatisierung

8.2Planung und Realisierung der Testautomatisierungsverbesserung

9Ausblick

9.1Herausforderungen in der Testautomatisierung

9.1.1Allgegenwärtige Vernetzung

9.1.2Testautomatisierung für die IT-Sicherheit

9.1.3Testautomatisierung für autonome Systeme

9.2Trends und mögliche Entwicklungen

9.2.1Agile Softwareentwicklung ohne Testautomatisierung ist nicht denkbar

9.2.2Neue Outsourcing-Szenarien für die Automatisierung

9.2.3Die Automatisierung der Automatisierung

9.2.4Ausbildung und Standardisierung

9.3Innovation und Weiterentwicklung

Anhang

ASoftwarequalitätsmerkmale

A.1Funktionalität (functional suitability)

A.2Performanz (performance efficiency)

A.3Kompatibilität (compatibility)

A.4Benutzbarkeit (usability)

A.5Zuverlässigkeit (reliability)

A.6Sicherheit (security)

A.7Wartbarkeit (maintainability)

A.8Übertragbarkeit (portability)

BLast- und Performanztest

B.1Arten von Last- und Performanztests

B.2Tätigkeiten im Last- und Performanztest

B.3Definieren der Performanzziele

B.4Identifizieren der Transaktionen bzw. Szenarien

B.5Erstellen der Testdaten

B.6Erstellung von Testszenarien

B.7Durchführung der Tests

B.8Monitoring

B.9Typische Komponenten von Last- und Performanzwerkzeugen

B.10Checklisten

CKriterienkatalog zur Testwerkzeugauswahl

DGlossar

EAbkürzungen

FQuellen

Stichwortverzeichnis

1Einführung in die Testautomatisierung und ihre Ziele

Die Softwareentwicklung als Ganzes erlebt eine Entwicklung hin zu einer industriellen Disziplin. Die zunehmende Digitalisierung der Geschäftsprozesse sowie die vermehrte Verbreitung von Standardprodukten und -services sind wesentliche Treiber für den Einsatz von immer effizienteren und effektiveren Methoden im Softwaretest, also auch in der Testautomatisierung. Die rasante Expansion mobiler Applikationen und die sich stetig ändernde Vielfalt der Endgeräte prägen diese Entwicklung ebenfalls nachhaltig.

1.1Einleitung

Ein wesentliches Merkmal der fortschreitenden Industrialisierung seit dem Ende des 18. Jahrhunderts ist die Mechanisierung energie- oder zeitaufwendiger manueller Tätigkeiten in fast allen Produktionsprozessen. Was vor mehr als 200 Jahren mit mechanischen Webstühlen und Dampfmaschinen in den Textilfabriken Englands begann, ist heute das höchste Ziel und gelebte Praxis in allen produzierenden Unternehmen: die kontinuierliche Steigerung und Optimierung der Produktivität. Ziel ist es stets, mit möglichst geringem Mitteleinsatz das gewünschte Ergebnis in Quantität, Qualität und Zeit zu erreichen. Der Einsatz von Ressourcen bezieht sich sowohl auf den Einsatz menschlicher Arbeitskraft als auch auf den Einsatz von Maschinen, Arbeitsmitteln und anderen (Energie-)Ressourcen.

Im Bestreben, immer besser zu werden und im globalen Konkurrenzdruck zu bestehen, gibt es keinen Industriebetrieb, der sich nicht laufend mit Optimierungen im Produktionsprozess beschäftigen muss. Vorbild und bestes Beispiel dafür ist die Automobilindustrie, die zu den Themen Prozesssteuerung, Produktionsgestaltung und -messung sowie Qualitätsmanagement immer wieder neue Ideen und Ansätze – auch für andere Industriezweige – hervorgebracht hat und auch weiter hervorbringt. Ein Blick in die Produktions- und Fertigungshallen eines Automobilherstellers beeindruckt durch die Präzision des Zusammenspiels zwischen Mensch und Maschine sowie den reibungslosen, hochautomatisierten Fabrikationsablauf. Ein ähnliches Bild zeigt sich mittlerweile in vielen anderen Produktionsprozessen.

Softwareentwicklung und Softwaretest auf dem Weg zur industriellen Produktionsreife

Eine nicht unbedingt rühmliche Ausnahme stellt jedoch die Industrie der Softwareentwicklung dar. Trotz vieler Verbesserungen und Bemühungen der letzten Jahre und Jahrzehnte ist diese von der Professionalität der Fertigungsprozesse anderer Branchen immer noch weit entfernt. Dies ist insofern verwunderlich, wenn nicht sogar bedenklich, als Software jene Technologie ist, die in den letzten Jahrzehnten wohl die größte Auswirkung auf gesellschaftliche, wirtschaftliche und technische Veränderungen hatte. Vielleicht liegt es daran, dass die Softwareindustrie noch eine junge Disziplin ist und somit auch nicht die Reife anderer erreichen konnte. Vielleicht liegt es auch am immateriellen Charakter von Softwaresystemen mit all der technologischen Vielfalt, die es generell schwierig macht, Standards zu definieren und konsequent umzusetzen. Oder vielleicht liegt es daran, dass viele die Softwareentwicklung immer noch mehr im Zusammenhang mit künstlerischer Kreativität sehen als mit einer Ingenieurdisziplin.

Auch in den internationalen Standards hat sich die Softwareentwicklung erst als industrieller Zweig etablieren müssen. So findet sich z. B. in der Revision 4 der International Standard Industrial Classification of All Economic Activities (ISIC), veröffentlicht im August 2008, die neue Sektion J »Information and Communication«, während in der Vorgängerversion des Standards die Softwareentwicklungsleistungen noch auf unterster Ebene einer Sektion »Real estate, renting and business activities« versteckt waren [ISIC 08; NACE 08].

Softwareentwicklung als industrielle Einzelfertigung

Das Argument der jungen Disziplin wird jedoch jedes Jahr schwächer. Dennoch wird Softwareentwicklung immer noch gerne als eher künstlerische als ingenieurmäßige Tätigkeit gesehen und wäre demnach anders zu bewerten als die identische Reproduktion zigtausender Türbeschläge. Aber auch wenn Softwareentwicklung nicht den Prozessen einer Massenfertigung unterliegt, so ist diese heutzutage dennoch als industrielle Einzelfertigung zu definieren.

Was bedeutet aber »industriell« in diesem Zusammenhang? Ein industrieller Prozess ist durch mehrere Merkmale gekennzeichnet, insbesondere durch die breite Anwendung von Standards und Normen, den intensiven Einsatz von Mechanisierung und den Umstand, dass es meist um die Bewältigung von großen Mengen und Massen geht. Entlang dieser Merkmale wird auch die Wandlung der Softwareentwicklung von der Kunst hin zu einer professionellen Disziplin deutlich.

1.1.1Standards und Normen

Seit den Anfängen der Softwareentwicklung gab es eine ganze Reihe von Ansätzen auf der Suche nach dem idealen Entwicklungsprozess. Viele dieser Ansätze waren für ihre Zeit und Rahmenbedingungen zweckmäßig und »State of the Art«. Die rasante Entwicklung der technischen Innovationen, die exponentielle Zunahme fachlicher und anwendungsbezogener Komplexitäten und die ständig wachsenden wirtschaftlichen Herausforderungen bedingen eine laufende Anpassung der bei der Softwareentwicklung eingesetzten Verfahren, Sprachen und Vorgehensmodelle: Wasserfall, V-Modell, iterative und agile Softwareentwicklung; ISO 9001:2008, ISO 15504 (SPICE), CMMI, ITIL; unstrukturierte, strukturierte, objektorientierte Programmierung, ISO/IEC/IEEE 29119 Software Testing – und das Ende der Fahnenstange ist noch lange nicht erreicht. Auch die Disziplin des Softwaretestens im engeren Sinne hat sich vor allem in den letzten Jahren stark verändert. Seit der Gründung des International Software Testing Qualifications Board (ISTQB®) im November 2002 und der damit initiierten, standardisierten Ausbildung zum Certified Tester in den verschiedenen Modulen und Ausbildungsstufen hat sich ein neues Berufs- und Rollenbild des Softwaretesters entwickelt und international etabliert [URL: ISTQB]. Das ISTQB® Ausbildungsprogramm wurde und wird laufend erweitert und aktualisiert und umfasst mit Stand 2020 folgendes Portfolio:

Abb. 1–1ISTQB®-Produktportfolio (Stand 2020)

Dennoch steckt die Disziplin des Softwaretestens im Vergleich zu anderen Ingenieurdisziplinen und ihrer meist Jahrhunderte oder Jahrtausende alten Tradition und Entwicklung noch in den Kinderschuhen. Dies betrifft nicht nur die inhaltliche Ausgestaltung oder etwa die Durchdringung in Lehre und Praxis.

Einer der Hauptgründe, warum Softwareprojekte trotz vieler Erfahrungen, die sich in Standards manifestieren, immer noch in großem Stil – nachvollziehbar oder nicht – in den Misserfolg schlittern, ist die Tatsache, dass alle bekannten »Best Practices« der Softwareentwicklung weitgehend unverbindlich sind. Wer heute ein Softwareprodukt bestellt, kann sich nicht a priori auf einen überprüfbaren Fertigungsstandard verlassen.

Es ist nicht nur so, dass grundsätzlich jedes Unternehmen selbst entscheidet, ob es bestimmte Produkt- und Entwicklungsstandards anwendet oder nicht, sondern es ist vielerorts auch eine geduldete Praxis, dass diese Unverbindlichkeit auch innerhalb des Unternehmens fortgeführt wird: Jedes Projekt ist ja anders. Das »not invented here«-Syndrom ist und bleibt ein ständiger Begleiter von Softwareentwicklungsprojekten [Katz & Allen 1982].

Noch fehlen in der Testautomatisierung vielfach Normen und Standards.

Auch im Bereich der Testautomatisierung unterliegen technische Konzepte eher selten allgemeinen Normen. Vielmehr bestimmen die Hersteller kommerzieller Werkzeuge oder Open-Source-Communitys den aktuellen Stand der Technik. Diesen beiden Parteien geht es jedoch weniger um die Schaffung eines allgemein gültigen Standards als vielmehr um die Generierung eines Wettbewerbsvorteils am Markt oder die Umsetzung kollektiver Ideen. Denn durch Standards werden Werkzeuge grundsätzlich austauschbar – und welches Unternehmen möchte schon gerne seine Marktposition durch die Schaffung eines Standards schwächen? Eine Ausnahme stellt hier die Testing and Test Control Notation (TTCN-3) des European Telecommunication Standards Institute (ETSI) dar [URL: ETSI]. Die Anwendung dieses Standards ist in der Praxis jedoch im Wesentlichen auf sehr spezifische Einsatzgebiete beschränkt, zum Beispiel in den Telekommunikations- und Automotive-Sektoren.

Für ein Unternehmen, das eine Testautomatisierung einführt, bedeutet dies in der Regel eine enge Bindung an einen Werkzeughersteller. Auch in Zukunft wird es nicht möglich sein, eine umfassende, automatisierte Testsuite einfach von einem Werkzeug auf ein anderes zu übertragen, da sich gemeinhin sowohl die technologischen Konzepte als auch die Automatisierungsansätze stark unterscheiden. Dies gilt auch für die Investitionen in die Ausbildung des Personals, die ebenfalls eine stark werkzeugbezogene Komponente enthält.

Dennoch gibt es einige allgemeine Prinzipien bei der Konzeption, Organisation und Durchführung von automatisierten Softwaretests. Diese Faktoren unterstützen dabei, die Abhängigkeit von bestimmten Werkzeugen zu reduzieren und die Produktivität bei der Automatisierung zu optimieren.

Die Ausbildung zum ISTQB® Certified Tester Advanced Level Testautomatisierungsentwickler und dieses Buch, in das die Autoren auch ihre praktischen Erfahrungen eingebracht haben, bieten eine Einführung in diese grundsätzlichen Aspekte und Prinzipien sowie eine Anleitung bzw. Empfehlungen zur Umsetzung eines Testautomatisierungsprojekts.

1.1.2Der Einsatz von Maschinen

Ein weiteres wesentliches Merkmal der industriellen Fertigung ist der Einsatz von Maschinen zur Erleichterung und Reduktion von manuellen Tätigkeiten. In der Softwareentwicklung sind diese Maschinen selbst wiederum Software. Dazu zählen etwa Entwicklungsumgebungen, die die Erstellung und Verwaltung des Programmcodes und weiterer Softwarebestandteile vereinfachen bzw. erst ermöglichen. Im Prinzip sind dies jedoch meist nur Bearbeitungs- und Verwaltungssysteme mit gewissen Kontrollmechanismen, wie sie etwa ein Compiler durchführt. Die Programme müssen immer noch »mit Hand und Verstand« geschrieben werden. Eine »Mechanisierung« der Programmierung ist das Ziel der modellbasierten Ansätze, in denen die mühsame Arbeit der Codierung von Generatoren erledigt wird. Ausgangsbasis für die Codegenerierung sind Modelle des zu entwickelnden Softwaresystems, z.B. in der UML-Notation. In einigen Bereichen wird diese Technologie bereits umfassend eingesetzt, etwa zur Generierung von Datenzugriffsroutinen oder dort, wo Spezifikationen in formalen Sprachen vorliegen, wie etwa bei der Entwicklung von eingebetteten Systemen. In der Breite jedoch ist Softwareentwicklung immer noch pures Handwerk.

Die Mechanisierung im Softwaretest

Einsatz von Werkzeugen zur Testfallgenerierung und Testdurchführung

Eine Aufgabe des Softwaretesters ist die Identifikation von Testbedingungen und der Entwurf von Testfällen. Ähnlich den Ansätzen zur modellbasierten Entwicklung zielt das modellbasierte Testen (MBT) auf die automatische Ableitung von Testfällen aus vorhandenen Modellbeschreibungen des Systems unter Test (SUT) ab. Als Ausgangsbasis dienen z.B. Objektmodelle, Use-Case-Beschreibungen und Ablaufgraphen in verschiedenen Notationen. Durch Anwendung eines semantischen Regelwerks werden fachliche Testfälle auf Basis textueller Spezifikationen abgeleitet. Und nicht zuletzt generieren entsprechende Parser aus dem Quellcode selbst abstrakte Testfälle, die dann zu konkreten Testfällen verfeinert werden. Für die Verwaltung dieser Testfälle steht eine Vielzahl geeigneter Testmanagementwerkzeuge zur Verfügung, die in die unterschiedlichen Entwicklungsumgebungen integriert sind. Ähnlich der Generierung von Code aus den Modellen ist auch die Generierung von Testfällen aus Testmodellen noch nicht sehr weit verbreitet. Ein Grund dafür ist der Umstand, dass das Ergebnis, der generierte Testfall, im hohen Grad von der Qualität und der »passenden« Beschreibungstiefe der Modelle abhängt. Diese sind zumeist nicht zufriedenstellend gegeben.

Eine weitere Aufgabe des Softwaretesters ist die Durchführung und Protokollierung der Testfälle. An dieser Stelle ist zu unterscheiden, ob es sich um Tests handelt, die auf der Ebene technischer Schnittstellen, Systemkomponenten, Module oder Methoden durchgeführt werden, oder um fachliche, anwenderbezogene Tests, die eher über die Benutzerschnittstelle erfolgen. Für erstere werden bereits vorwiegend technische Hilfsmittel eingesetzt: Testrahmen, Testtreiber, Unit-Test-Frameworks, Hilfsprogramme etc. Diese Tests werden auch fast immer von »Technikern« durchgeführt, die sich die »mechanischen Hilfsmittel« selbst bereitstellen können. Der fachliche Test wurde und wird zum überwiegenden Teil von Mitarbeitern aus den Fachbereichen oder dedizierten Testanalysten manuell ausgeführt. Für diesen Bereich stehen ebenfalls Werkzeuge zur Unterstützung und Erleichterung der manuellen Testdurchführungen zur Verfügung. Deren Einsatz ist jedoch mit entsprechenden Kosten und Lernaufwänden verbunden. Dies ist mit ein Grund dafür, dass der Einsatz von Testautomatisierungswerkzeugen in der Vergangenheit keine allgemeine Verbreitung gefunden hat. Die Weiterentwicklung dieser Werkzeuge hat in den letzten Jahren jedoch zu einer deutlichen Verbesserung der Kosten-Nutzen-Relation geführt. Die vereinfachte Erstellung eines automatisierten Testfalls sowie seine einfachere Wartbarkeit durch die zunehmende Trennung von fachlicher Logik und technischer Implementierung führten dazu, dass sich Automatisierung nicht erst dann rechnet, wenn riesige Mengen von Testfällen durchzuführen oder der x-te Regressionstest zu wiederholen sind, sondern bereits bei der erstmaligen automatisierten Durchführung von manuell aufwendigen Tests.

1.1.3Mengen und Massen

Während in der Programmierung eine beschränkte Anzahl von Programmen oder Objekten und Methoden einmal entwickelt wird und dann bestenfalls noch adaptiert bzw. korrigiert werden muss, ist im Test theoretisch eine fast grenzenlose Anzahl an Testfällen möglich. In der Praxis gehen die Testfallanzahlen meist in die Hunderte oder Tausende. Eine einmal entwickelte Eingabemaske und ein einmal entwickelter Verarbeitungsalgorithmus muss im Test unzählige Male getestet werden, z.B. durch verschiedene Eingabe- und Dialogvariationen oder etwa durch die Erfassung von hundert Verträgen mit unterschiedlichen Tarifen im datengetriebenen Test. Diese Tests sind aber nicht nur ein einziges Mal zu erstellen und durchzuführen. Mit jeder Änderung am System müssen Regressionstests durchgeführt und angepasst werden, um die Funktionsfähigkeit des Systems nachzuweisen. Um eventuell entstandene Nebeneffekte von Änderungen zu erkennen, ist jedes Mal eine möglichst große Testüberdeckung anzustreben, die aber erfahrungsgemäß aus Kosten- und Zeitgründen meist nicht erreicht werden kann.

Der notwendige Testumfang kann nur mit dem Einsatz von Automaten bewältigt werden.

Diese Ausgangslage, die notwendige Bewältigung von großen Mengen und Massen, schreit förmlich nach dem Einsatz der industriellen Mechanisierung, nach dem Einsatz von Testautomatisierungslösungen. Und wenn die Lage nicht schreit, so tun dies die Tester, die im Gegensatz zu einer Maschine bei der zehnten Durchführung desselben Testfalls menschliche Reaktionen wie Frustration, mangelnde Konzentration oder Ungeduld zeigen. Individuelle Priorisierungen lassen dann unter Umständen gerade die falschen, weil erfolgskritischsten Testfälle unter den Tisch fallen.

Betrachtet man die obigen Punkte, ist es eigentlich verwunderlich, dass Testautomatisierung nicht schon längst durchgängig im Einsatz ist. Fehlende Standardisierungen, bisherige unattraktive Kosten-Nutzen-Rechnungen und der Entwicklungsstand der Werkzeuge mögen Gründe dafür gewesen sein. Heutzutage führt jedoch an der Testautomatisierung kein Weg mehr vorbei. Der Anstieg der Komplexität der Softwaresysteme und der dadurch erhöhte Testbedarf, der steigende Druck auf Zeit und Kosten sowie die wachsende Verbreitung agiler Entwicklungsansätze und mobiler Applikationen zwingen Unternehmen regelrecht, bei der Softwareentwicklung auf eine nachhaltige Testautomatisierung zu setzen.

1.2Was ist unter Testautomatisierung zu verstehen?

In der Definition des ISTQB® ist unter Testautomatisierung der »Einsatz von Softwarewerkzeugen zur Durchführung oder Unterstützung von Testaktivitäten, z.B. Testmanagement, Testentwurf, Testausführung und Soll/Ist-Vergleich« zu verstehen. Man könnte auch sagen, »Testautomatisierung ist die Durchführung von ansonsten manuellen Testtätigkeiten durch Automaten bzw. Maschinen«. Das Spektrum umfasst demnach alle Tätigkeiten zur Überprüfung der Softwarequalität im Entwicklungsprozess, in den unterschiedlichen Entwicklungsphasen und Teststufen sowie die entsprechenden Aktivitäten von Entwicklern, Testern, Analytikern oder auch der in die Entwicklung eingebundenen Anwender.

Testautomatisierung bedeutet demnach nicht nur die Ausführung einer Testsuite, sondern umfasst den gesamten Prozess der Bereitstellung und Erstellung aller Testmittel, d.h. der Arbeitsergebnisse, die für die Planung, den Entwurf, die Ausführung, die Auswertung und die Berichterstattung über automatisierte Tests erforderlich sind.

Relevante Testmittel sind unter anderem:

Software

Für die Verwaltung, den Entwurf, die Implementierung, die Durchführung und die Auswertung von automatisierten Testsuiten ist eine Reihe von Werkzeugen (Automatisierungswerkzeuge, Testrahmen, Virtualisierungslösungen etc.) erforderlich. Die Auswahl und Bereitstellung dieser Werkzeuge ist eine komplexe Aufgabe, die von der Technologie und dem Umfang des SUT und der gewählten Testautomatisierungsstrategie abhängt.

Dokumentation

Dazu gehört nicht nur die Dokumentation der verwendeten Testwerkzeuge, sondern auch alle verfügbaren fachlichen und technischen Beschreibungen sowie der Architektur und der Schnittstellen des SUT.

Testfälle

Die fachlichen Testfälle, abstrakt oder konkret, bilden die Grundlage für die Implementierung automatisierter Tests. Deren Auswahl bzw. Priorisierung und funktionale Qualität (z.B. fachliche Relevanz, funktionale Überdeckung, Korrektheit) sowie die Qualität ihrer Beschreibung haben einen wesentlichen Einfluss auf das langfristige Kosten-Nutzen-Verhältnis der Testautomatisierungslösung (TAS – Test Automation Solution) und damit unmittelbar auf ihre Nachhaltigkeit.

Testdaten

Die Testdaten sind der Treibstoff für die Testdurchführung. Sie werden zur Steuerung der Testszenarien sowie zur Berechnung und Verifizierung der Testergebnisse verwendet. Sie stellen dynamische Eingabedaten, feste oder variable Parameter und (Konfigurations-)Daten dar, auf denen die Verarbeitung basiert. Die Erzeugung, Produktion und Wiederherstellung von Bestands- und Verarbeitungsdaten für und durch die Testautomatisierung erfordert besondere Aufmerksamkeit. Falsche Testdaten, wie fehlerhafte Testskripte, führen zu falschen Testergebnissen und können den Testfortschritt stark behindern. Auf der anderen Seite bieten die Testdaten die Möglichkeit, das Potenzial der Testautomatisierung voll auszuschöpfen. Die Bedeutung, aber auch die Komplexität eines effizienten und gut organisierten Testdatenmanagements spiegelt sich auch in der Ausbildung zum GTB Certified Tester Foundation Level Test Data Specialist [GTB 18] wider.

Testumgebungen

Der Aufbau von Testumgebungen ist in der Regel eine sehr komplexe Aufgabe und natürlich stark abhängig von der Komplexität des SUT sowie von den technischen und organisatorischen Rahmenbedingungen im Unternehmen. Es ist daher wichtig, den Betrieb, das Testumgebungsmanagement, das Applikationsmanagement etc. rechtzeitig mit allen Beteiligten zu diskutieren. Es ist zu klären, wer und in welcher Form das SUT, die benötigten Drittsysteme, die Datenbanken und die Testautomatisierungslösung selbst in der Testumgebung bereitstellt, alle erforderlichen Zugriffsrechte gewährt und die Ausführung überwacht.

Die Testautomatisierungslösung sollte nach Möglichkeit vom SUT getrennt sein, um gegenseitige Beeinflussung zu vermeiden. Ausnahmen sind z.B. eingebettete Systeme, bei denen die Testsoftware in das SUT integriert werden muss.

Obwohl sich der Begriff »Testautomatisierung« grundsätzlich auf alle Aktivitäten im Testprozess bezieht, wird in der Praxis gemeinhin die automatisierte Ausführung von Tests mithilfe spezieller Werkzeuge oder Software mit diesem Begriff in Verbindung gebracht.

Dabei werden eine oder mehrere Aufgaben, wie sie auch für die Durchführung dynamischer Tests definiert sind [Spillner & Linz 19], auf Basis der genannten Testmittel ausgeführt:

Die automatisierten Testfälle auf der Grundlage der vorhandenen Spezifikationen, der fachlichen Testfälle und des SUT implementieren und sie mit Testdaten versorgen.

Die definierten Vorbedingungen für die automatisierte Durchführung herstellen und steuern.

Die automatisierten Testsuiten ausführen, steuern und überwachen.

Die Ergebnisse der Ausführung – d.h. den Vergleich der tatsächlichen mit den erwarteten Ergebnissen – protokollieren, auswerten und entsprechende Berichte bereitstellen.

Aus technischer Sicht kann die Implementierung von automatisierten Tests auf verschiedenen Architekturebenen ansetzen. Unter dem Gesichtspunkt, die manuelle Testausführung zu ersetzen, greift die Automatisierung auf die Elemente der grafischen Benutzungsoberfläche (GUI-Test) oder – je nach Art der Anwendung – auf die Kommandoschnittstelle des SUT (CLI-Test) zu. Geht man eine Ebene tiefer, kann die Automatisierung über die öffentlichen Schnittstellen der Klassen, Module und Bibliotheken des SUT (API-Test) und über entsprechende Dienste (Servicetest) und Protokolle (Protokolltest) implementiert werden. Testfälle, die auf dieser tieferen Architekturebene umgesetzt werden, haben den Vorteil, dass sie weniger empfindlich auf (häufige) Änderungen der Benutzungsschnittstellen reagieren. Neben der wesentlich höheren Wartungsfreundlichkeit hat dieser Ansatz in der Regel auch einen deutlichen Performanzvorteil gegenüber einer GUI-basierten Automatisierung. Selbst vor der eigentlichen Verteilung der Software auf eine Laufzeitumgebung können wertvolle Tests durchgeführt werden: Mit Unit-Tests kann für jeden Build die automatisierte Prüfung der einzelnen Softwarekomponenten durchgeführt werden, noch bevor eine vollständige Integration und Paketierung in ein Softwareprodukt durchgeführt wird. Die Pyramide der Testautomatisierung nach Mike Cohn veranschaulicht die angestrebte Verteilung der automatisierten Tests auf der Grundlage ihrer Kosten-Nutzen-Effizienz über die Zeit [URL: Cohn].

Abb. 1–2Pyramide der Testautomatisierung

1.3Ziele der Testautomatisierung

Die Einführung einer Testautomatisierung ist in der Regel mit einer Reihe von Zielen und Erwartungen verbunden – denn bei allen Vorteilen ist und bleibt Automatisierung kein Selbstzweck. Zu den Zielen gehören zunächst einmal die Steigerung der Testeffizienz und damit die Senkung der Gesamtkosten für den Test. Weitere wichtige Faktoren sind die Verkürzung der Testausführungszeit/Testzyklen und die sich daraus ergebende Möglichkeit, die Häufigkeit der Testausführungen zu erhöhen. Dies ist besonders für die Ansätze DevOps und DevTestOps wichtig. Continuous Integration, Continuous Deployment und Continuous Testing können nur mit einer gut funktionierenden Testautomatisierungslösung effektiv realisiert werden.

Neben der Kostenreduktion und Zeitverkürzung ist die Steigerung bzw. Aufrechterhaltung der Qualität ein wichtiges Ziel der Testautomatisierung. Die Qualität kann durch eine Erhöhung der Funktionsüberdeckung und durch die Implementierung von Tests erreicht werden, die nicht oder nur mit großem Ressourcenaufwand manuell durchgeführt werden können. Beispiele hierfür sind der Test einer sehr großen Anzahl relevanter Datenkonstellationen oder -variationen, das Testen auf Fehlertoleranz, d.h. die Testausführung auf API-/Service-Ebene mit fehlerhaften Eingabedaten, um die Robustheit des SUT zu bewerten, oder auch der Performanztest in seinen verschiedenen Ausprägungen. Aber auch die einheitliche und wiederholte Ausführung ganzer Testsuiten gegen verschiedene Versionen des SUT (Regressionstest) in verschiedenen Umgebungen (unterschiedliche Browser und Versionen, Vielzahl mobiler Endgeräte etc.) ist nur unter Einsatz von Testautomatisierung wirtschaftlich machbar.

Vorteile der Testautomatisierung

Einer der größten Vorteile und Nutzen der Testautomatisierung ergibt sich durch den Aufbau einer automatisierten Regressionstestsuite, die es ermöglicht, mehr und mehr Testfälle je Softwarerelease durchzuführen. Ein manueller Regressionstest stößt sehr rasch an die Grenzen der Machbarkeit und Wirtschaftlichkeit. Zudem verliert er durch die nachlassende Konzentration und Motivation der Tester von Mal zu Mal an Effektivität und bindet wertvolle manuelle Ressourcen. Demgegenüber laufen automatisierte Tests schneller ab, sind weniger anfällig für Bedienerfehler und auch komplexere Testszenarien können – einmal konzentriert erstellt – wiederholt durchgeführt werden. Bei der manuellen Testdurchführung muss oft jedes Mal sehr viel Zeit investiert werden, um komplexere Testsequenzen wieder zu verstehen und in gleicher Qualität auszuführen.

Bestimmte Tests sind manuell auch kaum bzw. gar nicht durchführbar. So können automatisiert relativ einfach verteilte und parallele Tests implementiert und durchgeführt werden, zum Beispiel für die Durchführung von Last-, Performanz- und Stresstests. Auch Echtzeittests etwa in der Steuerungstechnik benötigen zwingend entsprechende Werkzeuge.

Da die automatisierten Testfälle und Testszenarien auf Basis eines einheitlichen Frameworks erstellt werden, einheitlich formal beschrieben sind, also im Gegensatz zum manuellen Testfall keinen Interpretationsspielraum zulassen, und quasi immer »stimmen« müssen, erhöhen sich zum einen die Konsistenz und Wiederholbarkeit der Tests und zum anderen die Ausfallsicherheit des SUT.

Auch aus Projektsicht ergeben sich wesentliche Vorteile durch den Einsatz einer Testautomatisierung. Die unmittelbare Rückmeldung bezüglich der Qualität des SUT beschleunigt den Projektverlauf deutlich. Vorhandene Probleme werden innerhalb von Stunden und nicht nach mehreren Tagen oder Wochen aufgezeigt und können behoben werden, bevor die Aufwände für die Korrekturen noch höher werden.

Die Testautomatisierung ermöglicht auch die effizientere und effektive Nutzung von Testressourcen. Damit sind nicht nur technische Infrastrukturen gemeint. Ein großer Vorteil ist das Freiwerden von Testern, auch aus den Fachbereichen, durch die Automatisierung der Regressionstests. Dadurch können sich diese Tester verstärkt der Fehlerfindung z.B. durch exploratives Testen oder dem gezielten Einsatz diverser Testverfahren im dynamischen, manuellen Test widmen.

Nachteile der Testautomatisierung

Natürlich bringt die Testautomatisierung nicht nur Vorteile, sondern auch den einen oder anderen Nachteil mit sich bzw. Aspekte, die man im Vorfeld kennen sollte, um hinterher nicht negativ überrascht zu werden.

Die Automatisierung von Prozessen ist immer mit zusätzlichen Kosten verbunden, die Testautomatisierung bildet hier keine Ausnahme. Zu den Anfangsinvestitionen, die für den Aufbau und die Inbetriebnahme einer Testautomatisierungslösung erforderlich sind, gehören Werkzeuge (bspw. für die Testdurchführung), die angeschafft oder entwickelt werden müssen, die Arbeitsplatzausstattung für die Testautomatisierungsentwickler (TAE), die in der Regel mehrere Rechner oder Bildschirme (Entwicklungsrechner, Ausführungsrechner) umfasst, die Aufrüstung der Testumgebungen, die Etablierung neuer Prozesse und Arbeitsschritte, die für die Entwicklung von Testskripten notwendig werden, zusätzliche Konfigurationsmanagement- und Versionierungssysteme u.v.m.

Neben der Investition in zusätzliche Technologien oder Prozesse müssen auch Zeit und Geld in den Ausbau der Kompetenzen des Testteams investiert werden. Dazu gehören die Ausbildung zum Testautomatisierungsentwickler und die Weiterbildung im Bereich der Softwareentwicklung sowie die Schulung für den Einsatz der Testautomatisierungslösung und der eingesetzten Werkzeuge.

Häufig unterschätzt wird auch der Aufwand für die Wartung der Testautomatisierungslösung und der automatisierten Testmittel, allen voran natürlich der Testskripte. Letztlich erzeugt die Testautomatisierung selbst Software, die gewartet werden muss. Eine ungeeignete Architektur, Nichteinhaltung von Konventionen, unzureichende Dokumentation und fehlendes Konfigurationsmanagement wirken sich dramatisch aus, sobald die automatisierte Testsuite ein bestimmtes Niveau erreicht hat. Änderungen und Erweiterungen finden immer statt. Das SUT ändert sich an der Benutzerschnittstelle, in den Prozessen, in den technischen Aspekten, den Geschäftsregeln usw. Und diese Änderungen wirken sich direkt und unmittelbar auf die Testautomatisierungslösung oder die automatisierten Testmittel aus.

Es ist nicht ungewöhnlich, dass der Testautomatisierungsentwickler von diesen Änderungen erst »in der Produktion« erfährt, nämlich dann, wenn bei der Testausführung eine Abweichung auftritt. Diese Abweichung wird gemeldet und dann vom Entwickler als Fehler der TAS (ein sogenanntes falsch positives Ergebnis) zurückgewiesen. Aber dies ist nicht das einzige Szenario, in dem die TAS zu Fehlern führt, denn, wie gesagt, die TAS ist auch nur Software – und Software ist in den allermeisten Fällen fehlerhaft.

Aus diesem Grund fokussieren sich die Testautomatisierungsentwickler oft zu sehr auf die technischen Aspekte der TAS und lassen sich von den eigentlichen, qualitativen Testzielen, die für die erforderliche Überdeckung des SUT notwendig sind, ablenken.

Ist eine TAS erst einmal etabliert und leistet gute Dienste, unterliegen Tester allzu gerne der Verlockung, alles automatisieren zu wollen, z.B. umfangreiche Ende-zu-Ende-Tests, ineinander verwobene Dialogsequenzen oder eine komplizierte Verarbeitung. Das klingt nach einer großartigen Sache, aber man muss sich des Aufwands bewusst sein, der mit der Implementierung und Wartung von automatisierten Tests verbunden ist. Allein die Erstellung und Pflege von konsistenten Testdaten über mehrere Systeme hinweg für umfangreiche Ende-zu-Ende-Tests ist in vielen Situationen eine große Herausforderung.

Beschränkungen und Grenzen der Testautomatisierung

Auch die Testautomatisierung hat ihre Grenzen. Technisch gesehen ist vieles möglich, aber manchmal stehen die Kosten für die Automatisierung bestimmter manueller Tests in keinem Verhältnis zum Nutzen.

Ein Automat kann nur tatsächliche, maschineninterpretierbare Ergebnisse prüfen und benötigt dafür ein Testorakel, das ebenfalls automatisiert sein muss. Die Stärke der Testautomatisierung liegt sicherlich in der Verifikation, dem exakten Vergleich von erwartetem mit dem tatsächlichen Verhalten des SUT. Die Schwäche liegt in der Validierung des Systems, der Bewertung der Eignung für die beabsichtigte Nutzung. Fehler in den Anforderungen oder deren fehlerhafte Interpretation werden von der Testautomatisierungslösung nicht erkannt. Ein Test »zwischen den Zeilen« und Testkreativität ist der Testautomatisierungslösung nicht bekannt. Daher ist die Testautomatisierung kein vollwertiger Ersatz für manuelle strukturierte, dynamische Tests oder für explorative Tests. Das SUT sollte bereits ein gewisses Maß an Fehlerfreiheit und Stabilität an den Benutzer- und Systemschnittstellen erreicht haben, damit die Testabläufe sinnvoll automatisiert werden können und nicht ständigen Änderungen unterliegen.

1.4Erfolgsfaktoren für die Testautomatisierung

Um die gesteckten Ziele zu erreichen, die Erwartungen langfristig zu erfüllen und die Hindernisse so gering wie möglich zu halten, sind folgende Erfolgsfaktoren für laufende Testautomatisierungsprojekte von besonderer Bedeutung. Und je mehr diese erfüllt sind, umso höher ist die Wahrscheinlichkeit, dass das Testautomatisierungsprojekt erfolgreich sein wird. In der Praxis wird es selten der Fall sein, dass alle Kriterien erfüllt sind, und dies ist auch nicht zwingend erforderlich. Bereits vor Beginn des Projekts müssen die Rahmenbedingungen und Erfolgsaussichten geprüft und während des Projekts laufend analysiert werden. Jeder Ansatz hat im jeweiligen Projektkontext auch Risiken, und man muss sich bewusst sein, welche Erfolgsfaktoren erfüllt sind und welche nicht. Die Testautomatisierungsstrategie und -architektur sind demnach auch stets an veränderte Rahmenbedingungen anzupassen und zu ergänzen.

Auf Erfolgsfaktoren für die Pilotierung von Testautomatisierungsprojekten wird in weiterer Folge nicht eingegangen.

1.4.1Testautomatisierungsstrategie

Die Testautomatisierungsstrategie ist ein Plan auf hoher Ebene zur Erreichung der langfristigen Ziele der Testautomatisierung unter gegebenen Randbedingungen. Aussagen über die Testautomatisierungsstrategie können in der Testrichtlinie des Unternehmens oder auch in der organisatorischen Teststrategie enthalten sein. Letztere definiert die generischen Anforderungen an das Testen in einem oder mehreren Projekten innerhalb einer Organisation, einschließlich Details darüber, wie das Testen durchgeführt werden soll, und ist an der Testrichtlinie ausgerichtet.

Für jedes Testautomatisierungsprojekt ist eine pragmatische und konsistente Testautomatisierungsstrategie erforderlich, die auf die Wartbarkeit der Testautomatisierungslösung und die Konsistenz des SUT abgestimmt ist.

Da das SUT selbst aus verschiedenen alten und neuen funktionalen und technischen Bereichen bestehen kann und auch Anwendungen und Komponenten verschiedener Plattformen umfasst, ist es wahrscheinlich, dass neben einer Basisstrategie auch entsprechende spezifische Strategien definiert werden müssen. Dabei ist zu berücksichtigen, welche Kosten, Nutzen und Risiken die Anwendung der Strategie auf die verschiedenen Bereiche des SUT mit sich bringt.

Eine weitere wesentliche Anforderung an die Testautomatisierungsstrategie ist die Sicherstellung der Vergleichbarkeit der Testergebnisse von automatisierten Testfällen, die über verschiedene Schnittstellen (z.B. API und GUI) des SUT ausgeführt werden.

Im Laufe des Projekts werden kontinuierlich Erfahrungen gesammelt, das SUT wird sich verändern und die Ziele können angepasst werden. Entsprechend muss die Teststrategie laufend adaptiert und verbessert werden. Deshalb müssen in der Strategie auch die Verbesserungsprozesse und die Strukturen definiert werden.

Exkurs: Testautomatisierungs-Manifest

Es können auch Grundprinzipien für die Testautomatisierung im Projekt oder für das Unternehmen formuliert werden, ein Mindset, das als Leitfaden in verschiedenen Fragestellungen dienen kann. Ein Beispiel dafür ist in der folgenden Abbildung aus dem Projektumfeld der Autoren dargestellt:

Abb. 1–3Testautomatisierungs-Manifest

Transparenz vor Komfort

Testautomatisierung hat den Charakter der Risikomessung und -vermeidung, ähnlich dem Sicherheitsnetz eines Artisten auf einem Hochseil. Das heißt, wenn alle Faktoren richtig zusammenspielen, ist etwa der »Output« im Regressionstest, d.h. die erkannten Fehler, gering. Dies bedeutet jedoch nicht, dass die Testautomatisierung keinen Mehrwert bietet. Es ist daher wichtig, die Testautomatisierung und ihre Ergebnisse und Funktion klar und sichtbar in der Organisation zu platzieren. Dies bedeutet aber auch, dass Probleme der Testautomatisierung klar und sofort sichtbar sind. Dies ist nach Meinung der Autoren kein Nachteil, sondern eine Stärke.

Zusammenarbeit vor Unabhängigkeit

Eine typische Situation für die Testautomatisierung besteht darin, dass ein Werkzeug gekauft und an einen Tester übergeben wird, der dann für die Einführung und Nutzung dieses Werkzeugs verantwortlich ist. Häufig tritt der Effekt auf, dass diese Person dann in einen experimentellen Modus gerät und unter Druck versucht, automatisierte Testfälle zu implementieren. Ein Verhaltensmuster in diesem Zusammenhang ist »ich und das Werkzeug gegen das Produkt« – d.h. eine Tendenz, Probleme und Herausforderungen allein lösen zu wollen oder sie zu umgehen. Wir empfehlen, sich stattdessen aktiv mit anderen Rollen auszutauschen. Wenn z.B. die Anzeige einer Tabelle schwer zugänglich ist, wenden Sie sich an die Entwickler, fragen Sie die Community oder rufen Sie einfach den Herstellersupport an.

Qualität vor Quantität

Eine typische Metrik für den Wert und Fortschritt von Testautomatisierung ist der Automatisierungsgrad einer Testsuite in Prozent oder auch die absolute Anzahl der automatisierten Testfälle. Dabei wird allerdings nicht der generierte Mehrwert betrachtet, der direkt von der Wartbarkeit und Robustheit der automatisierten Tests abhängt. Ein Leitspruch in diesem Kontext ist: »Zehn aussagekräftige, stabile, automatisierte Tests sind mehr wert als tausend instabile und nicht nachvollziehbare Testfälle.« Eine kleine Regressionstestsuite ist also oft nützlicher als ein riesiges, nur schwer wartbares Testportfolio.

Flexibilität vor Kontinuität

Die Testautomatisierung ist ein »Zwillingsprodukt« zu den Systemen, die sie testet – und oft ein Werkzeug zur Sicherstellung von Geschäftsprozessen. Sie liefert den höchsten Mehrwert, wenn sie über einen langen Zeitraum mit geringem Wartungsaufwand betrieben werden kann. In dieser Zeit können sich Technologien, Werkzeuge, Personal und auch die Geschäftsprozesse erheblich ändern. Um effektiv zu bleiben, erfordert die Testautomatisierung ein hohes Maß an Flexibilität gegenüber Veränderungen. Dies ist sowohl ein strategisches und prozessbezogenes als auch ein technologisches/architektonisches Problem, das auch durch die in späteren Kapiteln ausführlich beschriebene generische Testautomatisierungsarchitektur adressiert wird.

Die Testautomatisierungsstrategie muss auch auf den Typ des zugrunde liegenden Projekts abgestimmt sein. Auch die verschiedenen Teststufen und Testarten, die automatisiert unterstützt werden sollen, können unterschiedliche Ansätze erfordern.

Abschnitt 1.5 zu den Themen Teststufen und Projektarten sowie die Anhänge A »Softwarequalitätsmerkmale« und B »Last- und Performanztest« bieten eine Einführung in dieses Thema und sind als Exkurs, d.h. nicht als Bestandteil des Lehrplans zum ISTQB® Certified Tester Advanced Level Testautomatisierungsentwickler zu verstehen.

1.4.2Testautomatisierungsarchitektur

Die Architektur der Testautomatisierungslösung ist entscheidend für die Akzeptanz der Lösung sowie deren Bestand und Nutzung auf lange Sicht. Der Entwurf einer geeigneten Testautomatisierungsarchitektur (TAA) ist auch ein Kernthema der Ausbildung zum Testautomatisierungsentwickler. Es erfordert auch eine gewisse Erfahrung, um die Anforderungen an die Architektur optimal umzusetzen. Aus diesem Grund gibt es in vielen Testautomatisierungsprojekten einen Testautomatisierungsarchitekten, ähnlich dem Softwarearchitekten in der Entwicklung, der das Projekt zumindest zu Beginn und bei größeren Anpassungen begleitet.

Abb. 1–4Einfache, schematische Darstellung der Schichten einer generischen Testautomatisierungsarchitektur

Anforderungen an die Testautomatisierungsarchitektur

Die Architektur der Testautomatisierungslösung ist eng mit der

Architektur des SUT

verbunden. Die einzelnen Komponenten, Benutzeroberflächen, Dialoge, Schnittstellen, Services und technischen Konzepte, verwendeten Sprachen etc. müssen adressiert sein.

Bereits in der Test- und Testautomatisierungsstrategie sollte klar definiert werden, welche

funktionalen und nicht funktionalen Anforderungen des SUT

durch die Testautomatisierung – und damit durch die Testautomatisierungsarchitektur – adressiert und unterstützt werden sollen. Dies werden in der Regel die wichtigsten Anforderungen an das Softwareprodukt sein.

Anhang A

gibt einen Überblick über die Softwarequalitätsmerkmale nach ISO 25010 (Teil der Normenreihe ISO/IEC 25000:2014).

Aber auch die

funktionalen und nicht funktionalen Anforderungen der Testautomatisierungslösung

müssen angemessen berücksichtigt werden. Insbesondere die Anforderungen hinsichtlich Wartbarkeit, Performanz und Erlernbarkeit stehen beim Entwurf einer Testautomatisierungsarchitektur im Vordergrund. Das SUT wird kontinuierlich weiterentwickelt. Modifizierbarkeit und Erweiterbarkeit müssen daher in hohem Maße gegeben sein. Modulare Konzepte oder die Trennung von funktionaler und technischer Implementierungsschicht sind Möglichkeiten, um dies zu gewährleisten. Mit zunehmendem Umfang der automatisierten Testsuite wird die Performanz der Testautomatisierungslösung ein immer wichtigeres Thema. Verstärktes Testen über die API-Schnittstellen statt über die GUI kann zu erheblichen Effizienzsteigerungen führen. Auch sollte die Testautomatisierungslösung nicht eine Geheimwissenschaft für einige wenige Experten sein. Daher sind Verständlichkeit und Erlernbarkeit ebenfalls sehr wichtig. Es lohnt sich auch, die Qualitätsmerkmale in

Anhang A

zu betrachten und sie für die Anwendung auf die Testautomatisierungsarchitektur zu bewerten.

Um die bestmögliche Architektur für die Testautomatisierungslösung zu entwickeln, ist die Zusammenarbeit mit den Softwareentwicklern und -architekten sehr hilfreich, wenn nicht sogar unerlässlich. Denn um die oben genannten Anforderungen zu erfüllen, ist ein tiefes Verständnis der SUT-Architektur erforderlich.

1.4.3Testbarkeit des SUT

Natürlich stellt auch die Testbarkeit, genauer gesagt, die automatisierte Testbarkeit des SUT einen wesentlichen Erfolgsfaktor dar. Die Testautomatisierungswerkzeuge müssen Zugriff auf die Objekte und Elemente der diversen Benutzer- oder Systemschnittstellen haben oder auf Komponenten und Services der Systemarchitektur, um diese zu identifizieren und ansteuern zu können.

Testautomatisierungswerkzeuge stellen dafür eine Reihe von Adaptern für die Automatisierung auf Basis unterschiedlichster Technologien und Plattformen bereit. Ob .NET, Java, SAP, Web, Desktop oder mobile Lösung, Windows, Linux, Android oder iOS, Google Chrom, Internet Explorer, Microsoft Edge, Mozilla Firefox oder Safari – die Palette ist riesig.

Die Hersteller richten ihre Lösungen an den gängigen Standards dieser Technologien und Plattformen aus. Problematisch wird es dann oft, wenn das SUT davon abweichende Implementierungen und Konzepte enthält. Daher ist es auch notwendig, im Zuge eines Proof of Concept die prinzipielle Automatisierbarkeit des SUT festzustellen und auch die passendste Automatisierungslösung zu finden. Denn dreierlei ist schwierig oder teuer: Den Hersteller eines Automatisierungswerkzeugs dazu zu bewegen, sein Produkt nach Ihren Vorstellungen umzubauen; die Entwicklungsabteilung davon zu überzeugen, die Architektur des SUT anzupassen und selbst entwickelte Klassenbibliotheken gegen andere auszutauschen; oder in der Testautomatisierungslösung mit aufwendigen Konstrukten irgendwie eine Lösung herbeizuführen.

Aber mit zunehmender Verbreitung der Testautomatisierung im Unternehmen kann, insbesondere in agilen Entwicklungsszenarien, die Automatisierbarkeit der Testdurchführungen als neues Qualitätsmerkmal für Softwareapplikationen an Bedeutung gewinnen.

Für den automatisieren Test über die GUI sollten etwa die Elemente und Daten für die Interaktion mit der GUI so weit wie möglich von ihrem Layout entkoppelt werden. Für den API-Test können entsprechende Schnittstellen (von Klassen, Modulen/Komponenten etc. oder der Kommandozeile) öffentlich bereitgestellt oder zusätzlich entwickelt werden.

Für jedes SUT gibt es Bereiche (Klassen, Module, funktionale Einheiten), die leichter zu automatisieren sind, und welche, wo die Automatisierung sehr aufwendig werden kann. Mögliche Showstopper sollten bereits in der Evaluierung und Auswahl eines Werkzeugs adressiert werden. Daher sollte man sich zu Beginn eher auf gut automatisierbare Testbereiche fokussieren, denn ein wichtiger Erfolgsfaktor ist die möglichst einfache Implementierung und Verteilung automatisierter Testskripte. Der Nachweis erfolgreicher, automatisierter Testdurchführungen hilft dem Projekt und unterstützt die Investition in den Ausbau der Testdurchführung. Versteigt man sich jedoch zu sehr in kritische Bereiche, liefert man unter Umständen kaum Ergebnisse und Mehrwert für das Vorhaben.

1.4.4Testautomatisierungsframework

Ein Testautomatisierungsframework (TAF) muss einfach verwendbar, gut dokumentiert und vor allem gut wartbar sein. Die Grundlage dafür wird in der Testautomatisierungsarchitektur gelegt. Das Testautomatisierungsframework soll auch einen konsistenten Ansatz zur Testautomatisierung gewährleisten.

Dabei sind folgende Faktoren besonders wichtig:

Implementierung von Berichtsfunktionen

Die Testberichte müssen Informationen über die Qualität des SUT liefern (bestanden/nicht bestanden/fehlerhaft/nicht ausgeführt/abgebrochen, statistische Daten usw.). Die Berichte müssen diese Informationen in angemessener Form für die verschiedenen Beteiligten (Tester, Testmanager, Entwickler, Projektleiter und andere Beteiligte) darstellen, um einen Überblick über die Qualität des SUT zu erhalten.

Unterstützung bei der einfachen Fehlersuche und Fehlerbeseitigung