Manuelles Testen vs. automatisiertes Testen: Warum manuelles Testen bei End-to-End-Tests nicht reicht

Manuelles Testen heißt, dass ein Mensch eine App von Hand prüft; ein automatisierter Test spielt sie ohne Menschen ab.Bei Funktions- und End-to-End-Prüfungen, die sich bei jedem Release wiederholen, reicht manuelles Testen nicht: Es ist langsam, hängt vom Tester ab und kann nicht bei jedem Build laufen.

Dies ist kein Artikel gegen manuelle Tester.Die besten Tester finden Fehler, nach denen kein Skript suchen würde.Das Problem ist der andere Teil der Arbeit: dieselben Formulare, dieselben Menüs und denselben Checkout durchgehen, Release für Release, in jedem Browser und jeder Sprache.Dieser Teil skaliert nicht, und er war nie eine gute Verwendung der Aufmerksamkeit eines Testers.

Manuelles Testen vs. automatisiertes Testen: der Unterschied

Wenn Regressionstests neu für Sie sind, erklärt Was ist Regressionstesten, warum dieselben Prüfungen nach jeder Änderung wiederkommen.

Was manuelles Testen immer noch am besten kann

Ein fairer Vergleich beginnt mit dem, was Menschen besser können als jeder Test, und diese Liste ist echt.

DORA, das Forschungsprogramm hinter den State-of-DevOps-Berichten, sagt dasselbe.Seine Seite zur Testautomatisierung empfiehlt, manuelle Tätigkeiten wie exploratives Testen und Usability-Tests beizubehalten, und sagt, dass Tester und QA-Teams weiterhin eine wichtige Rolle spielen.

Die Grenzen manueller Tests bei End-to-End-Tests

Manuelles Testen funktioniert gut für eine Prüfung, die man einmal macht.Das sind die Nachteile, die auftreten, wenn dieselben Funktions- und End-to-End-Prüfungen bei jedem Release wiederkommen.

Es wächst nicht mit den Releases mit, und nicht mit KI-geschriebenem Code

Ein manueller Regressionsdurchgang ist so lang wie die Liste der Szenarien, und die Liste wächst nur.Jede Funktion bringt Prüfungen hinzu, und fast keine wird je entfernt.

KI-Coding-Assistenten vergrößern die Lücke.In seinem Bericht von 2026 stellte Faros AI fest, dass der Anteil KI-generierten Codes, den Entwickler übernehmen, von 20 % auf 60 % gestiegen ist und dass jeder Entwickler 16,2 % mehr Pull Requests zusammenführt, im Vergleich von geringer und hoher KI-Nutzung bei 22.000 Entwicklern.Jede Woche kommen mehr Änderungen bei den Testern an, während ein Mensch weiterhin im selben Tempo prüft.

Wie man KI-generierten Code testet betrachtet dieses Problem im Detail.

Wiederholung lässt Menschen Dinge übersehen

Menschen sehen, wonach sie suchen.Beim zwanzigsten Durchgang durch dasselbe Formular prüft ein Tester das Feld, das der Testfall nennt, und übersieht das Logo, das direkt daneben verschwunden ist.

Experten sind keine Ausnahme.In einer Studie von 2013, veröffentlicht in Psychological Science, baten Forschende 24 Radiologen, in CT-Aufnahmen nach Lungenknoten zu suchen, und setzten in die letzte einen Gorilla, 48-mal so groß wie ein Knoten.83 % von ihnen sahen ihn nicht, und die Blickverfolgung zeigte, dass die meisten davon direkt auf ihn geschaut hatten.

Auch sorgfältige Inspektion hat eine Obergrenze.In einer Studie mit 82 geschulten Prüfern, 2015 in Human Factors veröffentlicht, fanden sie 85 % der fehlerhaften Teile, nahe am Branchendurchschnitt von 80 %, den die Autoren angeben.Etwa jeder siebte Fehler kam durch, bei Menschen, deren Aufgabe es war, ihn zu finden.

Jeder Browser, jedes Gerät und jede Sprache vervielfacht die Arbeit

