Leadership im Test: Testausführungstools

Test-(Ausführungs-)Automatisierung

Das Thema Testautomatisierung (meist über grafische Benutzeroberflächen) rangiert weit oben auf der Agenda der meisten Tester und Testmanager. Oberflächlich betrachtet scheinen diese Tools ein großes Potenzial zu besitzen, doch viele Unternehmen, die Teile oder ihre gesamte funktionale Testung automatisieren wollen, stoßen auf Probleme.

Wir gehen in diesem Artikel nicht zu sehr ins technische Detail, möchten aber einige Aspekte beleuchten, die für Test- und Projektmanager relevant sind, wenn sie eine Wirtschaftlichkeitsrechnung für Automatisierung erstellen. Wir betrachten:

• Was Sie von Testausführungs-Tools bekommen – und was nicht
• Testautomatisierung über grafische Benutzeroberflächen (GUI)
• API- und Service-Testautomatisierung
• Regressionstests
• Frameworks für Testautomatisierung

Es ist wichtig, realistische Erwartungen daran zu setzen, was Automatisierung leisten kann – und was nicht. Daher wirken die kommenden Abschnitte möglicherweise etwas pessimistisch.

A WEEKLY 5 MINUTE READ

Upgrade your inbox with more tech leadership wisdom for delivering better software and systems.

URL

This field is for validation purposes and should be left unchanged.

Your email*

By submitting you agree to receive occasional emails and acknowledge our Privacy Policy. You can unsubscribe at anytime.

Was Sie von Testausführungs-Tools bekommen – und was nicht

Ob Sie nun Windows-Desktop-Anwendungen, Webseiten oder mobile Geräte testen: Die Prinzipien der Testautomatisierung, ihre Vorteile und Hürden sind ähnlich. Die Vorteile solcher Tools sind:

• Ein unermüdlicher, angeblich fehlerfreier Roboter, der beliebige Skript-Tests beliebig oft und auf Abruf ausführt.
• Ein präziser Vergleich zwischen den Ausgaben und/oder Ergebnissen von Tests und den vorbereiteten erwarteten Resultaten – auf allen Detailebenen, die Sie dem Tool einprogrammieren wollen.

Was Sie nicht bekommen:

• Flexibilität und eine reibungslose Reaktion auf Abweichungen, Fehler oder fragwürdiges Verhalten.
• Die Augen und das Denken eines menschlichen Testers, der in der Lage ist, Erkundungen vorzunehmen, Fragen zu stellen, zu experimentieren und das Verhalten des zu testenden Systems kritisch zu hinterfragen.
• Tests gratis. Sie müssen immer noch Tests entwerfen und z.B. Testdaten sowie erwartete Resultate vorbereiten.
• Obwohl Testausführungs-Tools zahlreiche Funktionalitäten bieten, fehlen ihnen oft fortschrittliche Möglichkeiten zur Datenspeicherung. Für eine umfassendere Lösung empfiehlt es sich, sich die beste Datenbank-Management-Software anzusehen.

Werfen wir einen genaueren Blick auf die Bedeutung dieser Vorteile und Probleme.

Wenn Sie ein einigermaßen fähiger Programmierer sind, können Sie von Menschen durchgeführte, prozedurale Tests recht leicht als automatisierte Abläufe mittels der Skriptsprache Ihres Tools umsetzen – und das Tool führt diese präzise aus.

Sofern die Umgebung und die für Ihre Testanwendung genutzten Daten konsistent sind, können Sie erwarten, dass Ihre Tests zuverlässig immer wieder gleich ablaufen. Das ist das offensichtliche Versprechen automatisierter Testausführung.

Automatisierte Tests simulieren jedoch nicht wirklich das, was (gute) Tester beim Testen tun.

Ein vom Tool ausgeführter Test ist NICHT gleichbedeutend mit demselben Test, durchgeführt von einer Person.

Ein geskripteter Test mag dem Tester vorgeben, was zu tun ist. Doch Tester können über den einfachen Vergleich zwischen Soll- und Ist-Ergebnis auf einem Bildschirm hinausblicken.

Tester müssen an die richtige Stelle navigieren und aufmerksam auf auffälliges Verhalten achten – Reaktion auf Befehle, Antwortgeschwindigkeit, Erscheinungsbild des Bildschirms, Verhalten von Objekten, die sich je nach Zustand der Anwendung ändern.

