In der Abschlussprüfung für Fachinformatiker Anwendungsentwicklung taucht das Thema Qualitätssicherung gleich an mehreren Stellen auf. Geprüft werden unter anderem Testverfahren und Testarten, die Auswahl des passenden Verfahrens, das Generieren von Testdaten sowie das Auswerten und Protokollieren der Ergebnisse. Eine Übersicht über alle Prüfungsinhalte findest du im Beitrag zu den Inhalten der Abschlussprüfung Teil 2 für Fachinformatiker Anwendungsentwicklung.

Ein Test hat ein klares Ziel: Fehler finden, bevor der Kunde sie findet. Dabei gilt ein Grundsatz, der gern falsch verstanden wird. Ein Test kann die Anwesenheit von Fehlern beweisen, aber nie deren Abwesenheit. Wer alle Tests besteht, hat keine fehlerfreie Software, sondern eine Software, in der die getesteten Fälle funktionieren.

Damit klar wird, worüber man spricht, hilft eine Abgrenzung:

• Verifikation: Bauen wir das Produkt richtig? Die Software erfüllt die festgelegte Spezifikation.
• Validierung: Bauen wir das richtige Produkt? Die Software erfüllt den tatsächlichen Bedarf des Kunden.

Die erste Einteilung trennt Verfahren danach, ob der Code ausgeführt wird oder nicht. Diese Unterscheidung wird in der Prüfung häufig abgefragt.

• Statische Verfahren: Hier wird der Code nicht ausgeführt. Geprüft werden Quelltext, Konzepte oder Dokumente. Dazu zählen das sogenannte Review (bei dem ein oder mehrere Personen den Code lesen), der Schreibtischtest (das gedankliche Durchspielen eines Ablaufs auf dem Papier) und die statische Codeanalyse durch Werkzeuge wie Linter.
• Dynamische Verfahren: In diesem Verfahren läuft das Programm. Man gibt Testdaten ein und vergleicht die tatsächliche mit der erwarteten Ausgabe. Unit-Tests, Integrationstests und End-to-End-Tests gehören in diese Kategorie.
   

Die zweite Einteilung trennt Verfahren danach, ob der Tester den inneren Aufbau des Codes kennt.

Beim sogenannten Black-Box-Test ist die innere Struktur unbekannt. Getestet wird nur gegen die Spezifikation: Welche Eingabe führt zu welcher Ausgabe? Der Code bleibt eine geschlossene Kiste. Typische Techniken sind die Äquivalenzklassenbildung und die Grenzwertanalyse.

Beim White-Box-Test hingegen ist der Quellcode bekannt. Die Testfälle werden so gewählt, dass möglichst viele Pfade durch den Code durchlaufen werden. Hier geht es um Überdeckung (auch genannt Coverage), zum Beispiel Anweisungs-, Zweig- oder Pfadüberdeckung.
 

Zwei Black-Box-Techniken solltest du benennen können:

• Äquivalenzklassenbildung: Eingaben werden in Klassen mit gleichem Verhalten zusammengefasst. Statt 1.000 Werte zu testen, prüft man einen Vertreter pro Klasse. Beispiel Alterseingabe: eine Klasse für gültige Werte (0 bis 120), je eine für zu kleine und zu große Werte.
• Grenzwertanalyse (Extremwerttest): Fehler treten besonders oft an den Rändern auf. Getestet werden die Werte direkt an der Grenze. Bei einer Grenze von 50 also 49, 50 und 51.

Tests lassen sich nach ihrem Umfang ordnen, vom kleinsten Baustein bis zum fertigen Gesamtsystem. In der Prüfung werden diese Stufen unter Begriffen wie Modultest, Integrationstest, Systemtest und Abnahmetest geführt.
 

Aus diesen Stufen ergibt sich eine Testpyramide. Sie ist eine Empfehlung zur Verteilung der Tests:

• Unten, breit: viele Unit-Tests. Sie sind schnell, günstig und zeigen präzise, wo ein Fehler liegt.
• Mitte: weniger Integrationstests.
• Oben, schmal: wenige End-to-End-Tests. Sie sind langsam und aufwendig, prüfen dafür den realen Ablauf.

