End-to-End-Tests: Warum sie teuer sind und wie Sie Kosten reduzieren

Automatisierte End-to-End-Tests sind unverzichtbar, aber oft aufwendig und teuer. Erfahren Sie, welche Faktoren die Kosten treiben und wie Sie mit gezielten Maßnahmen Testaufwand, Wartung und Fehleranalyse optimieren.

Automatisierte End-to-End-Tests sind aufwendig und kostenintensiv. Gleichzeitig ist ihre Bedeutung unbestritten, da nur diese Testart die Korrektheit und Vollständigkeit realer, systemübergreifender Geschäftsprozesse validieren kann.

In der Praxis zeigt sich jedoch häufig, dass die Erstellung, Wartung und Pflege automatisierter End-to-End-Tests aufwendig sind. Darüber hinaus ist ihre Ausführung zeitintensiv und aufgrund der Vielzahl beteiligter Systeme häufig instabil. Bereits kleine Veränderungen in der Testumgebung, bestehend aus der zugrunde liegenden Infrastruktur, den zu testenden Anwendungen sowie weiteren am Geschäftsprozess beteiligten Umsystemen, können zu Testabbrüchen führen.

Martin Fowler fasst diese Problematik in seiner Beschreibung der Test Pyramid prägnant zusammen:

“In short, tests that run end-to-end through the UI are: brittle, expensive to write, and time consuming to run.”

Quelle: Martin Fowler, Test Pyramid

Die Kosten entstehen dabei nicht an einer einzelnen Stelle. Sie verteilen sich auf die Erstellung, Wartung und Pflege der automatisierten Tests, Testumgebungen und Umsysteme, das Testdatenmanagement, die eigentliche Testausführung sowie die Analyse fehlgeschlagener Tests.

Warum automatisierte End-to-End-Tests hohe Kosten verursachen

Die Kosten automatisierter End-to-End-Tests entstehen insbesondere durch:

• die Erstellung, Wartung und Pflege der automatisierten End-to-End-Tests,
• die Bereitstellung, Wartung und Pflege der Testumgebung sowie weiterer am Geschäftsprozess beteiligter Umsysteme,
• die Bereitstellung und Pflege von Testdaten (Testdatenmanagement),
• lange Testausführungszeiten,
• das Risiko instabiler Testausführungen sowie
• hohe Aufwände bei der Analyse fehlgeschlagener Testausführungen.

Weitere Faktoren, die die Kosten und den Nutzen automatisierter End-to-End-Tests beeinflussen, sind:

• die Komplexität des Gesamtsystems,
• die geplante Lebensdauer der geschäftskritischen Anwendungen sowie
• die organisatorischen Zuständigkeiten für die automatisierten End-to-End-Tests.

Im Folgenden werden die einzelnen Kostenfaktoren näher betrachtet. Sofern hilfreich, werden diese Abhängigkeiten anhand praxisnaher Beispiele verdeutlicht.

Erstellung, Wartung und Pflege automatisierter End-to-End-Tests

Zu Beginn eines Automatisierungsprojekts übernimmt häufig ein Testautomatisierungsspezialist, im Folgenden kurz „Automatisierer“ genannt, die Erstellung eines automatisierten End-to-End-Tests für einen zentralen Geschäftsprozess. Dies erfolgt in der Regel erst nach erfolgreicher Prüfung der technischen Umsetzbarkeit und fachlichen Machbarkeit im Rahmen eines Proof of Concept (PoC).

Da der Automatisierer in der Regel nicht über alle erforderlichen fachlichen Kenntnisse verfügt, ist er auf die Unterstützung von Fachexperten angewiesen, um den Geschäftsprozess korrekt zu verstehen, als automatisierten End-to-End-Test umzusetzen und mit geeigneten Testdaten zu versehen.

Wartungsarbeiten infolge von Betriebssystem-, Browser- oder Testautomatisierungswerkzeug-Updates fallen zwar an, sollten sich aber im Rahmen halten.

Mit wachsender Anzahl automatisierter End-to-End-Tests nimmt der Pflegeaufwand zu. Ursache hierfür ist, dass Änderungen an den zu testenden Anwendungen häufig Anpassungen in mehreren Testfällen nach sich ziehen. Anwendungsanpassungen resultieren meist aus fachlichen Anforderungen sowie aus gesetzlichen Vorgaben. Ebenso können Änderungen an Fremdschnittstellen, beispielsweise an Datenformaten, Anpassungen erforderlich machen.