Der menschliche Tester kann beim Beobachten einer Auffälligkeit innehalten, seine Schritte zurückverfolgen oder sich die Anwendung oder die Daten genauer anschauen, bevor er beurteilt, ob die Anwendung korrekt funktioniert (oder nicht) – und ob er mit dem geskripteten Test fortfährt, Daten und Skript anpasst oder den Test wie vorgesehen weitermacht.

Menschen sind flexibel, während Werkzeuge genau das tun, was Sie ihnen vorgeben. Bei einer bildschirmbasierten Transaktion gibt das Tool Daten ein, klickt auf einen Button und prüft auf eine Nachricht oder ein Anzeigeergebnis – und das war’s. Bei menschlichen Testern bekommt man vieles mehr, das wir als selbstverständlich ansehen. 

Prinzipiell ist es möglich, ein Tool so zu programmieren, dass es alle Überprüfungen durchführt, die ein Mensch instinktiv macht – aber dafür müssen Sie viel Code schreiben und Zeit in das Debuggen Ihrer Tests investieren. Selbst dann erhalten Sie nicht die Fähigkeit des Menschen zu entscheiden, wie es weitergeht – ob er pausiert, weitermacht, den Test im Verlauf abändert oder eine Anomalie eingehender untersucht.

Nirgends wird die Unflexibilität von Tools deutlicher als beim Reagieren auf den Verlust der Synchronisation des Skripts mit dem zu testenden System. Vielleicht stimmt ein erwartetes Ergebnis nicht überein, das System stürzt ab oder das Verhalten der Benutzeroberfläche (zum Beispiel eine geänderte Reihenfolge von Feldern oder ein neues Feld) unterscheidet sich von den Erwartungen des Skripts. Was macht das Werkzeug? Es versucht weiterzumachen, und ein Schwall von Skriptfehlern oder Abstürzen folgt. 

Ja, Sie können und sollten ungeplante Ereignisbehandler in Ihr Skript einbauen, um Testfehler abzufangen. Verlust der Synchronisation, Abweichungen zwischen Systemzustand und Testdaten, Änderungen in der Reihenfolge der Felder, neue oder entfernte Felder – all das erkennt und handelt der Tester, ohne dass der Test zum Stillstand kommt. Tools können das nicht ohne erheblichen Programmieraufwand Ihrerseits.

Auch der Einsatz von Menschen zur Ausführung von Testskripten hat Nachteile. Tester können sich zu sehr darauf konzentrieren, das Skript zu befolgen, und dabei ihre Beobachtungsgabe vernachlässigen. Sie könnten offensichtliche Anomalien übersehen, weil sie sich zu sehr auf die Ausführung des Skripts konzentrieren. Dieser weniger optimale Ansatz ist genau das, was wir durch Testautomatisierung erhalten.

Blindes Befolgen von Testskripten ist für menschliche Tester keine gute Idee, aber bei der Testautomatisierung das Beste, was möglich ist.

In diesem Vergleich zwischen Testern, die Skripten folgen, und Tools, die Tests ausführen, haben wir das Vorgehen von explorativen Testern noch nicht betrachtet. Der explorative Ansatz gibt Testern die Freiheit, das System nach Belieben zu untersuchen und zu testen. 

Offensichtlich können Tools diese Tätigkeiten nicht simulieren. Noch wichtiger ist, dass Tools nicht in der Lage sind, den Funktionsumfang und Risiken eines Systems zu erfassen, zu priorisieren und darauf basierend Tests zu konzipieren.

Testanalyse- und Designaktivitäten sind erforderlich, unabhängig davon, ob ein Test von einem Menschen oder einem Tool ausgeführt wird.

Es gibt weitere Einschränkungen bezüglich dessen, was Testausführungstools leisten können:

• Testausführungstools machen exakt das, was Sie programmieren – nicht mehr und nicht weniger
• Tools führen in der Regel keine Umgebungserstellung, Anwendungsaufbau und -konfiguration oder das Laden von Testdaten durch
• Tools übernehmen nicht das Design der Testfälle oder -skripte, die Vorbereitung der Testdaten und der erwarteten Ergebnisse
• Tools können keine überlegten Entscheidungen treffen, wenn unerwartete Ereignisse auftreten.

Um Ihre Testausführungsprozesse zu optimieren, kann die Integration mit einer leistungsstarken Testmanagement-Software zu optimierten Arbeitsabläufen und verbessertem Reporting führen.

Graphische Benutzeroberflächen (GUI) Testautomatisierung

