Warum testen? Fehlerkosten und V-Modell

Software ohne Tests ist wie ein Flugzeug ohne TÜV: vielleicht fliegt es, vielleicht stürzt es ab – niemand weiß es vorher. Diese Lektion eröffnet einen kompletten Kurs zum Thema Testen: ein Pflichtbereich der IHK-Prüfung und eine Kern-Disziplin für alle FIAEs und FISIs. Du lernst hier die Grundlagen: warum testen überhaupt wichtig ist, wie sich Fehlerkosten über die Projektphasen entwickeln, und wie das V-Modell Entwicklung und Test systematisch verbindet.

Die folgenden Lektionen bauen darauf auf: Teststufen, Black-Box und White-Box-Tests, TDD, Unit-Tests, Mocking und Testdokumentation. Wer hier sicher ist, hat Punkte in der Klausur und Vertrauen in den eigenen Code.

1) Was ist eigentlich „testen"?

Im Alltag ist „testen" eine vage Tätigkeit: man klickt herum, schaut, ob das Programm „funktioniert". In professioneller Softwareentwicklung ist Testen ein strukturierter Prozess: man definiert Erwartungen, führt das System unter klaren Bedingungen aus, vergleicht Ergebnis mit Erwartung. Wenn beide übereinstimmen, bestanden. Wenn nicht, Fehler dokumentieren.

Die offizielle Definition nach ISTQB (dem internationalen Software-Tester-Verband): „Testen ist der Prozess der Planung, Ausführung und Bewertung von Tests, mit dem Ziel, die Qualität von Software-Produkten zu verbessern." Drei Stichworte stechen heraus: Prozess (nicht ad hoc), Bewertung (nicht nur ausführen), Qualität (das eigentliche Ziel).

Wichtige Unterscheidung gleich am Anfang: Testen findet Fehler – beweist aber nie ihre Abwesenheit. Das ist der Dijkstra-Satz, einer der berühmtesten der Informatik. Auch das gründlichste Test-Set kann übersehene Fälle haben. Deshalb arbeitet man mit systematischen Methoden, um die Wahrscheinlichkeit hoher Restfehler zu minimieren.

2) Begriffsklärung: Fehler, Fehlerwirkung und Co.

Im Test-Vokabular werden mehrere ähnliche Begriffe unterschieden, die in Klausuren gerne abgefragt werden. Sie folgen einer Ursache-Wirkung-Kette:

3) Warum testen? Die wirtschaftliche Seite

Manche Entwicklungs-Teams sehen Testen als „lästige Pflicht", die Zeit kostet. Genau umgekehrt: Tests sparen massiv Geld. Das berühmteste Diagramm der Test-Welt zeigt die Fehlerkosten-Kurve: je später ein Fehler entdeckt wird, desto teurer wird seine Behebung – exponentiell.

4) Die Phasen im Detail – probier es aus

Klick durch die Phasen und sieh, was sie ausmacht und warum die Kosten so steigen:

5) Das V-Modell – Test als Spiegelbild der Entwicklung

Das V-Modell ist das berühmteste Vorgehensmodell zum Testen. Idee: jeder Entwicklungsphase wird eine passende Test-Phase zugeordnet. Das Modell sieht wie ein „V" aus: links der Abstieg vom Allgemeinen zum Konkreten (Entwicklung), rechts der Aufstieg vom Konkreten zum Allgemeinen (Test).

6) Verifikation und Validierung – Vorsicht, Doppelgänger

Zwei Begriffe, die ständig verwechselt werden, aber Klausurklassiker sind:

• Verifikation beantwortet die Frage: „Bauen wir das System richtig?" Erfüllt das Produkt seine Spezifikation? Das prüft man durch Komponententests und Integrationstests – sie vergleichen Implementierung mit Entwurf.
• Validierung beantwortet die Frage: „Bauen wir das richtige System?" Erfüllt das Produkt die Bedürfnisse des Kunden? Das prüft man durch Abnahmetests – sie vergleichen Endprodukt mit Anforderungen.

Eselsbrücke: Verifikation = nach Spezifikation. Validierung = nach Validität (= echter Kundennutzen).

7) Die 7 Grundsätze des Testens (ISTQB)

Der ISTQB hat sieben fundamentale Prinzipien formuliert, die in fast jeder Test-Klausur auftauchen können. Lerne sie:

1. Testen zeigt die Anwesenheit von Fehlern – aber nie deren Abwesenheit (Dijkstra).
2. Vollständiges Testen ist unmöglich – außer für trivial kleine Systeme. Man muss priorisieren.
3. Frühes Testen spart Zeit und Geld – siehe Boehm-Kurve oben.
4. Fehler treten gehäuft auf – ein Modul mit Bugs hat oft noch mehr. „Pareto-Verteilung der Fehler".
5. Pestizid-Paradox – immer gleiche Tests finden irgendwann keine neuen Fehler mehr. Tests müssen weiterentwickelt werden.
6. Testen ist kontextabhängig – ein Medizingerät wird anders getestet als eine Shopping-App.
7. Trugschluss „keine Fehler = brauchbar" – ein fehlerfreies System, das die falschen Anforderungen erfüllt, hilft niemandem (Validierung!).

8) Fehlerklassen – nicht jeder Bug ist gleich kritisch

In der Praxis priorisiert man Fehler nach Schwere. Die typische Einteilung – auch bekannt aus jedem Bug-Tracker wie Jira:

9) Wer testet eigentlich? – Rollen im Test

In professionellen Teams sind diese Rollen verbreitet:

• Entwickler*innen schreiben Unit-Tests für ihren eigenen Code. „Test-Driven Development" macht das zur Routine (siehe L5).
• Tester*innen / QA Engineers machen System- und Integrationstests, schreiben Testpläne, prüfen ganze Anwendungen aus User-Sicht.
• Test-Automatisierer bauen die Test-Infrastruktur in CI/CD-Pipelines auf (Selenium, Cypress, Playwright).
• Product Owner / Stakeholder machen den Abnahmetest – prüfen, ob das System ihre fachlichen Anforderungen erfüllt.

Auch wichtig: „Du selbst" testet schlechter als jemand Anderes. Der Autor von Code sieht oft genau dieselben Annahmen wie beim Schreiben, übersieht eigene Lücken. Daher: Pair-Reviews, Crossing-Tests im Team, externe Testabteilung in größeren Projekten.

10) Statisches vs. dynamisches Testen

Zwei grundsätzlich verschiedene Ansätze:

• Statisches Testen: Code wird nicht ausgeführt. Stattdessen wird das Artefakt analysiert: Code-Review, statische Analyse-Tools (SonarQube, ESLint), Doku-Review. Findet Probleme früh – Tippfehler, Style-Verstöße, unsichere Patterns.
• Dynamisches Testen: Code wird ausgeführt, Verhalten beobachtet. Klassische Unit-Tests, Integration-Tests, manuelle Tests. Findet Probleme im echten Verhalten.

Beide Ansätze ergänzen sich. In modernen Pipelines läuft statische Analyse bei jedem Commit (Lint), dynamische Tests bei jedem Push (CI). Vgl. auch K51 L9 API-Testing.

11) Klausurrelevante Punkte

• Boehm-Kurve: Fehlerkosten steigen exponentiell, früh testen lohnt sich.
• V-Modell: jede Entwicklungsphase hat eine Test-Phase als Spiegelbild.
• Verifikation vs. Validierung: „Bauen wir das System richtig?" vs. „Bauen wir das richtige System?"
• Begriffe: Irrtum → Fehler → Fehlerzustand → Fehlerwirkung.
• ISTQB-Grundsätze: 7 Prinzipien kennen – besonders „keine Abwesenheit beweisbar" (Dijkstra).
• Fehlerklassen: Schwere vs. Priorität unterscheiden.

Zusammenfassung

Begriffskette: Irrtum → Fehler → Fehlerzustand → Fehlerwirkung (das nach außen sichtbare Verhalten). Tests beweisen nie die Abwesenheit von Fehlern (Dijkstra). Boehm-Kurve: Fehlerkosten steigen exponentiell von 1× (Analyse) auf 100–1000× (Produktion). V-Modell: jede Entwicklungsphase hat eine spiegelbildliche Test-Phase. Verifikation = Spec erfüllt? Validierung = Kundenbedürfnis erfüllt? Fehlerklassen: Blocker/Hoch/Mittel/Niedrig – Schwere ≠ Priorität. Nächste Lektion: Teststufen.