Aus technischer Sicht benötigt der Automatisierer ein Testautomatisierungswerkzeug, beispielsweise Playwright (Microsoft), Selenium (Open Source), UFT Functional Testing (OpenText) oder Tosca (Tricentis), häufig in Verbindung mit einer Testmanagement- oder Testplattform wie Jira (Atlassian) oder ALM (OpenText).

Die hierbei entstehenden Kosten können stark variieren und reichen von kostenfreien Open-Source-Lösungen bis hin zu kommerziellen Testautomatisierungswerkzeugen und Plattformkombinationen, bei denen jährliche Kosten im fünfstelligen Bereich pro Automatisierer anfallen können.

Kostenfaktoren:

• Personalkosten: Automatisierer, Fachexperten, Entwickler und weitere Personen des Testteams bzw. aus dem Unternehmen
• Hardwarekosten: abhängig von der verwendeten Testplattform und dem verwendeten Testautomatisierungswerkzeug
• Lizenzkosten: bei kostenpflichtigen Produkten zur Erstellung, Verwaltung, Orchestrierung und Ausführung der automatisierten Tests

Testumgebung und beteiligte Umsysteme

Für das Testen von Geschäftsprozessen mittels End-to-End-Tests wird in der Regel eine eigene Testumgebung benötigt, die der Produktivumgebung, soweit für die geplanten Tests erforderlich, möglichst nahekommt. Die Bereitstellung, Wartung und Pflege dieser Testumgebung samt beteiligter Umsysteme wird deshalb häufig von der Unternehmens-IT übernommen, da sie mit dem Produktivsystem und den darauf laufenden Anwendungen bereits bestens vertraut ist.

Stehen Tests auf dieser Testumgebung an, muss sichergestellt sein, dass die zu testenden Anwendungen den gewünschten Versionsstand aufweisen und die Testumgebung einschließlich der beteiligten Umsysteme zu Testbeginn betriebsbereit ist.

Beim Einsatz komplexer Testplattformen ist zu berücksichtigen, dass für deren Betrieb spezielles Fachwissen erforderlich ist. So besteht eine OpenText-ALM-Installation aus mehreren Komponenten (ALM Application Server, Lizenzserver, DB-Server und Dateispeicher) und muss spezielle Funktionen, beispielsweise die Remote-Testausführung, unterstützen. Die Administration und der Betrieb dieser Komponenten werden in der Regel von speziell dafür ausgebildeten Mitarbeitern übernommen, die häufig der Unternehmens-IT angehören.

Kostenfaktoren:

• Personalkosten: Unternehmens-IT, Testmanagement, Entwickler
• Hardwarekosten: bei unternehmenseigener Testumgebung
• Lizenzkosten/Gebühren: bei kostenpflichtigen Produkten oder Nutzung von unternehmensfremden Systemen

Testdatenmanagement

In der Praxis erweist sich der Aufwand für das Testdatenmanagement häufig als unterschätzter Kostenfaktor im End-to-End-Testing. Die Ermittlung geeigneter und korrekter Testdaten kann sehr zeitaufwendig sein und setzt in der Regel tiefgreifende fachliche Kenntnisse voraus. Da diese häufig über das Wissen des Automatisierers hinausgehen, müssen hierfür in vielen Fällen fachlich kompetente Personen unterstützend hinzugezogen werden.

Da die für End-to-End-Tests benötigten Testdaten häufig produktionsnah sind, müssen sie vor ihrer Bereitstellung und Verwendung in der Regel aufbereitet werden, um den rechtlichen Vorgaben, beispielsweise der DSGVO, sowie unternehmensweit geltenden Richtlinien zu entsprechen.

Erstreckt sich die Nutzung von End-to-End-Tests über einen längeren Zeitraum, muss der Pflege der Testdaten große Beachtung geschenkt werden, da sich beispielsweise die Relevanz der Testdaten im Laufe der Zeit ändern kann.

Beispiel aus der Praxis:

Für einen automatisierten End-to-End-Test des Geschäftsfalls „Festnetzvertrag für Neukunden“ wurden auf Basis der Auswertung von Produktivdaten zwei Testvarianten bereitgestellt: eine für den Standardtarif und eine weitere für den von den meisten Kunden gewählten Tarif.

Die Testfallvariante mit der höchsten Kundenpräferenz wurde mit der Priorität „hoch“ versehen, um sicherzustellen, dass sie in jeder Testphase ausgeführt wird.

Die Testausführungen dieser Tests bleiben über einen sehr langen Zeitraum unauffällig. Sie haben aber aus folgenden Gründen an Relevanz verloren:

• neuer Standardtarif nach Einführung eines neuen Produktportfolios
• geänderte Kundenpräferenz nach Umstellung von analoger auf IP-basierte Telefonie und Erweiterung des Produktportfolios um Tarife für Glasfaseranschlüsse mit hohen Bandbreiten

Kostenfaktoren:

• Personalkosten: Automatisierer, Fachexperten, Entwickler
• Hardware-/Softwarekosten: können beispielsweise bei der Nutzung zusätzlicher DB-Kapazitäten, spezieller Testdatenmanagement-Tools oder unternehmensfremder Dienste anfallen

Lange Testausführungszeiten

Neben der Notwendigkeit, eine produktionsnahe Testumgebung zu nutzen, sind lange Testausführungszeiten von End-to-End-Tests ein wesentlicher Grund dafür, dass End-to-End-Testing entweder vollständig außerhalb des CI/CD-Prozesses durchgeführt oder innerhalb des Prozesses nur für ausgewählte Builds ausgeführt wird.

Die Ausführungsdauer hängt von verschiedenen Faktoren ab, wobei häufig der Geschäftsfall selbst eine Mindestlaufzeit mit sich bringt.

Kostenfaktoren:

• Personalkosten: Automatisierer
• Hardwarekosten: zusätzliche Kosten können bei nutzungsbasierter Abrechnung der Testumgebung anfallen

Instabile Testausführungen

Durch instabile Testausführungen entstehen zusätzliche Kosten, da die häufig langlaufenden Tests wiederholt werden müssen und gegebenenfalls vor einem Neustart erneut mit neuen Testdaten zu versorgen sind.

Aussagen zur Korrektheit der Geschäftsfälle können dadurch erst später getroffen werden. Zudem muss der Test nachgelagerter Geschäftsfälle gegebenenfalls verschoben werden.

Instabile Testausführungen bergen neben dem reinen Kostenaspekt auch das Risiko, dass das Vertrauen in die Testautomatisierung innerhalb des Testteams sowie im gesamten Unternehmen sinkt.

Kostenfaktoren:

• Personalkosten: Automatisierer, Fachexperten, Entwickler

Analyse fehlgeschlagener Testausführungen

Warum insbesondere in sehr komplexen Testumgebungen beim Einsatz von End-to-End-Tests schnell hohe Analyseaufwände entstehen können, lässt sich anhand eines Beispiels verdeutlichen.

Beispiel aus der Praxis:

Aufgrund eines temporären Netzwerkproblems als Fehlerursache kann ein im Geschäftsprozess genutzter Dienst keine Rufnummer reservieren. Später versucht eine Anwendung, diese Rufnummer weiterzuverarbeiten, schlägt dabei jedoch fehl und erzeugt eine anwendungsspezifische Fehlermeldung.

Die fehlende Rufnummer bleibt also zunächst unbemerkt und führt erst zu einem späteren Zeitpunkt zum Abbruch des automatisierten End-to-End-Tests mit dem Status FAILED.

Liegen keine Hinweise auf Netzwerkprobleme vor, wird zur Analyse des fehlgeschlagenen Testlaufs zunächst ein Entwickler der Anwendung hinzugezogen, in der der interne Fehler gemeldet wurde. Bis zur endgültigen Identifikation der Fehlerursache können mehrere Analysezyklen erforderlich sein, an denen häufig Personen aus unterschiedlichsten Bereichen beteiligt sind.

Kostenfaktoren:

• Personalkosten: Automatisierer, Fachexperten, Entwickler, Unternehmens-IT

Welche Faktoren die Kosten zusätzlich beeinflussen