Seit etwa fünfundzwanzig Jahren gibt es GUI-Testautomatisierungstools auf dem Markt, doch die Zahl gescheiterter Implementierungen solcher Tools ist weiterhin hoch. Das liegt meist daran, dass die Erwartungen zu hoch angesetzt werden – und Tools ohne Disziplin diese niemals erfüllen können.

GUI-Testautomatisierungstools gelten als einfach zu bedienen, sind jedoch schwer zu verwalten, wenn sich die zu testenden Anwendungen – und damit die Testskripte – ändern. Diese Tools reagieren äußerst sensibel auf Änderungen der Benutzeroberfläche. Änderungen in Position, Reihenfolge, Größe sowie das Hinzufügen oder Entfernen von Bildschirmelementen können die Skripte beeinflussen. Noch technischere Veränderungen wie die Umbenennung von Bildschirmelementen oder Anpassungen von „unsichtbaren“ eingebetteten GUI-Bibliotheken bereiten ebenfalls Probleme.

GUI-Testautomatisierung funktioniert am besten, wenn Disziplin in folgenden Bereichen herrscht:

• Der Entwicklungsprozess sowie Änderungen und Releases werden sorgfältig gesteuert. Beispielsweise werden Auswirkungen analysiert und Tester über Änderungen informiert. 
• Vorgehen bei der Entwicklung der Testskripte. Erfahrene Testautomatisierungsingenieure nutzen systematische Namenskonventionen, Verzeichnisstrukturen, modulare und wiederverwendbare Komponenten, defensives Programmieren usw.

Das Schreiben von Automatisierungsskripten erfordert mehr als grundlegende Programmierkenntnisse und vor allem Erfahrung mit Automatisierung und dem eingesetzten Tool. Werden Tests im großen Umfang automatisiert, sind zusätzlich Designfähigkeiten erforderlich. 

Egal wie Tools von Anbietern beschrieben werden – „skriptfrei“, „für Nicht-Programmierer geeignet“ oder „jeder Nutzer kann automatisieren“ – es braucht dennoch eine Entwicklermentalität, Designkompetenz und eine systematische Herangehensweise.

API- und Service-Testautomatisierung

Wenn Komponenten oder Funktionen als Services bereitgestellt werden und von Thin Clients oder mobilen Clients aufgerufen werden, wird das Testen mittels API- oder Service-Aufrufen durchgeführt. Diese Testform erfolgt entweder mithilfe von eigens von Entwicklern geschriebenem Code oder speziellen API- bzw. Service-Testtools. In jedem Fall lautet die gängige Vorgehensweise: Testen wird auf die eine oder andere Art automatisiert.

Da die API „näher“ am zu testenden Code ist, können die Tests viel gezielter auf die zu überprüfende Funktionalität ausgerichtet werden. Insbesondere können die Komplexitäten bei der Navigation und dem Testen über das Benutzerinterface umgangen werden. Aus diesem Grund gilt die allgemeine Regel:

Wenn sich die zu testende Funktion (auf Code- oder Komponentenebene) durch einen Funktionsaufruf, eine API oder einen Service-Aufruf testen lässt, ist die Automatisierung leichter – und wird empfohlen.

Das Testen über die API bietet klare Vorteile.

• Auch wenn Sie Code benutzen oder schreiben müssen, sind die Tests deutlich einfacher anzuwenden (es gibt keine Benutzeroberfläche, um die Sie sich kümmern müssten).
• Sobald ein API-Aufruf geskriptet ist, müssen Sie nur noch die gewünschten Testfälle tabellarisch festlegen. Es gibt keine Begrenzung für die Anzahl der durchführbaren Tests.
• API-basierte Tests laufen in der Regel deutlich schneller und eignen sich daher besonders für Continuous-Delivery-Ansätze, bei denen die Bereitstellungspipeline hochgradig automatisiert ist und schnelle Reaktionen erfordert.

Die „Testautomatisierungspyramide“ (eine Google-Suche liefert hunderte Beispiele für entsprechende Grafiken) wird praktisch universell verwendet, um die Empfehlung darzustellen, dass sich Testautomatisierungsbemühungen eher auf Entwickler- und API-Tests als auf GUI-Tests konzentrieren sollten.

• Setzen Sie UI-Tests dort ein, wo Arbeitsabläufe des Nutzers überprüft werden müssen, jedoch nur in kleinem Umfang, weil solche Tests kostenintensiv und langsam im Ablauf sein können.
• Nutzen Sie API- oder Service-Aufrufe, wenn sich die zu testende Funktionalität isolieren lässt und wo Geschwindigkeit und einfache Automatisierung entscheidend sind.

