Ein Funktionstest in der Software prüft, ob ein System die Funktionen erfüllt, die Anforderungen, User-Storys oder Spezifikationen festlegen. Geprüft wird beobachtbares Verhalten, etwa ob eine Überweisung gebucht wird oder das Tageslimit greift. Mit Prüfständen in der Elektronikfertigung oder medizinischen Untersuchungen hat der Begriff hier nichts zu tun. Der ISTQB-Lehrplan führt sie als eine von vier Testarten auf allen fünf Teststufen. Wie gut ein System seine Aufgaben erledigt, etwa wie schnell oder sicher, klären nicht-funktionale Tests. Banken und andere Finanzunternehmen müssen der Aufsicht zusätzlich zeigen, dass Änderungen vor dem Einsatz getestet wurden.

Kurz gefasst: Ein Funktionstest prüft, was eine Software tun soll, gemessen an Anforderungen und Akzeptanzkriterien. Der ISTQB-Lehrplan 4.0.2 führt ihn als eine von vier Testarten, anwendbar auf fünf Teststufen vom Komponententest bis zum Abnahmetest. Testfälle entstehen mit Äquivalenzklassen, Grenzwerten, Entscheidungstabellen und Zustandsübergängen. Regressionstests sind ein starker Kandidat für Automatisierung.

Abbildung 1: Funktionale Tests prüfen, was ein System tut, nicht-funktionale Tests, wie gut es das tut.

Was ist ein Funktionstest in der Software?

Ein Funktionstest ist eine Testart, die prüft, ob eine Komponente oder ein System die festgelegten Funktionen vollständig, korrekt und passend ausführt. Der deutschsprachige Lehrplan formuliert es so: „Beim funktionalen Test werden die Funktionen bewertet, die eine Komponente oder ein System erfüllen soll.“ (ISTQB-Lehrplan CTFL 4.0.2, 2025). „Funktionstest“ und „funktionaler Test“ meinen dasselbe.

Der Lehrplan nennt drei Prüfziele: „Das Hauptziel der funktionalen Tests ist die Überprüfung der funktionalen Vollständigkeit, der funktionalen Korrektheit und der funktionalen Angemessenheit.“ Am Beispiel eines Zahlungsauftrags im E-Banking heißt das:

• Funktionale Vollständigkeit: Kundinnen und Kunden können Aufträge erfassen, ändern, terminieren und stornieren, so wie es die Anforderungen vorsehen.

• Funktionale Korrektheit: Gebühren und Wechselkurse stimmen, ein Auftrag über dem Limit wird abgewiesen.

• Funktionale Angemessenheit: Die Funktionen passen zur Aufgabe, eine Standardzahlung braucht keine unnötigen Zwischenschritte.

Dieselben drei Untermerkmale bilden in ISO/IEC 25010:2023 das Qualitätsmerkmal funktionale Eignung (functional suitability). Die Norm beschreibt es als Fähigkeit eines Produkts, Funktionen bereitzustellen, die festgelegte und implizite Bedürfnisse der vorgesehenen Nutzer unter festgelegten Bedingungen erfüllen (ISO/IEC 25010:2023, 2023). Implizite Bedürfnisse zählen mit: Dass ein negativer Betrag abgewiesen wird, steht selten in der User-Story.

Wie sich diese Testart zu Smoke-Test, Regressionstest und anderen Begriffen verhält, zeigt die Übersicht der Testarten im Software-Testing.

Wie unterscheiden sich funktionale und nicht-funktionale Tests?

Funktionale Tests prüfen, was ein System tut; nicht-funktionale Tests prüfen, wie gut es das tut, gemessen an Qualitätsmerkmalen wie Performanz, Sicherheit oder Gebrauchstauglichkeit. Der ISTQB-Lehrplan ordnet diese Merkmale nach ISO/IEC 25010: Performanz, Kompatibilität, Gebrauchstauglichkeit, Zuverlässigkeit, Sicherheit (Security), Wartbarkeit, Übertragbarkeit und Sicherheit (Safety).

Die zweite Ausgabe der Norm vom November 2023 hat zwei Merkmale umbenannt und Safety ergänzt. Gebrauchstauglichkeit heißt dort Interaktionsfähigkeit, Übertragbarkeit heißt Flexibilität (ISO/IEC 25010:2023, 2023).

„Viele nicht-funktionale Tests leiten sich von funktionalen Tests ab“, heißt es im Lehrplan (ISTQB-Lehrplan CTFL 4.0.2, 2025). Ein Lasttest spielt oft denselben Überweisungsablauf durch und misst dabei die Antwortzeit.