Neben den direkten Kosten für die Erstellung, Ausführung und Analyse automatisierter End-to-End-Tests sowie für die Bereitstellung von Testumgebungen und Testdaten beeinflussen weitere Rahmenbedingungen deren Wirtschaftlichkeit. Dazu zählen insbesondere die Komplexität des Gesamtsystems, die geplante Lebensdauer der geschäftskritischen Anwendungen und die organisatorischen Zuständigkeiten.

Komplexität des Gesamtsystems

Der Einfluss der Komplexität eines Gesamtsystems auf die Kosten des End-to-End-Testings ist erheblich und wirkt sich auf alle zuvor genannten Kostenfaktoren aus.

Beispiel für steigende Kosten bei der Wartung und Pflege automatisierter End-to-End-Tests:

Zur Bearbeitung von Geschäftsfällen in komplexen Gesamtsystemen werden in der Regel mehrere Anwendungen benötigt. Dies führt häufig dazu, dass mehrere Automatisierer zum Einsatz kommen und die zu testenden Anwendungen auf diese verteilt werden.

Zwischen den Automatisierern gibt es Absprachen zur Umsetzung der zu erstellenden Automatisierungsartefakte. Diese betreffen jedoch hauptsächlich die „Schnittstellen“ der Artefakte, also die Eingabedaten, die sie benötigen, sowie die Ausgabedaten, die sie bereitstellen. Über die Interna der einzelnen Artefakte wird hingegen häufig nicht oder nur in sehr begrenztem Umfang gesprochen.

Mögliche Folgen:

• Ansteuerung und Bedienung von UI-Elementen werden unterschiedlich umgesetzt.
• Fachlichkeit wird unterschiedlich berücksichtigt.

Bei einer stabilen Teamzusammensetzung mag dies zunächst unbemerkt bleiben. Dennoch wirkt es sich bereits hier auf die Pflegeaufwände aus, da notwendige Anpassungen an den Anwendungen unterschiedlich hohe Aufwände verursachen und für gleiche oder ähnliche Aufgabenstellungen unterschiedliche Lösungsansätze zum Einsatz kommen.

Im Falle größerer Änderungen an der Teamstruktur steigen insbesondere die Wartungs- und Pflegeaufwände stark an, sodass die Schaffung zusätzlicher Testabdeckung nur noch eingeschränkt möglich ist.

Geplante Lebensdauer der geschäftskritischen Anwendungen

Eine lange Lebensdauer geschäftskritischer Anwendungen erhöht den Nutzen von End-to-End-Tests, da vorhandene Artefakte länger für Regressionstests genutzt werden können.

Gleichzeitig können Testdaten im Laufe der Zeit an fachlicher Relevanz verlieren und Änderungen in der Teamstruktur zu höheren Wartungs- und Pflegekosten führen.

Organisatorische Zuständigkeiten für automatisierte End-to-End-Tests

Während die Verantwortung für automatisierte End-to-End-Tests im gesamten Team liegt, existieren keine allgemein gültigen Empfehlungen hinsichtlich der konkreten Zuständigkeiten für deren Erstellung, Wartung, Pflege und Ausführung.

In der Praxis sind häufig Mischformen anzutreffen. So übernehmen beispielsweise Automatisierer die Erstellung, Wartung und Pflege der Tests, während deren Ausführung durch die für die manuellen Tests zuständigen Personen, im Folgenden kurz Tester genannt, erfolgt.

Wesentliche Faktoren, die bei der Aufgabenverteilung eine Rolle spielen können, sind:

• Kenntnisse über die eingesetzte Testplattform und das Testautomatisierungswerkzeug
• Erfahrungen und Vorgaben des Kunden
• Personalkosten für Automatisierer und Tester

Darüber hinaus unterscheiden sich Automatisierer und Tester häufig hinsichtlich ihrer fachlichen und technischen Kompetenzen. Während Automatisierer über ausgeprägtes technisches Know-how verfügen, bringen Tester in der Regel vor allem umfassende Fachkenntnisse mit.

So lassen sich die Kosten automatisierter End-to-End-Tests reduzieren

Mit dem Verständnis über die kostenverursachenden Faktoren automatisierter End-to-End-Tests lassen sich geeignete Optimierungspotenziale identifizieren, um die unbestrittenen Vorteile von End-to-End-Testing möglichst kosteneffizient nutzen zu können.