Regressionstests

Der klassische Einsatz automatisierter Werkzeuge liegt in der Durchführung von Regressionstests. Diese Tests werden einmal erstellt und gelten als verlässliche Abbildung des erwarteten Verhaltens. Wenn entweder der getestete Anwendungscode, damit verbundene wiederverwendbare Bibliotheken oder die Testumgebung geändert werden, vermitteln diese Tests ein gewisses Vertrauen, dass die gewünschte Funktionalität durch die Änderung nicht beeinträchtigt wurde.

Man kann sich automatisierte Tests vorstellen wie eine Gussform, in die das zu testende System hineinpasst. Natürlich sollten die Tests sämtliche Prüfungen bestehen, die zuvor bereits bestanden wurden. Durch das erneute Ausführen soll die funktionale Gleichwertigkeit der neuen Softwareversion gegenüber der alten demonstriert werden. Es gibt einige einfache Grundsätze, die Sie beachten sollten:

• Zunächst müssen die durchgeführten Tests und Überprüfungen so ausgewählt sein, dass sie die Sicherheit geben, unerwünschte Verhaltensänderungen zu erkennen. Diese Tests wirken wie eine „Stolperfalle“ für Unterschiede im Verhalten.
• Werden Fehler behoben oder andere Änderungen an der Software vorgenommen, kann es dazu kommen, dass sich (korrekterweise) bestimmte Verhaltensweisen verändern, welche Ihre Tests dann nicht mehr bestehen. Entweder passen Sie Ihre Tests im Vorfeld an, oder Sie lassen sie fehlschlagen und korrigieren sie anschließend. Manchmal ist es auch schneller, fehlerhafte Tests einfach zu entfernen und neue Tests von Grund auf zu erstellen. Alle geänderten Tests müssen dann bis zum Abschluss ausgeführt werden und erfolgreich sein.
• Wenn das zu testende System nicht stabil ist, viele Fehler aufweist oder sich zwischen Releases stark verändert, ist es möglicherweise wirtschaftlich nicht sinnvoll, einen Satz automatisierter Tests zu pflegen. Selbst wenn die Systemfunktionalität unverändert bleibt, kann es sein, dass sich die Benutzeroberfläche noch verändert – eine instabile UI erschwert die Wartung der Automatisierung ebenfalls. Die Kosten für die Fehleranalyse bei Tests und deren Wartung könnten den Nutzen übersteigen. Es kann ratsam sein, weniger stabile Teile des Systems zunächst manuell zu testen, bis sich die Stabilität erhöht.

Tests über die Benutzeroberfläche sind manchmal mühsam, teuer und langsam in der Ausführung. Bevor Sie sich an die Automatisierung von GUI-Tests oder sogar das Skripten einer einzelnen Testsequenz wagen, sollten Sie prüfen, ob das Testen der Kernfunktionalität nicht viel einfacher, schneller und wirtschaftlicher über eine API möglich wäre.

Der klassische Einsatz automatisierter Werkzeuge besteht in der Durchführung von Regressionstests. Um sicherzustellen, dass Sie hierfür die effektivsten Tools nutzen, schauen Sie sich unsere Liste der besten Software-Testtools an.

Testautomatisierungs-Frameworks

Test-Frameworks sind ein wesentlicher Bestandteil erfolgreicher Testautomatisierung. Stellen Sie sie sich als eine Sammlung an Leitlinien vor, die beim Erstellen und Gestalten von Testfällen helfen. Ihr Einsatz beschleunigt Ihr Testteam, erhöht die Effizienz, verbessert die Genauigkeit der Tests, senkt Risiken und reduziert Wartungskosten der Tests. Im Folgenden sehen wir uns zwei davon an.

Bei der Diskussion von Testautomatisierungs-Frameworks ist es wichtig, die Rolle von QA-Automatisierungstools für eine effektive Teststrategie zu berücksichtigen.

Unit-Test-Frameworks

Unit-Test-Frameworks existieren seit einigen Jahren und werden von Programmierern ausgiebig zur Überprüfung ihres Codes eingesetzt. Entwicklertests sind in der Regel sehr lokal begrenzt – immerhin testen sie normalerweise eine einzelne Komponente, während Schnittstellen zu anderen Komponenten oder Datenbanken gemockt oder gestubbt werden. Daher benötigen auch Unit-Tests Vorbereitungs- und Nachbereitungsmaßnahmen, diese beschränken sich jedoch meist auf das Testen einer einzelnen Komponente. Für jede einzelne Komponente gibt es eigene Testsuiten.