Autemos automatisiert funktionale Tests über Web, Mobile (iOS und Android), API (REST und SOAP) und Desktop. Last- und Performancetests, Sicherheits- und Penetrationstests sowie die Messung der Codeüberdeckung gehören nicht zum Funktionsumfang. Dafür brauchen Sie spezialisierte Werkzeuge.

Auf welchen Teststufen finden Funktionstests statt?

Funktionstests finden auf allen fünf Teststufen statt, die der aktuelle ISTQB-Lehrplan beschreibt: Komponententest, Komponentenintegrationstest, Systemtest, Systemintegrationstest und Abnahmetest (ISTQB-Lehrplan CTFL 4.0.2, 2025). Viele deutschsprachige Seiten zeigen noch vier Stufen. Im Lehrplan ist der Systemintegrationstest eine eigene Stufe.

Abbildung 2: Funktionstests laufen auf allen fünf ISTQB-Teststufen.

Den Systemtest kann laut Lehrplan ein unabhängiges Testteam durchführen, Abnahmetests sollten idealerweise die vorgesehenen Benutzer durchführen. Für den Systemintegrationstest braucht es eine Testumgebung, die der Betriebsumgebung möglichst nahekommt.

Wie sich Systemtest und Integrationstest abgrenzen, erklärt der Beitrag zum Systemtest mit Zielen und Ablauf. Die Formen der Abnahme, vom Benutzerabnahmetest (UAT) bis zum regulatorischen Abnahmetest, behandelt der Artikel zu Abnahmetest und User Acceptance Testing. Eine kompakte Einführung in alle Stufen finden Sie in den Grundlagen des Software-Testings.

Ist ein Funktionstest immer ein Black-Box-Test?

Die Prüfung von Funktionen ist nicht automatisch ein Black-Box-Test, denn der ISTQB-Lehrplan führt funktionale, nicht-funktionale, Black-Box- und White-Box-Tests als vier eigenständige Testarten. Alle vier lassen sich auf jeder Teststufe anwenden, mit unterschiedlichem Schwerpunkt (ISTQB CTFL Syllabus v4.0.1, 2024).

Die beiden Begriffspaare beantworten verschiedene Fragen. Funktional oder nicht-funktional sagt, was geprüft wird: eine Funktion oder ein Qualitätsmerkmal. Black-Box oder White-Box sagt, woher die Tests stammen. Der Black-Box-Test „basiert auf Spezifikationen und leitet die Tests aus der Dokumentation ab, die sich nicht auf die interne Struktur des Testobjekts bezieht“ (ISTQB-Lehrplan CTFL 4.0.2, 2025). Der White-Box-Test nutzt Code, Architektur, Workflows oder Datenflüsse.

Daraus ergeben sich vier Kombinationen. Ein White-Box-Test einer Funktion prüft etwa, ob jeder Zweig einer Gebührenregel mindestens einmal durchlaufen wird und dabei das richtige Ergebnis liefert. Der Lehrplan erwähnt White-Box-Verfahren ausdrücklich für höhere Teststufen, zum Beispiel für API-Tests. Auf System- und Abnahmeebene entstehen diese Tests häufig aus Spezifikationen. Daher stammt die verbreitete Gleichsetzung.

Beide Ansätze mit ihren Techniken und Einsatzzeitpunkten vergleicht der Artikel Black-Box-Test und White-Box-Test im direkten Vergleich.

Mit welchen Testverfahren entstehen gute Testfälle?

Testfälle für funktionale Anforderungen entstehen im ISTQB-Lehrplan vor allem mit vier Black-Box-Testverfahren: Äquivalenzklassenbildung, Grenzwertanalyse, Entscheidungstabellentest und Zustandsübergangstest. Nötig sind sie, weil vollständiges Testen außer in trivialen Fällen nicht machbar ist, ein Grundsatz, den der Lehrplan auf Manna (1978) zurückführt (ISTQB CTFL Syllabus v4.0.1, 2024).

Bei der Äquivalenzklassenbildung reicht laut Lehrplan „ein Test je Klasse“, und die Klassen dürfen sich nicht überschneiden. Die 3-Wert-Grenzwertanalyse ist gründlicher und kann Fehler aufdecken, die die 2-Wert-Variante übersieht: Ist „x ≤ 10“ fälschlich als „x = 10“ umgesetzt, bleiben die Testwerte 10 und 11 unauffällig. Erst der Nachbarwert 9 deckt den Fehler wahrscheinlich auf.

