·
8 min
Welche Tests automatisieren? Kriterien, Checkliste und was manuell bleibt
Roman Kirchmeier - Autemos
Tests automatisieren lohnt sich für Prüfungen, die sich oft wiederholen, stabil laufen und viel genutzte Geschäftsabläufe absichern, allen voran Regressionstests. Manuell bleiben explorative Tests, subjektives Look-and-Feel, einmalige Prüfungen und alles, was menschliches Urteil verlangt. Diese Linie zieht der ISTQB-Lehrplan Test Automation Strategy (CT-TAS v1.0) vom Mai 2024 mit konkreten Auswahlkriterien (ISTQB CT-TAS, 2024). Sein Lehrbuchbeispiel für schwer automatisierbare Tests stammt aus dem Finanzbereich: ein Kreditantrag mit manueller Prüfung durch Sachbearbeitende. Wie die Auswahl in das Gesamtvorhaben passt, zeigt der Leitfaden zur Einführung von Testautomatisierung.
Kurz gefasst: Automatisieren Sie zuerst stabile Regressionstests, die häufig laufen und viel genutzte Abläufe abdecken. Der ISTQB CT-TAS (2024) liefert dafür Prüffragen von technischer Machbarkeit bis ROI. Explorative Tests, Look-and-Feel, Barrierefreiheit und Abläufe mit manuellen Entscheidungen, etwa ein Kreditantrag mit Prüfung durch Sachbearbeitende, brauchen weiterhin Menschen.
Abbildung 1: Was automatisiert wird und was manuell bleibt, nach ISTQB CT-TAS (2024)
Welche Tests sollten Sie automatisieren und welche nicht?
Automatisieren sollten Sie Tests, die oft und immer gleich ablaufen, deren Ergebnis ein Werkzeug eindeutig bewerten kann und die stabile, viel genutzte Funktionen abdecken. Den Einstieg benennt der ISTQB klar: „The easiest opportunity for transitioning from manual testing to test automation is to target regression testing“ (ISTQB CT-TAS, 2024). Der erste Kandidat ist damit der Regressionstest.
Die folgende Tabelle ordnet gängige Testarten ein. Sie ist eine Faustregel und ersetzt nicht die Prüfung des einzelnen Testfalls.
Testart | Automatisieren? | Begründung |
|---|---|---|
Regressionstest stabiler Kernabläufe | Ja, zuerst | Läuft nach jeder Änderung, gleiche Schritte, klares Soll-Ergebnis |
Smoke-Test | Ja | Kurz, läuft bei jedem Build, schnelle Rückmeldung |
Bestätigungstest nach Fehlerbehebung | Ja, wenn er in die Regressionssuite wandert | Einmal ausgeführt kommt der Aufwand selten zurück |
Datengetriebene Tests, Browser- und Gerätekombinationen | Ja | Viele Permutationen, manuell kaum zu schaffen |
Last- und Stresstests | Ja, mit spezialisiertem Werkzeug | Brauchen Lasterzeugung und Monitoring |
Explorative Tests | Nein | Lernen und Fragen stellen bleibt Menschenarbeit |
Look-and-Feel, UI-Konsistenz | Nein | Subjektives Urteil, laut CT-TAS ein Fall für menschliche Prüfung |
Barrierefreiheit | Teilweise | Werkzeuge finden einen Teil der Barrieren, den Rest prüfen Menschen |
Einmalige Tests, kurzlebige Funktionen | Meist nein | Erstellung und Wartung zahlen sich nicht aus |
Abläufe mit manueller Freigabe (z. B. Kreditentscheid) | Teilweise | Systemschritte automatisieren, der Entscheid bleibt beim Menschen |
Tests mit langen Wartezeiten (z. B. Session-Timeout) | Nur mit Mocks | Die Zeit muss sich über Mocks oder Serverantworten steuern lassen |
Was ist der Unterschied zwischen Testen und Prüfen?
Testen ist ein Lernprozess, den Werkzeuge nur unterstützen können; Prüfen (Checking) ist der mechanische Abgleich festgelegter Aussagen über ein Produkt, den ein Werkzeug übernehmen kann. Die Unterscheidung stammt von James Bach und Michael Bolton. In der 2024 vereinfachten Fassung heißt es: „Checking is the mechanistic process of verifying propositions about the product“ (Bach & Bolton, 2024).
Für die Auswahl heißt das: Automatisieren Sie Prüfungen, deren erwartetes Ergebnis Sie vorab exakt formulieren können. Martin Fowler hält es für ein Warnsignal, wenn ein Team gar nicht explorativ testet: „I would consider it a red flag if a team isn’t doing exploratory testing at all“ (Fowler, 2019).
Checkliste: Nach welchen Kriterien wählen Sie Tests zum Automatisieren aus?
Der ISTQB CT-TAS (§3.3.1) bewertet jeden Kandidaten mit Prüffragen zu Machbarkeit, Kompetenz, Wirtschaftlichkeit, Häufigkeit, Wiederholbarkeit, Wartbarkeit und Wiederverwendung (ISTQB CT-TAS, 2024). Gehen Sie die Fragen pro Testfall durch und notieren Sie Ja oder Nein:
Abbildung 2: Zehn Prüffragen pro Testfall nach ISTQB CT-TAS §3.3.1
Technisch machbar? Das Werkzeug muss Oberfläche, Schnittstelle oder Plattform des Systems ansteuern können.
Ist das Team geschult? Ohne Kenntnisse in Werkzeug und Framework entstehen Skripte, die niemand pflegt.
Ist der ROI angemessen? Erstellung und Wartung müssen sich über die geplanten Läufe rechnen.
Bringt häufige Ausführung Wert? Ein Test, der jede Nacht läuft, zahlt sich schneller aus als einer pro Quartal.
Funktional oder nicht-funktional? Die Art bestimmt Werkzeug und Testebene.
Gehört er zur Smoke-, Regressions- oder Bestätigungssuite? Diese Suiten laufen wiederholt.
Ist er wiederholbar? Gleiche Eingaben müssen zum gleichen erwarteten Ergebnis führen.
Bleibt er wartbar, wenn sich das System ändert? Tests auf instabilen Oberflächen kosten bei jedem Release Zeit.
Deckt er häufig genutzte Geschäftsabläufe ab? Fehlerzustände dort treffen viele Nutzer.
Gibt es funktionale Überschneidungen? Gemeinsame Schritte wie ein Login und gemeinsame Testdaten lassen sich wiederverwenden.
Eine einfache Praxisregel, keine ISTQB-Vorgabe: Ein Test mit fast nur Ja-Antworten gehört nach oben auf die Liste. Bei einem Nein zu Machbarkeit oder Wiederholbarkeit klären Sie zuerst die Ursache. Warum ein kurzer Build-Check fast immer alle Fragen besteht, zeigt der Beitrag zum Smoke-Test.
Welche Tests kann nur die Automatisierung leisten?
Der CT-TAS (§3.3.2) nennt acht Situationen, in denen manuelles Testen praktisch ausscheidet, von zu langen Laufzeiten bis zu Stresstests mit großer Nutzerlast (ISTQB CT-TAS, 2024). Liegt einer dieser Fälle vor, planen Sie die Automatisierung von Anfang an ein:
Die manuelle Ausführung dauert zu lange.
Ausführungen müssen zeitlich synchronisiert sein.
Die Ergebnisse werden direkt in der CI/CD-Pipeline gebraucht.
Große Logdateien müssen ausgewertet werden.
Präzises Timing ist gefordert.
Es gibt viele Permutationen aus Betriebssystemen, Browsern, Geräten und Konfigurationen.
Es braucht große Mengen an Ausführungen oder Dateneingaben.
Nicht-funktionale Tests verlangen automatisiertes Monitoring oder sehr viele Nutzereingaben, etwa Stress- und Zuverlässigkeitstests.
Ein Beispiel aus dem Bankumfeld: dasselbe E-Banking in mehreren Browsern, auf iOS und Android, mit verschiedenen Kontotypen. Jeder weitere Kontotyp vervielfacht die Zahl der Durchläufe, und große Mengen an Ausführungen oder Dateneingaben nennt der CT-TAS ausdrücklich als Fall für die Automatisierung (ISTQB CT-TAS, 2024). Last- und Stresstests brauchen spezialisierte Werkzeuge, funktionale UI-Werkzeuge decken sie nicht ab.
Welche Tests sollten manuell bleiben?
Manuell bleiben Tests, die ein menschliches Urteil verlangen: subjektives Look-and-Feel, Abläufe mit vielen manuellen Eingriffen, Funktionen mit Einschränkungen auf Betriebssystemebene wie native SMS und lange Wartezeiten, die sich nicht über Mocks verkürzen lassen (ISTQB CT-TAS, 2024).
Abbildung 3: Kreditantrag aufteilen, Systemschritte automatisieren, Entscheid bleibt beim Menschen
Der Foundation-Lehrplan führt das Gegenteil als Risiko: die „Verwendung eines Testwerkzeugs, wenn manuelles Testen besser geeignet ist“ (ISTQB CTFL Lehrplan 4.0.2, 2025). Eine Umfrage von 2012 unter 115 Praktikern zeigt dieselbe Haltung: 80 % widersprachen der Vorstellung, automatisierte Tests würden manuelles Testen vollständig ersetzen (Rafi et al., Umfrage 2012).
Warum ist ein Kreditantrag das Lehrbuchbeispiel?
Der CT-TAS illustriert zu viel menschliche Interaktion mit einem Beispiel aus dem Finanzbereich: einem Kreditantrag, bei dem Sachbearbeitende die Angaben prüfen und manuell entscheiden (ISTQB CT-TAS, 2024). Bei Banken und Versicherern stecken Freigaben, Vier-Augen-Prüfungen und manuelle Entscheide in vielen Kernprozessen.
Ein solcher Ablauf lässt sich in der Regel aufteilen. Antragserfassung, Datenübernahme und die Statusänderung nach dem Entscheid können automatisierte Tests über API und Oberfläche abdecken. Der Entscheid selbst bleibt ein menschliches Urteil; im Test setzen Sie ihn über vorbereitete Testdaten oder eine stellvertretende Freigabe im Testsystem.
Was gilt für Barrierefreiheit?
Barrierefreiheit lässt sich nur teilweise automatisch prüfen. Das W3C schreibt: „Tools cannot check all accessibility aspects automatically. Human judgement is required.“ (W3C WAI, abgerufen 2026). Ein Test des britischen Government Digital Service auf einer absichtlich fehlerhaften Seite zeigt die Größenordnung: Alle Werkzeuge zusammen fanden 71 % der Barrieren, das beste einzelne 37 % (GOV.UK, 2017). Die Zahlen sind illustrativ, nicht aktuell.
Wie hilft die Testpyramide bei der Auswahl?
Die Testpyramide beantwortet, auf welcher Ebene Sie einen Test automatisieren: viele schnelle Tests auf Unit- und API-Ebene, wenige langsame Tests über die Oberfläche. Die Testpyramide ist laut ISTQB „ein Modell, das zeigt, dass verschiedene Tests eine unterschiedliche Granularität haben können“ (ISTQB CTFL Lehrplan 4.0.2, 2025). Google nannte 2015 eine Aufteilung von 70 % Unit-, 20 % Integrations- und 10 % E2E-Tests, ausdrücklich „as a good first guess“ (Google Testing Blog, 2015). Das ist eine Heuristik, keine Norm; die Mischung unterscheidet sich je Team.
Abbildung 4: Flaky Tests nach Testgröße (Quelle: Google Testing Blog, 2017)
Martin Fowler formuliert dasselbe ohne Zahlen: „you should have many more low-level UnitTests than high level BroadStackTests running through a GUI“ (Fowler, 2012). Der Grund ist Stabilität. Google wertete 2017 seine Tests nach Größe aus: 0,5 % der kleinen, 1,6 % der mittleren und 14 % der großen Tests waren flaky, lieferten bei gleichem Code mal Erfolg, mal Fehlschlag (Google Testing Blog, 2017).
Prüfen Sie vor jedem geplanten UI-Test, ob sich dieselbe Geschäftsregel tiefer testen lässt, etwa über die API. Die Oberfläche bleibt wenigen durchgehenden Abläufen vorbehalten. Wie die Ebenen zusammenspielen, erklärt der Beitrag zur Testpyramide und ihren Ebenen.
Wie priorisieren Sie, welche Tests Sie zuerst automatisieren?
Beginnen Sie mit der bestehenden manuellen Regressionssuite, prüfen Sie jeden Kandidaten gegen die Checkliste und automatisieren Sie zuerst die Tests mit dem größten Nutzen pro Aufwand. Die folgende Reihenfolge stützt sich auf CT-TAS §1.1.2, §3.3.1, §5.1.1 und §6.1.1 (ISTQB CT-TAS, 2024):
Kandidaten sammeln. Listen Sie die manuellen Regressionstests auf, die bei jedem Release laufen.
Manuellen Test prüfen. Läuft er fehlerfrei und reproduzierbar? Laut CT-TAS ergibt ein fehlerhafter manueller Test nur einen nicht funktionierenden automatisierten Test. Klären Sie die Ursache zuerst.
Checkliste anwenden. Bewerten Sie jeden Kandidaten mit den zehn Fragen oben.
Ebene wählen. Testen Sie jede Regel so tief in der Pyramide wie möglich.
Nutzen und Aufwand schätzen. Der CT-TAS rechnet ROI als Verhältnis: Einsparung geteilt durch Investition. Die Rechnung im Detail steht im Beitrag zum ROI der Testautomatisierung.
Wiederverwendbares zuerst bauen. Eine gemeinsame Login-Komponente und eine einzige Datenquelle sparen bei jedem weiteren Test Zeit.
Klein starten. Der CT-TAS empfiehlt ein Pilotprojekt, um Werkzeuge und Machbarkeit zu prüfen. Automatisieren Sie zuerst eine überschaubare Menge.
Regelmäßig ausmustern. Entfernen Sie Tests, die keinen Wert mehr liefern; der CT-TAS zählt das zu den Erfolgsfaktoren.
Planen Sie Budget für den Übergang ein. Der CT-TAS warnt: „the project should expect increased costs as both manual testing and automated testing take place simultaneously“ (ISTQB CT-TAS, 2024). Wo diese Auswahl in Ihrer übergeordneten Planung verankert wird, beschreibt der Beitrag zur Teststrategie.
Wo unterstützt der AI Recorder von Autemos?
Der AI Recorder von Autemos ist eine Aufnahmefunktion, die aus einem Jira-Ticket, einer User Story oder einem Testfall in Klartext einen ausführbaren Test-Workflow entwirft. Jeden KI-generierten Schritt prüft und genehmigt Ihr Team, bevor er läuft. Der Recorder setzt ausgewählte Tests um; welche Tests automatisiert werden, entscheidet weiterhin Ihr Team. Autemos deckt funktionale Tests für Web, Mobile, API und Desktop ab; Last-, Performance- und Sicherheitstests gehören nicht zum Umfang. Details stehen auf der Seite zum AI Recorder.
Häufig gestellte Fragen
Kann man alle Tests automatisieren?
Nein, Tests mit menschlichem Urteil wie explorative Tests, Look-and-Feel oder manuelle Entscheide lassen sich nicht vollständig automatisieren. Der ISTQB CT-TAS nennt als Beispiel einen Kreditantrag, bei dem Sachbearbeitende manuell entscheiden (ISTQB CT-TAS, 2024).
Welche Tests sollte man zuerst automatisieren?
Zuerst automatisieren Sie stabile Regressionstests, die oft laufen und viel genutzte Abläufe abdecken; der ISTQB CT-TAS (2024) nennt sie den einfachsten Einstieg. Prüfen Sie vorher, ob der manuelle Test zuverlässig funktioniert.
Welcher Anteil der Tests sollte automatisiert sein?
Eine belegte Idealquote gibt es nicht: Der ISTQB-Lehrplan zählt den „Grad der Testautomatisierung“ zu den Größen, die vom Kontext abhängen (ISTQB CTFL Lehrplan 4.0.2, 2025). Eine Herstellerumfrage von Applitools unter knapp 1000 Unternehmen ergab, dass die Mehrheit weniger als die Hälfte ihrer Tests automatisiert hatte (SD Times, 2022). Googles 70/20/10 betrifft Testebenen, nicht manuell gegenüber automatisiert.
Lohnt sich Testautomatisierung bei kurzen Projekten?
Oft nicht: Laut CT-TAS lohnt sich Testautomatisierung nicht, wenn die geplante Projektdauer unter dem ROI-Wendepunkt liegt (ISTQB CT-TAS, 2024). Rechnen Sie Einsparung und Investition vorab durch.
Kann KI entscheiden, welche Tests automatisiert werden?
Nein, KI kann Tests entwerfen, die Auswahl bleibt eine Entscheidung Ihres Teams. Der ISTQB-Lehrplan nennt es ein Risiko, sich zu stark auf ein Werkzeug zu verlassen und das menschliche kritische Denken zu vernachlässigen (ISTQB CTFL Lehrplan 4.0.2, 2025). KI-Entwürfe brauchen eine menschliche Freigabe.
Fazit
Welche Tests Sie automatisieren, entscheidet sich am einzelnen Testfall: Läuft er oft, ist er wiederholbar und wartbar, deckt er einen viel genutzten Ablauf ab und rechnet sich der Aufwand? Dann gehört er auf die Liste, beginnend mit der Regressionssuite.
Explorative Tests, Look-and-Feel, Barrierefreiheit und Abläufe mit manuellen Entscheiden wie der Kreditantrag bleiben beim Menschen. Die Testpyramide sagt Ihnen, auf welcher Ebene Sie einen Test bauen, und die Google-Zahlen von 2017 zeigen, dass große Tests am häufigsten flaky sind. Wenn Sie Ihre Regressionssuite mit uns durchgehen und erste Kandidaten im AI Recorder entwerfen möchten, vereinbaren Sie ein Gespräch mit unserem Team.