Eine Web-App, die in Chrome geprüft ist, ist nicht in Firefox geprüft.Ein Bildschirm, der auf Englisch geprüft ist, ist nicht auf Deutsch geprüft, wo jede Beschriftung länger ist.Von Hand ist jeder Browser, jede Bildschirmgröße und jede Sprache ein weiterer vollständiger Durchgang, also vervielfacht ein Team entweder seine Stunden oder prüft stillschweigend nur eine Kombination.

Cross-Browser-Testing aus einer Aufzeichnung zeigt, wie aus einem Web-Test eine Version für jeden Browser, jedes Gerät und jede Sprache wird.

Es kann nicht bei jedem Build laufen

Ein Entwickler kann zehnmal am Tag bauen; ein Tester kann nicht zehnmal am Tag prüfen.Also finden manuelle Prüfungen am Ende eines Sprints statt, und ein Fehler, der am Donnerstag gefunden wird, wurde am Montag geschrieben.Die DORA-Seite zur Testautomatisierung sagt es deutlich: Manuelle Regressionstests sind zeitaufwendig in der Durchführung und teuer, was sie zum Engpass macht, und Entwickler bekommen keine schnelle Rückmeldung.

Es hinterlässt wenig Nachweise

Am Ende eines manuellen Durchgangs ist der Nachweis eine Liste von Häkchen, und manchmal ein Screenshot eines Fehlers.Niemand kann später sehen, wie der Bildschirm bei den bestandenen Schritten aussah, oder dieses Release mit dem letzten vergleichen.Wenn ein Fehlerbericht sagt „gestern ging es noch“, lässt sich weder das eine noch das andere beweisen.

Es unterscheidet sich von Tester zu Tester

Ein Testfall sagt „Bestellübersicht prüfen“.Ein Tester liest die Summe, ein anderer jede Zeile, ein dritter prüft auch das Datum.Jeder hat recht, und jeder Durchgang prüft etwas anderes.Derselbe Tester am Freitagnachmittag ist auch nicht derselbe Tester am Montagmorgen.

Seine Kosten wachsen mit jedem Release

Eine manuelle Prüfung kostet bei jeder Ausführung dieselben Stunden, für immer.Ein automatisierter Test kostet einmal Zeit für die Erstellung und etwas Pflege, wenn sich die App absichtlich ändert, und läuft dann für nicht mehr als Maschinenzeit.Je länger ein Produkt lebt, desto größer der Unterschied.

Warum manuelle Regressionstests zu lange dauern

Die Vervielfachung wird leicht unterschätzt, deshalb hier mit runden Zahlen.Nehmen Sie eine bescheidene Web-App mit 40 Szenarien, die vor einem Release geprüft werden sollten, mit etwa zehn Minuten pro Szenario von Hand.

Diese Zahlen sind eine Veranschaulichung, keine Umfrage: Ihre Szenarien dauern vielleicht fünf Minuten oder dreißig.Es kommt auf die Form an.Jeder Browser, jede Sprache und jedes Release vervielfacht die Stunden, während die Zahl der Tester gleich bleibt.

Deshalb werden manuelle Regressionstests zum Engpass eines Releases.Das Team wartet auf den Durchgang, oder es liefert aus, ohne ihn beendet zu haben.

Manuelles oder automatisiertes Testen, Aufgabe für Aufgabe

Die faire Antwort ist nicht „alles automatisieren“.Jede Art von Aufgabe hat einen besseren Weg.

Wann man Tests automatisiert und wann man sie manuell lässt

Warum QA-Teams nicht früher automatisiert haben

Wenn Automatisierung für wiederholte Prüfungen besser ist, warum machen so viele Teams sie noch von Hand?Vor allem wegen dessen, was Automatisierung bisher bedeutet hat: Code.

In Code-basierten Frameworks wie Playwright, Selenium, Cypress, Appium oder WinAppDriver ist ein Test ein Programm.Jemand schreibt ihn in einer Programmiersprache, findet jedes Element über einen Selektor und repariert diese Selektoren, wenn sich die Seite ändert: Die Dokumentation von Playwright warnt selbst, dass CSS- und XPath-Selektoren brechen können, wenn sich die Struktur der Seite ändert.

Also blieb der manuelle Testfall manuell: Die Person, die ihn am besten kannte, konnte ihn nicht automatisieren, und die Person, die es konnte, war anderweitig beschäftigt.Wenn trotzdem Suiten geschrieben wurden, haben Pflegeaufwand und instabile Ergebnisse sie oft zermürbt, wie Flaky Tests und Fehlalarme erklärt.