Entscheidungstabellen halten komplexe Geschäftsregeln fest, ihre Regelanzahl wächst jedoch exponentiell mit der Zahl der Bedingungen. Beim Zustandsübergangstest ist die Überdeckung aller gültigen Übergänge laut Lehrplan das meistgenutzte Kriterium.

Der anwendungsfallbasierte Test (use case testing) gehört in CTFL v4.0.1 nicht mehr zu den Black-Box-Verfahren; in Version 3.1 stand er noch in der Liste. Ergänzend nennt der Lehrplan erfahrungsbasierte Verfahren: intuitive Testfallermittlung (Error Guessing), explorativer Test und checklistenbasierter Test. Sie finden Fehler, die andere Verfahren übersehen können. Wie Sie Klassen und Grenzwerte für echte Eingabefelder ableiten, zeigt die Anleitung zu Äquivalenzklassen und Grenzwertanalyse.

In welchen Schritten läuft die Prüfung ab?

Die Prüfung von Funktionen läuft in acht Schritten von der Testbasis über Testfälle und Testdaten bis zu den Endekriterien, die festlegen, wann die Testaktivität abgeschlossen ist. Ausgangspunkt sind meist Akzeptanzkriterien, laut Lehrplan „die Bedingungen, die eine Implementierung der User-Story erfüllen muss, um von den Stakeholdern akzeptiert zu werden“ (ISTQB-Lehrplan CTFL 4.0.2, 2025).

Abbildung 3: Der Ablauf von der Testbasis bis zu den Endekriterien.

1. Testbasis prüfen: Anforderungen, User-Storys und Akzeptanzkriterien lesen und Unklarheiten klären, bevor der Entwurf beginnt.

2. Testbedingungen ableiten: Je Anforderung festhalten, was geprüft wird, etwa „Auftrag über Limit wird abgewiesen“.

3. Testfälle und Testdaten entwerfen: Mit den Verfahren aus dem vorigen Abschnitt Eingaben und erwartete Ergebnisse festlegen.

4. Eingangskriterien prüfen: Testumgebung, Testdaten und ein lauffähiger Build sind verfügbar, die Smoke-Tests sind bestanden.

5. Tests durchführen: Manuell oder automatisiert, mit protokolliertem Ergebnis je Testfall.

6. Abweichungen melden: Schritte, erwartetes und tatsächliches Ergebnis, Umgebung und Testdaten dokumentieren.

7. Fehlernachtest und Regressionstest: Nach der Korrektur den Fehlerfall erneut prüfen und kontrollieren, ob die Änderung Bestehendes beschädigt hat.

8. Endekriterien bewerten: Überdeckungsgrad, ungelöste Fehlerzustände und fehlgeschlagene Testfälle mit den vereinbarten Schwellen vergleichen.

„Eingangskriterien und Endekriterien sollten für jede Teststufe definiert werden und unterscheiden sich je nach den Testzielen“, schreibt der Lehrplan. Aufgebrauchte Zeit oder ein ausgeschöpftes Budget können ebenfalls als Endekriterium gelten, sofern die Stakeholder das verbleibende Risiko akzeptieren.

Prüfbare Akzeptanzkriterien im Ticket sind die Grundlage für die folgenden Schritte. Schritt 7 wiederholt sich mit jedem Release; wie Sie die Suite dafür aufbauen, beschreibt der Beitrag zum Regressionstest in der Softwareentwicklung.

Welche Tests sollten Sie zuerst automatisieren?

Automatisieren Sie zuerst funktionale Regressionstests für stabile, geschäftskritische Abläufe, und setzen Sie jeden Test auf der niedrigsten Teststufe an, die das Verhalten noch aussagekräftig prüft. Der ISTQB-Lehrplan nennt Regressionstests einen starken Kandidaten für Automatisierung und empfiehlt, früh im Projekt damit zu beginnen (ISTQB CTFL Syllabus v4.0.1, 2024).

Ham Vocke rät, Tests so weit wie möglich nach unten in der Testpyramide zu schieben, und beschreibt Tests über den gesamten Stack als notorisch instabil (The Practical Test Pyramid, 2018). Google berichtete 2016, dass fast 16 % seiner Tests eine gewisse Flakiness zeigen (Google Testing Blog, 2016).

Gute Kandidaten für Automatisierung sind:

• Regressionstests für Login, Zahlungsauftrag und Kontoeröffnung, die bei jedem Release laufen