Die Logik dahinter ist wirtschaftlich. Je tiefer ein Fehler gefunden wird, desto billiger ist seine Behebung. Ein Fehler im Unit-Test kostet Minuten, derselbe Fehler beim Kunden kostet ein Vielfaches.

Ein Test ist keine spontane Aktion, sondern ein geordneter Ablauf. Genau dieser Ablauf ist prüfungsrelevant, inklusive der Dokumentation. Ein typischer Testprozess hat fünf Schritte:

1. Testverfahren auswählen: Passend zum Ziel entscheiden, ob statisch oder dynamisch, Black-Box oder White-Box, welche Teststufe.
2. Testfälle und Sollergebnisse definieren: Für jede Eingabe festlegen, welche Ausgabe korrekt ist.
3. Testdaten generieren und auswählen: Repräsentative Daten bestimmen, etwa über Äquivalenzklassen und Grenzwerte.
4. Test durchführen: Ist-Ergebnis erzeugen und mit dem Soll-Ergebnis vergleichen.
5. Auswerten und protokollieren: Abweichungen dokumentieren, Fehler an die Entwicklung zurückspielen.

Zur Dokumentation gehören zwei Begriffe, die in der Prüfung vorkommen können. Das Testprotokoll hält fest, welche Testfälle mit welchem Ergebnis durchlaufen wurden. Das Abnahmeprotokoll dokumentiert die formale Abnahme durch den Kunden am Ende.

Test Driven Development (TDD), auf Deutsch testgetriebene Entwicklung, dreht die übliche Reihenfolge um. Normalerweise schreibt man erst den Code und testet danach. Bei TDD steht der Test am Anfang. Erst wenn ein Test existiert und fehlschlägt, wird der Code geschrieben, der ihn besteht.

Der Ablauf folgt einem kurzen Zyklus, dem Red-Green-Refactor:

1. Red: Einen Test für eine noch nicht vorhandene Funktion schreiben. Er schlägt fehl, weil der Code fehlt.
2. Green: Den einfachsten Code schreiben, der den Test bestehen lässt. Nicht mehr.
3. Refactor: Den Code aufräumen und verbessern, ohne sein Verhalten zu ändern. Die Tests müssen weiter grün bleiben.

Danach beginnt der Zyklus von vorn, für die nächste kleine Anforderung.

TDD an einem Beispiel

Gefordert ist eine Funktion für die Versandkosten eines Onlineshops. Die Regel: unter 50 Euro Bestellwert kostet der Versand 4,95 Euro, ab 50 Euro ist er kostenlos.

Schritt 1, Red. Zuerst der Test, noch ohne Funktion:

test "Versand kostet 4,95 Euro bei Bestellwert unter 50 Euro":

    erwarte versandkostenBerechnen(30) == 4.95

test "Versand ist kostenlos ab 50 Euro Bestellwert":

    erwarte versandkostenBerechnen(50) == 0.0

Beide Tests schlagen fehl, weil versandkostenBerechnen noch nicht existiert. Der Test ist rot.

Schritt 2, Green. Jetzt der einfachste Code, der beide Tests bestehen lässt:

funktion versandkostenBerechnen(bestellwert):

    wenn bestellwert < 50:

        gib 4.95 zurueck

    sonst:

        gib 0.0 zurueck
 

Die Tests laufen durch. Der Test ist grün.

Schritt 3, Refactor. Die feste Zahl 50 ist eine magische Konstante. Sie bekommt einen Namen, das Verhalten bleibt gleich:

funktion versandkostenBerechnen(bestellwert):

    konstante FREIGRENZE = 50

    konstante VERSANDKOSTEN = 4.95

    wenn bestellwert < FREIGRENZE:

        gib VERSANDKOSTEN zurueck

    sonst:

        gib 0.0 zurueck