So wird aus einem manuellen Testfall ein automatisierter Test

GUI Test Studio, das End-to-End-Tests unter Windows automatisiert, wurde für die Person gebaut, die das Szenario schon kennt.Sie führen den Test einmal durch, so wie Sie ihn heute von Hand machen, und er wird zu einem Test, der von selbst läuft.Es funktioniert mit Desktop-Apps, Web-Apps, Spielen und Android-Telefonen.

1. 1

   Wählen Sie einen Testfall, den Sie bei jedem Release wiederholen

   Beginnen Sie mit einem Ablauf, den Ihr Team vor jedem Release von Hand prüft, etwa Anmelden, Suchen oder eine Bestellung aufgeben.Je öfter er wiederholt wird, desto schneller zahlt sich der automatisierte Test aus.

2. 2

   Notieren Sie seinen Ausgangspunkt

   Ein Test spielt genau das ab, was Sie getan haben, genau ab der Stelle, an der Sie begonnen haben.Notieren Sie den Bildschirm, das Konto und die Daten, von denen das Szenario ausgeht, und bringen Sie die App vor jedem Lauf dorthin zurück.

3. 3

   Nehmen Sie ihn einmal auf, oder beschreiben Sie ihn in einem Prompt

   Klicken Sie in GUI Test Runner-Recorder auf Aufzeichnen und führen Sie das Szenario selbst durch, in normalem Tempo.Oder fügen Sie die Schritte des manuellen Testfalls in einen Prompt ein, und Ihr KI-Assistent führt sie mit GUI Test Studio aus und speichert den Test.

4. 4

   Wählen Sie, was er prüft

   Wenn die Aufzeichnung endet, fragt die App, was dieser Test prüfen soll: visuelle Elemente, Text und das, was auf dem Bildschirm erscheint.Die Prüfungen werden beim Speichern des Tests erstellt, eine für jedes Element, das Sie verwendet haben.

5. 5

   Führen Sie ihn einmal aus, dann verfeinern Sie ihn

   Bringen Sie die App dorthin zurück, wo der Test beginnt, und klicken Sie auf Test ausführen.Öffnen Sie ihn dann in GUI Test Studio, um die wichtigen Schritte zu benennen, eine Prüfung hinzuzufügen, die die Aufzeichnung nicht gemacht hat, oder eine Wartezeit anzupassen.

6. 6

   Führen Sie ihn bei jedem Build aus

   Fügen Sie gtr-cli, den Befehlszeilen-Runner, Ihrer Pipeline hinzu.Er führt den Test wie die Schaltfläche Test ausführen aus und gibt Ihrem CI-Tool einen Exit-Code und eine JUnit-Datei.

7. 7

   Lesen Sie den Bericht, wenn er fehlschlägt

   Jeder Lauf schreibt einen Konfidenzbericht: das Ergebnis, jeden Schritt und für jede fehlgeschlagene Prüfung das erwartete Bild neben dem gefundenen, mit dem Video des Laufs.

Die Aufzeichnung: der manuelle Testfall, einmal durchgeführt

Eine Aufzeichnung ist der manuelle Durchgang, ein letztes Mal durchgeführt.Klicken Sie auf Aufzeichnen, wählen Sie den Bildschirm, eine App, eine Web-App, einen Bereich oder ein Telefon, und spielen Sie das Szenario durch wie ein Benutzer.Drücken Sie die Stopp-Taste, wenn Sie fertig sind.Einen Test aufzeichnen zeigt jeden Schritt, und Ihr erster Test führt in wenigen Minuten durch eine Übungsseite.

Ein Prompt: der Testfall, so geschrieben, wie Sie ihn schon schreiben

Wenn Ihre Testfälle schon aufgeschrieben sind, kann ein Prompt schneller sein.Fügen Sie die Schritte in das Fenster Test mit einem Prompt erstellen oder bearbeiten ein und senden Sie sie an Ihren KI-Assistenten: Claude, ChatGPT mit Codex oder ein lokales KI-Modell, eines von uns oder Ihr eigenes.Der Assistent führt die Schritte mit GUI Test Studio aus, prüft, was Sie verlangt haben, und speichert den Test.Siehe Einen Test aus einem Prompt erstellen.