Neben allgemeinen Maßnahmen der Softwareentwicklung wie

• Sicherstellung des Wissenstransfers, z. B. durch Pair Programming und regelmäßige Code Reviews,
• Dokumentation der erstellten Tests sowie der verwendeten Testdaten und
• klare Definition von Verantwortlichkeiten

können auch spezifische Maßnahmen der Testautomatisierung zur Kostenoptimierung beitragen:

1. Auswahl der Testplattform und des Testautomatisierungswerkzeugs
2. klare Definition der Testziele
3. kontinuierliche Pflege und Verwaltung der Testdaten
4. Priorisierung der Teststabilität
5. Standardisierung und Modularisierung der Testautomatisierung

Testplattform und Testautomatisierungswerkzeug passend auswählen

Im Folgenden wird zur Vereinfachung der Begriff „Testtool“ verwendet, sofern allgemein von einer Testplattform oder einem Testautomatisierungswerkzeug die Rede ist.

Falls das Testtool noch nicht festgelegt ist, sollten neben den reinen Testtoolkosten die folgenden Gesichtspunkte berücksichtigt werden:

• Gibt es unternehmensseitige Vorgaben, z. B. zur Tool-Konsolidierung, oder wird bereits ein Testtool eingesetzt? Der Einsatz eines zusätzlichen Testtools ausschließlich für End-to-End-Testing sollte vermieden bzw. fachlich und wirtschaftlich begründet werden.

• Gibt es Gründe, die den Einsatz bestimmter Testtools ausschließen bzw. zwingend erforderlich oder besonders sinnvoll machen? Die Eignung von Testautomatisierungswerkzeugen hängt stark vom Anwendungsumfeld ab. Während Werkzeuge wie Playwright primär für Webanwendungen konzipiert sind und Desktop-Anwendungen nur eingeschränkt unterstützen, bietet Tricentis Tosca insbesondere im SAP-Umfeld umfangreiche Automatisierungsmöglichkeiten.

• Ist der Einsatz der Testplattform auf End-to-End-Testing beschränkt oder soll sie auch für andere automatisierte bzw. manuelle Tests verwendet werden?

• Welche technischen Kenntnisse müssen die Nutzer des Testtools mitbringen? Während einige Testautomatisierungswerkzeuge wie Functional Testing umfassende Softwareentwicklungskenntnisse voraussetzen, gilt Robot Framework aufgrund seines konsequenten Keyword-Driven-Ansatzes als Testautomatisierungswerkzeug, das vergleichsweise geringe Entwicklungskenntnisse erfordert.

• Welche weiteren Funktionen muss das Testtool beispielsweise zur Dokumentation von Testausführungen und Testergebnissen bereitstellen?

Testziele klar definieren und Testumfang begrenzen

Im Fokus des End-to-End-Testings steht die Validierung vollständiger, meist system- und anwendungsübergreifender Geschäftsprozesse. Aufgrund des hohen Aufwands und der damit verbundenen Kosten empfiehlt es sich, den Testumfang auf wenige, geschäftskritische Geschäftsfälle zu beschränken.

Voraussetzung für die Durchführung dieser Tests ist die Verfügbarkeit aller an den jeweiligen Geschäftsprozessen beteiligten Systeme und Anwendungen in der Testumgebung.

Eine Betrachtung der einzelnen Systeme bzw. Anwendungen aus Sicht der Testziele kann sinnvoll sein, da sich hierdurch weitere Möglichkeiten zur Kostenreduzierung identifizieren lassen, insbesondere:

• Einsatz von Mocking-, Simulations- und Service-Virtualisierungstechniken
• Verwendung von API-Schnittstellen

Testdaten kontinuierlich pflegen und verwalten

Die Bereitstellung geeigneter und korrekter Testdaten ist zeitaufwendig und erfordert einen hohen Grad an fachlichem Wissen. Einmal ermittelte und wiederverwendbare Testdaten bergen das Risiko, dass sie im Laufe der Zeit „veralten“. Dadurch kann die fachliche Relevanz der Tests sinken oder Testausführungen können fehlschlagen.

Eine kontinuierliche Pflege und Verwaltung der Testdaten ist daher unerlässlich. Folgende Maßnahmen können dabei unterstützen:

