Wer „Testarten” googelt, findet meist eine flache Liste, die Teststufen, Qualitätsmerkmale und Vorgehensweisen wild vermischt. Das hilft niemandem bei der Planung. Schlechte Softwarequalität kostete US-Unternehmen 2022 rund 2,41 Billionen US-Dollar (CISQ, 2022) – ein Großteil davon entsteht durch unentdeckte Fehler. Dieser Leitfaden ordnet das Feld sauber nach drei Achsen der ISTQB-Systematik: Wann getestet wird, was geprüft wird und wie vorgegangen wird. Sie erhalten eine praxistaugliche Teststufe×Testart-Matrix, aktuelle Marktdaten und konkrete Hinweise für regulierte Branchen wie Banken.

Kurz gefasst: Testarten lassen sich in drei Achsen trennen: Teststufen (wann), Qualitätsmerkmale (was) und Vorgehensweisen (wie). Diese Trennung verhindert die übliche Verwechslung von Integrationstest und Smoke-Test. Laut World Quality Report nutzen oder planen 68 % der Organisationen GenAI in der Qualitätssicherung (WQR 2024-25, 2024).

Abbildung 1: Die drei ISTQB-Achsen – wann, was und wie getestet wird.

Warum unterscheidet man überhaupt verschiedene Testarten?

Abbildung 4: Was schlechte Softwarequalität kostet – 2,41 Bio. US-Dollar.

Die saubere Unterscheidung von Testarten ist kein akademischer Selbstzweck, sondern senkt Kosten. Schlechte Softwarequalität verursachte in den USA 2022 Schäden von etwa 2,41 Billionen US-Dollar, davon 1,56 Billionen durch Betriebsausfälle (CISQ, 2022). Wer Testarten gezielt einsetzt, findet Fehler früher und günstiger.

Das Problem fast aller Online-Listen: Sie werfen Begriffe in einen Topf, die auf völlig unterschiedlichen Ebenen liegen. Ein Komponententest beschreibt, *wann* getestet wird. Ein Sicherheitstest beschreibt, *was* geprüft wird. Ein Smoke-Test beschreibt, *wie* man vorgeht. Diese drei Fragen vermengen sich in der Praxis ständig – und genau daraus entstehen Lücken im Testkonzept.

Die ISTQB-Systematik trennt deshalb drei Achsen. Das klingt zunächst pedantisch. Doch sobald Sie eine Teststrategie für ein reales Projekt aufsetzen, brauchen Sie diese Trennung, um keine Qualitätsmerkmale zu übersehen. Die folgenden Abschnitte gehen jede Achse einzeln durch.

Welche drei Achsen ordnen die Testarten?

Software-Testing gliedert sich nach ISTQB in drei voneinander unabhängige Achsen: Teststufen, Testarten im engeren Sinn und Vorgehensweisen. Diese Dreiteilung folgt den Normen ISO/IEC/IEEE 29119 (Prozess) und ISO/IEC 25010 (Qualitätsmodell) und ist die Grundlage des ISTQB Certified Tester Foundation Level v4.0.

Die erste Achse – die Teststufen – beantwortet die Frage nach dem Zeitpunkt im Entwicklungsablauf. Die zweite Achse – die Testarten im engen Sinn – fragt nach dem geprüften Qualitätsmerkmal gemäß ISO/IEC 25010. Die dritte Achse – die Vorgehensweisen – beschreibt die Aktivität oder Methode.

Ein praktisches Beispiel macht das greifbar. Ein Regressionstest auf Systemebene, der das funktionale Verhalten prüft, kombiniert alle drei Achsen: Systemtest (Stufe), funktionaler Test (Art) und Regression (Vorgehen). Erst wenn Sie diese Koordinaten benennen können, ist Ihr Testfall eindeutig beschrieben.

Die drei Achsen im Überblick

• Achse A – Teststufen (wann): Komponententest/Unit-Test, Integrationstest, Systemtest, Abnahmetest.

• Achse B – Testarten (was): Funktionaler Test, nicht-funktionaler Test, Performanz-, Usability-, Sicherheits- und Strukturtest.

• Achse C – Vorgehensweisen (wie): Smoke-Test, Regressionstest, End-to-End-Test, exploratives Testen, Re-Test, Black-/White-Box.

Was sind die vier Teststufen (Achse A)?

Abbildung 2: Die vier Teststufen vom Komponenten- bis zum Abnahmetest.

Die vier Teststufen ordnen Tests nach ihrem Zeitpunkt im Entwicklungsprozess: Komponententest, Integrationstest, Systemtest und Abnahmetest. Sie folgen der Logik des V-Modells und prüfen schrittweise von der kleinsten Einheit bis zum Gesamtsystem aus Anwendersicht. Jede Stufe hat eigene Verantwortliche, Werkzeuge und Fehlerklassen.