• Tests mit vielen Datenkombinationen aus Äquivalenzklassen und Grenzwerten

• Prüfungen von Geschäftsregeln über die API, unterhalb der Oberfläche

• Tests, die in der CI/CD-Pipeline bei jedem Merge Rückmeldung geben

Manuell bleiben sollten explorative Tests neuer Funktionen und Prüfungen an Oberflächen, die sich noch wöchentlich ändern. Für den explorativen Ansatz gibt es Evidenz: In einem kontrollierten Experiment mit 51 Studierenden fanden Itkonen und Mäntylä keinen signifikanten Unterschied in der Fehlerfindung gegenüber testfallbasiertem Testen, bei weniger Entwurfsaufwand (Empirical Software Engineering, 2014).

Automatisierte Oberflächentests kosten Pflege. Eine Studie mit Industriedaten von Siemens und Saab zeigt, dass die Wartungskosten beträchtlich sein können und häufige kleine Wartung günstiger ist als seltene große Überarbeitungen (Alégroth, Feldt, Kolström, 2016). Garousi und Mäntylä halten fest, dass die Entscheidung über Zeitpunkt und Umfang der Automatisierung vom Kontext abhängt und Fehlentscheidungen teuer werden können (Information and Software Technology, 2016).

Autemos ist eine KI-gestützte Plattform für Testautomatisierung der selementrix GmbH aus Baar. Der AI Recorder von Autemos entwirft aus einem Jira-Ticket, einer User-Story oder einem Testfall in Klartext einen ausführbaren Testablauf; jeder KI-generierte Schritt läuft erst, wenn Ihr Team ihn freigegeben hat. Web-Tests lassen sich als Playwright-Code (Java oder TypeScript) exportieren, mobile Tests als Appium (Java), und laufen dann ohne Autemos.

Self-Healing-Locators passen Selektoren nach Oberflächenänderungen an und dokumentieren jede Anpassung so, dass Ihr Team sie zurücknehmen kann. Das senkt die Locator-Pflege; Wartung an Testlogik und Testdaten bleibt. Wie automatisierte Tests in Build-Pipelines laufen, beschreibt der Beitrag zur Testautomatisierung in CI/CD.

Was verlangen FINMA und DORA von Softwaretests in Banken?

Das FINMA-Rundschreiben 2023/1 verlangt, funktionale und nicht-funktionale Anforderungen gemäß ihrer Kritikalität zu testen; DORA verlangt getestete, genehmigte und verifizierte Änderungen, ohne eine bestimmte Testart zu benennen. Keines der beiden Regelwerke schreibt ein bestimmtes Werkzeug oder Testautomatisierung vor.

Das Rundschreiben zu operationellen Risiken und Resilienz gilt seit dem 1. Januar 2024. Im Abschnitt Änderungsmanagement heißt es: „Bei Entwicklung und Beschaffung von IKT werden funktionale und nicht-funktionale Anforderungen klar definiert und genehmigt und gemäss ihrer Kritikalität getestet und validiert.“ (FINMA-RS 2023/1, 2022). Derselbe Abschnitt verlangt getrennte Umgebungen für Entwicklung oder Test und Produktion.

Die EU-Verordnung DORA (2022/2554) gilt seit dem 17. Januar 2025. Artikel 9 Absatz 4 Buchstabe e verlangt, dass alle Änderungen an IKT-Systemen kontrolliert erfasst, getestet, bewertet, genehmigt, umgesetzt und verifiziert werden. Nach Artikel 24 Absatz 6 testen Finanzunternehmen außer Kleinstunternehmen mindestens jährlich alle IKT-Systeme und Anwendungen, die kritische oder wichtige Funktionen unterstützen (DORA auf EUR-Lex, 2022).

Die Delegierte Verordnung (EU) 2024/1774 fordert in Artikel 16 ein Verfahren zum Testen und Genehmigen aller IKT-Systeme vor ihrer Nutzung und nach Wartung. Der Testumfang muss der Kritikalität der betroffenen Geschäftsprozesse und IKT-Assets entsprechen (Delegierte Verordnung 2024/1774, 2024).

DORA bindet Finanzunternehmen in der EU; Schweizer Banken betrifft die Verordnung über EU-Tochtergesellschaften oder EU-Geschäft. Unsere Einschätzung: Automatisierte funktionale Regressionstests, die in Jira/Xray mit Anforderungen verknüpft sind und Ergebnisse in Allure-Berichten ablegen, sind ein Weg, den verlangten Nachweis zu führen. Vorgeschrieben ist dieser Weg nicht.