Testdaten regelmäßig prüfen und aktualisieren

Insbesondere zur Aufrechterhaltung der fachlichen Relevanz automatisierter End-to-End-Tests ist eine regelmäßige Überprüfung der Testdaten aus fachlicher Sicht erforderlich.

Testdaten müssen bei Bedarf an veränderte Rahmenbedingungen angepasst werden, beispielsweise durch die Einführung neuer Tarife und Tarifoptionen im Produktportfolio oder einer Obergrenze für Mobilfunkverträge pro Kunde.

Testdatenerzeugung, -ermittlung und -prüfung automatisieren

Der Einsatz von Automatisierung kann den Aufwand für die Erzeugung, Ermittlung, Validierung und kontinuierliche Pflege von Testdaten reduzieren.

Beispiele hierfür sind:

• die Wiederverwendung bereits erstellter Verträge für Tests von Bestandskundenprozessen wie Vertragskündigungen,
• die automatisierte Ermittlung geeigneter Testdaten mittels SQL-Statements,
• die Nutzung interner oder externer Dienste sowie
• die werkzeuggestützte Erzeugung spezifischer Testdaten wie IBANs oder SIM-Kartennummern.

Testdatenverwaltungstools einsetzen

Viele Testtools bieten bereits Funktionen zur Verwaltung von Testdaten an. So können beispielsweise Testdaten für automatisierte End-to-End-Tests, die mit OpenText Functional Testing erstellt werden, in der Testplattform OpenText ALM zentral als Testressourcen abgelegt werden.

Darüber hinaus sind Werkzeuge auf dem Markt verfügbar, die die Verwaltung von Testdaten in den Fokus stellen oder bestimmte Funktionalitäten von Testverwaltungstools unterstützen.

Teststabilität priorisieren

Eine wesentliche Ursache für instabile Testausführungen ist die hohe Anzahl der am Geschäftsprozess beteiligten Systeme, Anwendungen und Schnittstellen sowie die damit verbundenen technischen Abhängigkeiten.

Die Minimierung äußerer Einflüsse auf die Testausführung stellt daher einen wichtigen Ansatz zur Verbesserung der Testausführungsstabilität dar. Neben dem bereits erwähnten Einsatz von Mocking- und Simulationstechniken sowie der Nutzung von API-Schnittstellen können die folgenden Maßnahmen zur Erhöhung der Stabilität von Testausführungen beitragen:

• Sicherstellung und kontinuierliche Überwachung der Verfügbarkeit aller Systeme
• Sicherstellung definierter Ausgangszustände vor jeder Testausführung
• Reduzierung der beteiligten Systeme auf die für die Ausführung der Geschäftsprozesse zwingend erforderlichen Komponenten

Mit Blick auf die Testautomatisierungsartefakte können insbesondere die folgenden Maßnahmen zur Verbesserung der Testausführungsstabilität beitragen:

Feste Wartezeiten vermeiden

Fixed Waits (feste Wartezeiten) sollten möglichst vermieden werden, da zu großzügig bemessene Wartezeiten die Testausführungszeiten unnötig erhöhen und zu kurze Wartezeiten das Risiko von Testabbrüchen und instabilen Testergebnissen erhöhen.

Moderne Testautomatisierungswerkzeuge wie Playwright verfügen über integrierte Synchronisationsmechanismen, wodurch statische Wartezeiten weitgehend vermieden werden können.

Bietet ein Testautomatisierungswerkzeug nur eine eingeschränkte Synchronisationsunterstützung, sollten explizite, zustandsabhängige Synchronisationsmechanismen wie Event- oder Message-basierte Verfahren eingesetzt werden, da diese robuster und effizienter sind als feste Wartezeiten.

System- und Anwendungszustände kontinuierlich überwachen

Aufgrund der Vielzahl beteiligter Systeme und Anwendungen besteht bei End-to-End-Tests die Gefahr, dass sich Fehler erst zeitverzögert auswirken und letztlich zu einem Testabbruch führen. Dies erschwert die Fehleranalyse und kann dazu führen, dass Testautomatisierungsskripte unabhängig von den fachlichen Anforderungen zur Behandlung solcher Fehlerfälle angepasst werden.