Hier schließt sich der Kreis zu den Testverfahren. Die Grenze bei 50 Euro ist ein klassischer Fall für die Grenzwertanalyse. Sinnvolle Testfälle sind deshalb 49,99 (kostenpflichtig), 50,00 (kostenlos) und 50,01 (kostenlos). Genau an dieser Kante entstehen die typischen Fehler, etwa wenn jemand < und <= verwechselt.

Vorteile und Grenzen von TDD

TDD ist eine Methode, kein Allheilmittel. Eine ehrliche Einordnung gehört dazu.
 

Der Aufwand am Anfang zahlt sich vor allem bei Code aus, der lange gepflegt wird und sich oft ändert. Bei einem Wegwerf-Prototyp steht der Nutzen in einem anderen Verhältnis.

Wie das Thema in der Prüfung zusammenhängt

Hier lohnt eine klare Einordnung, damit du deine Zeit richtig einsetzt. Im Prüfungskatalog stehen die Testverfahren und Testarten: statisch und dynamisch, Black-Box und White-Box, die Teststufen sowie der Testprozess mit Testdaten und Protokollierung. Diese Begriffe musst du sicher erklären und anwenden können.

Test Driven Development wird im Katalog nicht ausdrücklich genannt. Trotzdem lohnt sich das Verständnis aus zwei Gründen. Erstens baut TDD direkt auf Unit-Tests auf, und die sind prüfungsrelevant. Zweitens ist TDD in der Praxis verbreitet und kann im Fachgespräch zur Projektarbeit zur Sprache kommen, wenn du in deinem Projekt testgetrieben gearbeitet hast.

Kurz gesagt: Lerne die Testverfahren und den Testprozess für die schriftliche Prüfung. Verstehe TDD als die Arbeitsweise, die Unit-Tests in den Entwicklungsalltag einbettet. Wie eine prüfungstaugliche Projektdokumentation aufgebaut sein muss, liest du im Beitrag Projektdokumentation Fachinformatiker Systemintegration.

Was ist der Unterschied zwischen statischen und dynamischen Tests? Bei statischen Tests wird der Code nicht ausgeführt, sondern gelesen oder analysiert, etwa im Review oder Schreibtischtest. Bei dynamischen Tests läuft das Programm mit Testdaten, und das Ergebnis wird mit dem Sollwert verglichen.

Was ist der Unterschied zwischen Black-Box- und White-Box-Test? Beim Black-Box-Test ist der innere Aufbau unbekannt, getestet wird nur gegen die Spezifikation. Beim White-Box-Test ist der Quellcode bekannt, und die Testfälle zielen auf eine möglichst hohe Überdeckung der Programmpfade.

Was ist ein Modultest beziehungsweise Unit-Test? Ein Test, der einen einzelnen Baustein isoliert prüft, meist eine Funktion oder Klasse. Modultests sind schnell und zeigen genau, an welcher Stelle ein Fehler liegt.

Was bedeutet Red-Green-Refactor? Der TDD-Zyklus. Red: einen fehlschlagenden Test schreiben. Green: den einfachsten Code schreiben, der den Test besteht. Refactor: den Code verbessern, ohne sein Verhalten zu ändern, während die Tests grün bleiben.

Ist TDD prüfungsrelevant? TDD wird im Prüfungskatalog nicht ausdrücklich genannt. Die zugrunde liegenden Unit-Tests und der Testprozess sind es. TDD kann zusätzlich im Fachgespräch zur Projektarbeit relevant werden.

Was ist die Grenzwertanalyse? Eine Black-Box-Technik, bei der gezielt die Werte an den Rändern eines Bereichs getestet werden, weil dort die meisten Fehler entstehen. Bei einer Grenze von 50 testet man 49, 50 und 51.

Was gehört in ein Testprotokoll? Welche Testfälle ausgeführt wurden, mit welchen Testdaten, welches Ergebnis erwartet wurde und welches tatsächlich eintrat. Abweichungen werden dokumentiert und an die Entwicklung gemeldet.

Wenn du wissen willst, wie die Prüfungsvorbereitung für deine Fachrichtung abläuft, findest du hier die Details zur Prüfungsvorbereitung für Fachinformatiker Anwendungsentwicklung.