Der Komponententest (Unit-Test) prüft die kleinste isolierte Einheit – meist eine Funktion oder Klasse. Entwicklerinnen schreiben ihn typischerweise selbst, oft testgetrieben. Der Integrationstest prüft das Zusammenspiel mehrerer Komponenten und deren Schnittstellen; viele Fehler verstecken sich genau hier, an den Übergängen zwischen Modulen.

Der Systemtest betrachtet das vollständig integrierte System gegen die spezifizierten Anforderungen. Der Abnahmetest (Akzeptanztest) schließlich validiert aus Sicht des Auftraggebers oder Nutzers. Er kennt mehrere Untertypen: den User-Acceptance-Test (UAT), den Betriebsabnahmetest, den regulatorischen sowie den vertraglichen Abnahmetest. Gerade für Banken ist der regulatorische Abnahmetest mit prüffähigen Nachweisen zentral.

Jede Stufe bringt eigene Verantwortliche, Werkzeuge und typische Fehlerbilder mit. Die folgende Übersicht macht greifbar, wer auf welcher Stufe womit prüft – und welche Fehlerklasse dort vorrangig auftritt:

Auffällig: Je höher die Stufe, desto teurer wird die Fehlerbehebung – ein an der Schnittstelle übersehener Defekt schlägt im Systemtest oft als schwer lokalisierbares Folgeproblem durch. Genau deshalb lohnt sich eine bewusste Verteilung der Prüftiefe über alle vier Stufen statt eines späten Großtests kurz vor dem Release.

Wie verschieben sich die Verantwortlichkeiten?

Mit jeder Stufe wandert die Perspektive vom Code zum Geschäftswert. Unten testet die Entwicklung technisch, oben prüft das Fachbereichs- oder Compliance-Team gegen reale Anforderungen. In der Praxis zeigt sich, dass Teams die mittleren Stufen – Integration und System – am häufigsten unterschätzen.

Was prüfen die Testarten im engeren Sinn (Achse B)?

Testarten im engeren Sinn prüfen einzelne Qualitätsmerkmale gemäß ISO/IEC 25010 – etwa Funktionalität, Performanz oder Sicherheit. Die wichtigste Trennung verläuft zwischen funktionalen und nicht-funktionalen Tests. Funktionale Tests fragen, *ob* die Software das Richtige tut; nicht-funktionale Tests fragen, *wie gut* sie es tut.

Zu den nicht-funktionalen Testarten zählen mehrere klar abgegrenzte Familien. Der Performanz-, Last- und Stresstest misst Antwortzeiten und Verhalten unter Spitzenlast. Der Gebrauchstauglichkeitstest (Usability) prüft die Bedienbarkeit aus Nutzersicht. Der IT-Sicherheitstest sucht nach Schwachstellen und Angriffsflächen.

Hinzu kommen Tests für Zuverlässigkeit, Kompatibilität und Portabilität sowie der strukturbasierte White-Box-Test, der die innere Code-Struktur und Überdeckung betrachtet. Diese Merkmale lassen sich nicht beliebig vertagen. Wer Sicherheit oder Performanz erst kurz vor dem Go-live prüft, riskiert teure Nacharbeit – ein wiederkehrendes Muster in vielen Projekten.

Welche Vorgehensweisen gibt es (Achse C)?

Vorgehensweisen beschreiben, *wie* getestet wird – nicht wann oder was. Dazu gehören Smoke-Test, Regressionstest, End-to-End-Test, exploratives Testen und Re-Test. Diese Methoden lassen sich über mehrere Stufen und Qualitätsmerkmale hinweg anwenden und sind deshalb keine eigene „Ebene”, sondern eine Querschnittsdimension.

Der Smoke-Test prüft als schneller Funktionsdurchlauf, ob ein Build überhaupt stabil genug für tiefere Tests ist – die Rauchprobe vor dem eigentlichen Prüflauf. Der Regressionstest stellt sicher, dass bestehende Funktionen nach Änderungen weiterhin korrekt arbeiten. Beide werden häufig automatisiert, weil sie oft und unverändert wiederholt laufen.

Der End-to-End-Test bildet komplette Geschäftsprozesse über alle Systeme hinweg ab und prüft sie aus Anwendersicht. Exploratives Testen dagegen verzichtet bewusst auf Skripte: Erfahrene Testende erkunden die Anwendung gezielt und stoßen auf Fehler, die starre Testfälle übersehen. Der Re-Test (Fehlernachtest) verifiziert schließlich eine korrigierte Fehlerbehebung.

Wie hängen Teststufen und Testarten zusammen?

Abbildung 3: Die Teststufe×Testart-Matrix als Planungs-Checkliste.