Von Entwicklern erstellte Unit-Tests werden in der Regel versioniert und parallel zum Komponentencode verwaltet. Typischerweise übernehmen Continuous-Integration-Systeme den Quellcode und alle Unit-Tests und führen diese nach jedem Commit von neuem Code und/oder Tests aus. Alle Entwickler sehen die Ergebnisse dieser Tests, sodass ein Fehler im CI-Test sehr sichtbar wird. Das Beheben fehlgeschlagener Tests und fehlerhaften Codes hat in Teams, die CI auf diese Weise nutzen, hohe Priorität, damit die jeweils aktuelle Version des Systems stets alle CI-Tests besteht.

Frameworks zur Automatisierung von Integrations- und Systemtests

In den letzten Jahren wurden GUI-Testwerkzeuge mithilfe virtualisierter Testgeräte, Testumgebungen und der Ausführung über Kommandozeilenschnittstellen mit CI-Tools verbunden. Vielen Organisationen ist es gelungen, die Ausführung von Unit-, API- und GUI-Tests vollständig über CI-Dienste zu integrieren.

Viele Testteams betreiben jedoch weiterhin eigene Testumgebungen, die getrennt von Entwicklungs- oder CI-Services sind. Diese Teams tendieren dazu, eigene Testautomatisierungsframeworks zu bauen, weil CI-Tools zu entwicklerorientiert sind oder proprietäre Tools nicht ausreichen.

GUI-Tests führen meist End-to-End-Tests oder Benutzerreisen durch, die verschiedene Anwendungen, Hardwaregeräte und Umgebungen umfassen. Diese Tests müssen integrierte Testumgebungen sowie vorbereitete Testdaten auf unterschiedlichen Plattformen nahtlos einrichten, wofür privilegierte, komplexe Abläufe und unterschiedlichste technische Umgebungen notwendig sind. Die große Mehrheit der Teams, die GUI-Testautomatisierung einsetzen, entwickelt daher eigene, aber effektive, Automatisierungsframeworks.

GUI-Automatisierungsframeworks unterscheiden sich im Grad der Ausgereiftheit – von unit-test-ähnlichen Tools bis hin zu komplexen und umfassenden Einrichtungen, die für Verwaltung von Umgebungen, Anwendungs-Builds, großen Testdatenmengen, Nachrichtenübermittlung und Synchronisation über Plattformen und Umgebungen hinweg sowie die Benachrichtigung von Teammitgliedern notwendig sind.

Einige proprietäre Werkzeuge bringen Hilfsmittel oder Testharnesse mit, um automatisierte Testsuiten zu verwalten, auszuführen und darüber zu berichten. Deren Nutzen ist unterschiedlich, weshalb viele Organisationen eigene Testautomatisierungsframeworks schreiben, um die Funktionalität zu erweitern. In den letzten Jahren ist der Umfang von Automatisierungsframeworks gewachsen, sodass es keine einfache oder einheitliche Definition mehr gibt. Wir schauen uns nun an, was Testautomatisierungsframeworks für Softwareteams leisten können.

Ein Testautomatisierungsframework erweitert die Funktionalität von Testausführungsengines.

Konfiguration der Testsuite

Das Framework integriert automatisierte Tests in sinnvolle Sammlungen oder Cluster von Tests. Diese Sammlungen sind so konfigurierbar, dass sie in Hierarchien von Sequenzen, Gruppen oder beliebigen Auswahlen ausgeführt werden können. Solche Tools können Funktionen bieten, um Tests datengetrieben anhand vorbereiteter Testdatentabellen auszuführen. Dies ist die einfachste Framework-Art – bekannte Werkzeuge bieten meistens zumindest eine Form der Testsuite-Konfiguration.

Set-up und Tear-Down

Das Framework übernimmt sämtliche Set-up- und Tear-Down-Aktivitäten für einzelne Tests, Sammlungen oder ganze Suiten. Set-up kann bedeuten, Testumgebungen komplett neu zu erstellen, vollständige Konfigurationen vorzunehmen und Testdatenbanken sowie andere Datenquellen von Grund auf zu befüllen. Tear-Down umfasst das Aufräumen von Testdaten oder das Zurücksetzen bzw. Löschen partieller oder ganzer Umgebungen. Das Framework kann mit Pipeline-Orchestrierungstools integriert und von diesen gesteuert werden.

Exception Handling