Vergrößern

Wählen, was er prüft

Ein manueller Tester entscheidet, worauf er schaut.Die Aufzeichnung auch: Wenn sie endet, fragt sie, was dieser Test prüfen soll.Visuelle Elemente prüfen prüft jedes Element, das Sie angeklickt oder in das Sie getippt haben, Text prüfen prüft die Wörter, und Erscheinendes prüfen prüft die Menüs, Dialoge und Meldungen, die ohne Klick erscheinen.Was prüfen erklärt jede Wahl.

Vergrößern

Jede Prüfung betrifft, was der Benutzer sieht, nicht, wie die App gebaut ist.Um jedes Element zu finden, fragt die GTS Engine + AI zuerst die Anwendung, und findet das Element optisch, wenn die Anwendung es nicht sagt.Es gibt keinen Selektor, den man schreiben oder aktuell halten muss.

Bei jedem Build ausführen

gtr-cli, der Befehlszeilen-Runner, führt einen Test genau wie die Schaltfläche Test ausführen aus und fügt hinzu, was eine Pipeline braucht: einen Exit-Code, eine JUnit-Datei und alle Nachweise eines Fehlers in einem Ordner.Er funktioniert mit jedem CI/CD-Tool.Tests in Ihrer Pipeline ausführen listet alle Optionen auf.

gtr-cli run tests --junit results\junit.xml

Vergrößern

Was ein automatisierter Lauf zurückgibt

Hier beantwortet ein automatisierter Test den schwächsten Punkt eines manuellen Durchgangs.Jeder Lauf schreibt einen Konfidenzbericht, der mit dem Test aufbewahrt wird.

Vergrößern

Von dort macht Fehlerbericht aus einem Fehlschlag einen ausgefüllten Bericht oder einen Jira-Vorgang, mit den Bildern im Anhang.Die Anleitung Der Konfidenzbericht zeigt, wie man ihn liest.

Ist manuelles Testen tot?

Nein, und das sollte es auch nicht sein.Was endet, ist das manuelle Regressionstesten: dieselben festgelegten Prüfungen, von Hand durchgegangen, Release für Release.Die Tester, die diese Arbeit gemacht haben, wissen, welche Szenarien zählen, und genau das braucht ein automatisierter Test.

Wenn die wiederholten Prüfungen automatisiert sind, verbringt ein QA-Team seine Zeit mit explorativem Testen, mit neuen Funktionen und mit den Fragen, die nur ein Mensch stellt.Die Tests laufen bei jedem Build, und die Tester prüfen, was sie gefunden haben.

Neu im Tool?Erste Schritte mit GUI Test Studio zeigt einen ersten Test von Anfang bis Ende.

Das Wichtigste in Kürze

• 1Manuelle und automatisierte Tests erledigen verschiedene Aufgaben: Menschen erkunden und urteilen, automatisierte Tests wiederholen dieselben Prüfungen jedes Mal auf dieselbe Weise.
• 2Manuelle Funktions- und End-to-End-Prüfungen reichen nicht, sobald sie sich wiederholen: Sie werden mit jedem Release, jedem Browser und jeder Sprache langsamer, und sie können nicht bei jedem Build laufen.
• 3Wiederholung lässt Menschen Dinge übersehen: Selbst Experten übersehen, wonach sie nicht suchen, und zwei Tester prüfen denselben Testfall unterschiedlich.
• 4Code hat viele QA-Teams vom Automatisieren abgehalten: In einem Code-basierten Framework ist ein Test ein Programm mit Selektoren, die man schreiben und pflegen muss.
• 5GUI Test Studio macht aus dem manuellen Szenario einen Test: Nehmen Sie es einmal auf oder beschreiben Sie es in einem Prompt, führen Sie es bei jedem Build mit gtr-cli aus und lesen Sie einen Bericht mit Bildern und Video.

Fragen

Playwright, Selenium, Cypress, Appium, WinAppDriver, Chrome, Edge, Firefox, Claude, ChatGPT, Codex, Jira und Windows sind Marken ihrer jeweiligen Inhaber.