Wiederholte Anpassungen erhöhen die Komplexität des Skriptcodes, beeinträchtigen die Lesbarkeit und steigern den Wartungsaufwand.

Eine mögliche Gegenmaßnahme ist die kontinuierliche Überwachung relevanter System- und Anwendungszustände während der Testausführung.

UI-Elemente robust identifizieren

Im Idealfall lässt sich ein UI-Element stets eindeutig über eine seiner Eigenschaften, z. B. eine statische, anwendungsweit gültige ID, identifizieren.

Ist dies nicht möglich, müssen mehrere Eigenschaften als Identifikationskriterien herangezogen werden. In diesem Fall besteht das Risiko, dass ein Objekt nicht mehr oder nicht mehr eindeutig erkannt wird. Folglich kann das UI-Element im Rahmen einer Testausführung nicht mehr angesteuert und bedient werden.

Für eine robuste Identifikation von UI-Elementen sollte daher darauf geachtet werden, ausschließlich diejenigen Elementeigenschaften zu verwenden, die für eine eindeutige Identifikation zwingend erforderlich sind.

Testautomatisierung standardisieren und modularisieren

Allgemeingültige Maßnahmen zur Standardisierung und Modularisierung des Software-Engineerings können auch auf die Erstellung, Wartung und Pflege von Testartefakten für automatisierte End-to-End-Tests übertragen werden:

• Verwendung von Standards und Richtlinien
• Trennung von Testlogik und Fachlichkeit
• Bereitstellung und Verwendung wiederverwendbarer Testartefakte

Zur Umsetzung dieser Maßnahmen kann ein eigenentwickeltes Testautomatisierungsframework maßgeblich beitragen.

Da sowohl der zeitliche als auch der personelle Aufwand für die Konzeption, Realisierung und Einführung eines solchen Frameworks erheblich ist und insbesondere zu Beginn zahlreiche Ressourcen bindet, muss sichergestellt sein, dass die damit verbundenen Kosten in einem angemessenen Verhältnis zum erzielten Nutzen stehen.

Wann lohnt sich ein eigenes Testautomatisierungsframework?

Faktoren, die für den Einsatz eines eigenen Testautomatisierungsframeworks sprechen, sind:

• spezielle Kundenanforderungen
• lange Projektlaufzeiten bzw. eine lange Lebensdauer der Anwendungen (> 5 Jahre)
• hoher Wiederverwendbarkeitsgrad der Testartefakte über mehrere Anwendungen bzw. Projekte hinweg
• hohe Anzahl automatisierter Tests
• kurze Releasezyklen bzw. häufige Regressionstests

In den meisten Fällen fällt die Entscheidung für ein eigenes Framework in Testautomatisierungsprojekten mit langen Laufzeiten und basiert auf den bisher im Projekt gesammelten Erfahrungen mit der Testautomatisierung.

Häufig, jedoch nicht ausschließlich, sind stark steigende Pflegeaufwände ein ausschlaggebender Faktor für den Wunsch nach einem eigenen Framework.

Fazit: End-to-End-Tests gezielt und kosteneffizient einsetzen

Automatisierte End-to-End-Tests sind besonders wertvoll, wenn vollständige, systemübergreifende Geschäftsprozesse validiert werden sollen. Gleichzeitig entstehen durch ihre Erstellung, Wartung und Pflege, die benötigten Testumgebungen und Testdaten, lange Ausführungszeiten sowie die Analyse fehlgeschlagener Tests erhebliche Aufwände.

Um diese Aufwände zu begrenzen, sollte der Einsatz von End-to-End-Tests gezielt auf geschäftskritische Geschäftsfälle ausgerichtet werden. Darüber hinaus können eine geeignete Toolauswahl, kontinuierliches Testdatenmanagement, eine hohe Teststabilität sowie die Standardisierung und Modularisierung der Testautomatisierung dazu beitragen, die langfristigen Kosten zu reduzieren.

Entscheidend ist dabei nicht, möglichst viele Geschäftsprozesse vollständig über End-to-End-Tests abzudecken. Vielmehr gilt es, den Nutzen der zusätzlichen Testabdeckung gegen die damit verbundenen Erstellungs-, Ausführungs- und Wartungsaufwände abzuwägen.