Teststufen und Testarten sind keine Alternativen, sondern Koordinaten desselben Plans: Jede Stufe kann mehrere Testarten enthalten. Genau diese Kombinatorik unterschlagen die meisten Online-Listen. Die folgende Matrix zeigt, welche Testart auf welcher Stufe typischerweise sinnvoll ist – das zentrale Planungswerkzeug für Ihre Teststrategie.

Lesen Sie die Matrix als Checkliste: Jede Zelle mit „typisch” gehört in ein vollständiges Testkonzept. Auffällig ist, dass nicht-funktionale Merkmale wie Performanz und Usability erst auf System- und Abnahmeebene ihr volles Gewicht entfalten. Wer sie früher mitdenkt, vermeidet späte Überraschungen – verschieben lassen sie sich aber selten ganz nach vorn.

Die Vorgehensweisen aus Achse C legen sich quer über diese Matrix. Ein Regressionstest etwa kann auf jeder Stufe und für jede Testart laufen. Deshalb ist er in keiner Spalte fest verortet, sondern eine Methode, die Sie auf die jeweils passende Zelle anwenden.

Wie verändert KI die Testarten?

Künstliche Intelligenz verändert vor allem das *Wie* der Testdurchführung, nicht die Taxonomie selbst. 72 % der Organisationen berichten, dass GenAI ihre Testautomatisierung beschleunigt hat (WQR 2024-25, 2024). Die Testarten bleiben dieselben – KI senkt jedoch den Aufwand, sie umzusetzen.

Den größten Hebel hat KI bei wiederholbaren Vorgehensweisen wie Regression und Smoke-Tests. Selbstheilende Lokatoren erkennen geänderte UI-Elemente automatisch und reduzieren so die berüchtigte Pflegelast brüchiger Testskripte. Visuelle Recorder erlauben es auch nicht-technischen Fachleuten, funktionale End-to-End-Tests aufzuzeichnen. Diese Mechanismen wirken über Web, Mobile, API und Desktop hinweg.

Konkret bildet sich KI heute so auf einzelne Testarten ab:

• Regressionstest: Selbstheilende Lokatoren halten große Suites trotz UI-Änderungen lauffähig und senken die Pflegelast.

• Smoke-Test: KI generiert schlanke Build-Verification-Checks, die als schnelles Gate in die Pipeline passen.

• Funktionaler und End-to-End-Test: Visuelle Recorder zeichnen reale Nutzerflüsse ohne Skripting auf.

• Strukturbasierter Test: Modelle schlagen Testfälle für ungedeckte Code-Pfade vor und erhöhen die Überdeckung.

Nicht jede Testart profitiert gleich stark. Exploratives Testen etwa lebt von menschlicher Neugier und lässt sich nicht sinnvoll automatisieren – KI liefert hier höchstens Hinweise, wo sich genaueres Hinsehen lohnt.

Trotz des Hypes bleibt eine Lücke. 57 % der Befragten verfügen über keine umfassende Testautomatisierungsstrategie, und 64 % nennen Altsysteme als Hürde (WQR 2024-25, 2024). Werkzeuge allein lösen das nicht. Wie Sie KI sinnvoll auf die einzelnen Testarten abbilden, vertieft unser Leitfaden zur KI-gestützten Testautomatisierung.

Was ist vom „100×”-Mythos zu halten?

Wenig. Die oft zitierte Behauptung, ein Fehler koste in Produktion das Hundertfache, ist eine nicht belegbare Zombie-Zahl ohne Primärquelle. Belastbar ist dagegen der CISQ-Befund von 2,41 Billionen US-Dollar Schaden (CISQ, 2022). Argumentieren Sie mit Quellen, nicht mit Faustregeln.

Lohnt sich der Aufwand wirtschaftlich?

Strukturiertes Testen mit klarer Testautomatisierung zahlt sich messbar aus, auch wenn Zahlen je nach Kontext schwanken. In einer von Forrester für Tricentis durchgeführten Fallstudie erreichte ein SAP-Anwender einen ROI von 403 % und 83 % schnellere Releases (Tricentis/Forrester, 2026). Das ist ein Einzelfall, kein Branchendurchschnitt – aber ein aussagekräftiger.

Der Gesamtmarkt für Testautomatisierung wächst entsprechend. Analysten schätzen das Volumen von 25,43 Milliarden US-Dollar (2022) auf 92,45 Milliarden bis 2030, was einer jährlichen Wachstumsrate von rund 17,3 % entspricht (Grand View Research, 2023). Die Schätzungen einzelner Analysten variieren, doch die Richtung ist eindeutig.