Ein Fehler in einem Test – sei es im zu testenden System oder durch einen Synchronisationsverlust – kann konsistent behandelt werden, indem das Ereignis gemeldet wird und die verbleibenden Tests dieser Sammlung in der Regel weiterhin ausgeführt werden. Das Framework kann programmiert werden, um Testprüfungsausfälle, Synchronisationsverluste, Ausführungs-Timeouts und weitere gewählte Testergebnisse jeweils mit eigenen Abläufen zu behandeln.

Logging und Messaging

Das Framework protokolliert Testausführungen und deren Status konsistent über alle Testsammlungen hinweg. Es stößt entweder Berichte der Testwerkzeuge an oder stellt ein einheitliches Berichtsjournal für alle Set-up-, Ausführungs- und Tear-Down-Aktivitäten bereit. Das Framework kann mit ChatOps-Bots interagieren, um das Team über Ausnahmen zu informieren und Teammitgliedern zu ermöglichen, Testsuiten anzuhalten, zu stoppen, zu wiederholen oder neu zu starten.

Testabstraktion mit domänenspezifischer Sprache

Auf dem Markt sind zwei unterschiedliche Framework-Typen entstanden, die den Testausführungscode auf Modelle oder menschenlesbaren bzw. nicht-technischen Text abstrahieren:

• Schlüsselwort-gesteuerte Frameworks ermöglichen es, Tests mit Schlüsselwörtern zu definieren. Aufrufe von Engine-Funktionen werden als englischähnliche Befehle mit Platzhaltern für Parameter oder Daten implementiert. Benutzerdefinierte, wiederverwendbare Module können in gleicher Weise mittels Klartextbefehlen definiert und aufgerufen werden. Es existieren Frameworks für alle Arten von Schnittstellen, einschließlich GUI, Service, API, Kommandozeileninterpreter usw. Skripte können Funktionen plattformübergreifend auf unterschiedlichen Betriebssystemen und Geräten ausführen.
• Behaviour-Driven Development (BDD)-Frameworks ermöglichen es, Stories und Szenarien (Beispiele), die das Verhalten von Funktionen beschreiben, mit einer domänenspezifischen Sprache (DSL) zu erfassen. Die populärste Sprache ist das sogenannte Gherkin, das die Sprachstruktur „gegeben … wenn … dann …“ verwendet, um Beispiele zu erfassen. Gegeben/wenn/dann repräsentieren effektiv Vorbedingungen, Schritte und Nachbedingungen von Testfällen. BDD-Tools wandeln den Gegeben/Wenn/Dann-Text in „Schrittaufrufe“ in einer Programmiersprache um. Der Entwickler (oder Tester) muss die Fixtures oder den Code implementieren, um Aufrufe an die Testausführungsengine zu machen. Auf diese Weise kann die Sprache einer Anforderung (die Story) direkt mit dem zur Ausführung nötigen Code verknüpft werden.

Modellbasierte Frameworks

In diesem Fall ermöglichen Werkzeuge das Erstellen eines Modells des zu testenden Systems. Dies kann beispielsweise automatisch aus einer Webseite abgeleitet werden, wobei das Werkzeug das HTML scannt, Formulare und Felder erkennt und daraus ein Modell erstellt, anhand dessen Wege durch die Formulare entweder automatisch generiert oder vom Tester ausgewählt werden können. Objektzuordnungen für mobile Apps oder andere smarte Geräte können ebenfalls manuell aufgebaut werden. Mithilfe der Pfade durch die Objektzuordnung werden Aufrufe an die Features der Testausführungs-Engine auf ähnliche Weise wie bei BDD- und Keyword-gesteuerten Werkzeugen gemacht. Grundsätzlich können Tests grafisch ohne Code erstellt werden. Werkzeuge in diesem Bereich sind relativ neu und entwickeln sich schnell weiter. Es ist zu erwarten, dass ihre Nutzung in Zukunft stark zunehmen wird.

Abonniere den The QA Lead-Newsletter, um benachrichtigt zu werden, wenn neue Teile der Serie veröffentlicht werden. Diese Beiträge sind Auszüge aus Pauls Leadership In Test Kurs, den wir sehr empfehlen, wenn du tiefer in dieses und weitere Themen eintauchen möchtest. Nutze dabei unseren exklusiven Gutscheincode QALEADOFFER und spare $60 auf den gesamten Kurspreis!

Verwandter Beitrag: 10 BESTE WEB-SERVER-ÜBERWACHUNGS-TOOLS