Welche Irrtümer über diese Testart halten sich?

Ein hartnäckiger Irrtum rund um den Funktionstest ist die 1:10:100-Regel, nach der ein Fehler in jeder späteren Projektphase zehnmal teurer wird. Menzies et al. fanden in 171 Softwareprojekten aus den Jahren 2006 bis 2014 keinen Beleg für einen allgemeinen „delayed issue effect“ (Empirical Software Engineering 22, 2017).

Abbildung 4: Verbreitete Irrtümer und was Studien, ISTQB und ISO/IEC 25010 dazu sagen.

Die Autoren folgern, der Effekt solle nicht als allgemeingültige Wahrheit gelten. Einzelne spät gefundene Fehler können trotzdem sehr teuer sein. Wer Testbudgets mit der 1:10:100-Regel begründet, nennt ein Verhältnis, das diese Daten nicht bestätigen. Die übrigen Irrtümer betreffen Begriffe:

Ein Team, das eine eigene Funktionsprüfungsphase nach dem Integrationstest einplant, prüft Funktionen womöglich nie auf Komponentenebene.

Häufig gestellte Fragen

Was ist ein Funktionstest in der Softwareentwicklung?

Ein Funktionstest prüft, ob eine Software die Funktionen erfüllt, die Anforderungen, User-Storys oder Akzeptanzkriterien festlegen. Der ISTQB-Lehrplan 4.0.2 nennt als Hauptziel die Überprüfung der funktionalen Vollständigkeit, Korrektheit und Angemessenheit. ISO/IEC 25010:2023 fasst diese drei Untermerkmale unter funktionaler Eignung zusammen.

Was ist der Unterschied zwischen Funktionstest und Systemtest?

Der Funktionstest ist eine Testart, der Systemtest eine Teststufe. Tests von Funktionen laufen auf allen fünf ISTQB-Teststufen, vom Komponententest bis zum Abnahmetest. Der Systemtest prüft laut Lehrplan das Gesamtverhalten eines Systems und umfasst häufig funktionale und nicht-funktionale Prüfungen.

Ist ein Unit-Test ein Funktionstest?

Ein Unit-Test ist ein Test auf der Teststufe Komponententest und kann funktional oder nicht-funktional sein. Funktional ist er, wenn er prüft, ob eine Gebührenfunktion richtig rechnet. Nicht-funktional ist er, wenn er etwa die Laufzeit einer Methode misst. Der Unit-Test ist deshalb keine Unterart dieser Testart.

Kann man diese Tests automatisieren?

Regressionstests, die bei jeder Änderung wiederholt laufen, lassen sich am sinnvollsten automatisieren. Der ISTQB-Lehrplan nennt Regressionstests einen starken Kandidaten dafür. Explorative Tests neuer Funktionen bleiben meist manuell, und automatisierte Oberflächentests brauchen laut einer Studie mit Daten von Siemens und Saab laufende Wartung.

Verlangen DORA oder FINMA funktionale Tests?

FINMA verlangt im Rundschreiben 2023/1, funktionale und nicht-funktionale Anforderungen gemäß ihrer Kritikalität zu testen. DORA benennt keine bestimmte Testart, fordert aber getestete und genehmigte Änderungen und mindestens jährliche Tests der IKT-Systeme für kritische oder wichtige Funktionen. Automatisierung schreibt keines der beiden Regelwerke vor.

Fazit

Ein Funktionstest prüft, was eine Software tun soll, gemessen an Anforderungen und Akzeptanzkriterien. Nach ISTQB ist er eine Testart und kommt auf allen fünf Teststufen vor. Testfälle mit Aussagekraft entstehen mit Äquivalenzklassen, 2-Wert- oder 3-Wert-Grenzwerten, Entscheidungstabellen und Zustandsübergängen.

Automatisieren Sie zuerst stabile Regressionstests auf der niedrigsten sinnvollen Stufe, und planen Sie Wartung von Anfang an ein. Last-, Performance- und Sicherheitstests brauchen eigene Werkzeuge; Autemos deckt sie nicht ab. Für Banken zählt der Nachweis: FINMA verlangt Tests gemäß Kritikalität, DORA getestete und genehmigte Änderungen.

Wenn Sie sehen möchten, wie Autemos aus Ihren Jira-Stories freigabepflichtige Testabläufe entwirft und mit Xray verknüpft, vereinbaren Sie ein Gespräch mit dem Autemos-Team.