Auch die Datenbasis professionalisiert sich. Der Einsatz synthetischer Testdaten stieg von 14 % (2024) auf 25 % (2025) (WQR 2025-26, 2025). Für regulierte Branchen ist das relevant: Synthetische Daten umgehen Datenschutzhürden, ohne den Testabdeckungsgrad zu senken.

Wie wählen regulierte Branchen die richtigen Testarten?

Banken und regulierte Unternehmen müssen Testarten an Nachweispflichten ausrichten, nicht nur an technischen Risiken. Der regulatorische Abnahmetest erzeugt prüffähige Belege, die Aufsichtsanforderungen wie DORA oder BaFin-Vorgaben standhalten. Hier zählt nicht allein, *dass* getestet wurde, sondern dass es lückenlos dokumentiert ist.

Diese Anforderung verschiebt das Gewicht der Achsen. Während Start-ups oft auf schnelle Smoke- und Regressionstests setzen, müssen Banken die Abnahmestufe mit auditierbaren Artefakten unterlegen. Sicherheits- und Zuverlässigkeitstests rücken nach vorn, weil Ausfälle und Datenlecks regulatorisch sanktioniert werden.

Eine praktische Konsequenz: Die Testautomatisierung muss revisionssichere Protokolle liefern. In Kundenprojekten im DACH-Raum zeigt sich, dass automatisierte, versionierte Testnachweise die Abstimmung mit Prüfern spürbar verkürzen. Den passenden technischen Unterbau dafür beschreibt unser Beitrag zum Integrationstest und seinen Schnittstellennachweisen.

Häufig gestellte Fragen

Was ist der Unterschied zwischen Teststufe und Testart?

Eine Teststufe beschreibt den Zeitpunkt im Entwicklungsprozess (Komponente, Integration, System, Abnahme), eine Testart das geprüfte Qualitätsmerkmal (funktional, Performanz, Sicherheit). Beide sind unabhängige Achsen: Auf einer Stufe lassen sich mehrere Testarten anwenden. Die ISTQB-Systematik trennt sie bewusst, um Lücken im Testkonzept zu vermeiden.

Wie viele Testarten gibt es?

Es gibt keine feste Zahl, weil sich Testarten an den Qualitätsmerkmalen der ISO/IEC 25010 orientieren. Praktisch unterscheidet man rund acht Hauptfamilien: funktional, Performanz, Usability, Sicherheit, Zuverlässigkeit, Kompatibilität, Portabilität und strukturbasiert. Hinzu kommen Vorgehensweisen wie Smoke-, Regressions- und End-to-End-Test als eigene Achse.

Welche Testarten sollte man automatisieren?

Wiederholbare, stabile Vorgehensweisen wie Regressions- und Smoke-Tests eignen sich am besten zur Automatisierung, weil sie häufig und unverändert laufen. 72 % der Organisationen berichten, dass GenAI ihre Testautomatisierung beschleunigt hat (WQR 2024-25, 2024). Exploratives Testen bleibt dagegen menschlich.

Sind Smoke-Test und Sanity-Test dasselbe?

Nein, beide sind verwandte, aber unterschiedliche Vorgehensweisen. Der Smoke-Test prüft breit und oberflächlich, ob ein Build grundsätzlich lauffähig ist. Der Sanity-Test prüft eng und gezielt, ob eine bestimmte Korrektur funktioniert. Beide sind schnelle Filter vor tieferen Testläufen, aber mit verschiedenem Fokus.

Welche Testarten verlangen Banken zwingend?

Banken priorisieren Abnahme-, Sicherheits- und Zuverlässigkeitstests mit prüffähiger Dokumentation. Regulatorische Rahmen wie DORA und BaFin-Vorgaben verlangen auditierbare Nachweise über den gesamten Teststufenverlauf. Funktionale Tests allein genügen nicht; entscheidend ist die lückenlose, revisionssichere Protokollierung jeder Testdurchführung.

Fazit

Testarten werden erst dann zum Steuerungsinstrument, wenn man sie sauber nach drei Achsen trennt: Teststufen für den *Zeitpunkt*, Testarten für das *Qualitätsmerkmal*, Vorgehensweisen für die *Methode*. Die Teststufe×Testart-Matrix macht aus dieser Theorie eine handfeste Checkliste, mit der Sie keine relevante Prüfung übersehen. Angesichts von 2,41 Billionen US-Dollar Schaden durch schlechte Softwarequalität (CISQ, 2022) ist diese Disziplin keine Kür. KI senkt heute den Aufwand für wiederholbare Testarten spürbar – ersetzt aber weder Strategie noch Fachwissen. Wenn Sie Ihre Teststrategie über Web, Mobile, API und Desktop hinweg automatisieren wollen, sprechen Sie mit dem Autemos-Team über Ihren konkreten Anwendungsfall.