Testen & Qualitätssicherung — Fehler finden, bevor der Kunde sie findet
Prüfungsaufgaben fragen meist: Welche Teststufe ist das, und welches Verfahren passt? Wer die Begriffe sauber trennt, beantwortet das schnell.
Teststufen
| Stufe | Was wird geprüft | Wer testet |
|---|---|---|
| Unit-Test | einzelne Methode/Klasse isoliert | Entwickler |
| Integrationstest | Zusammenspiel mehrerer Komponenten, Schnittstellen | Entwickler |
| Systemtest | das Gesamtsystem gegen die Anforderungen | QA/Testteam |
| Abnahmetest | erfüllt es den Vertrag? (Validierung) | Auftraggeber |
Ergänzend: Regressionstest prüft, ob eine Änderung anderes kaputtgemacht hat — typischerweise automatisiert im Build.
Black Box gegen White Box
- Black Box: Tester kennt den Code nicht, prüft nur Ein-/Ausgabe gegen die Spezifikation. Verfahren: Äquivalenzklassenbildung, Grenzwertanalyse, Entscheidungstabellen.
- White Box: Tester kennt den Code und prüft Pfade und Bedingungen. Verfahren: Anweisungsüberdeckung, Zweigüberdeckung, Pfadüberdeckung.
- Grey Box: teilweise Einsicht — z. B. Schnittstellentest mit Kenntnis der Datenstrukturen.
Testfälle und Testplanung
Ein Testfall besteht aus Vorbedingung, Eingabe, erwartetem Ergebnis und Nachbedingung. Wichtig ist die Trennung von Testerwartung (was laut Spezifikation passieren soll) und tatsächlichem Ergebnis — nur so wird ein Fehler dokumentierbar.
- Positivtest: der erwünschte Normalfall.
- Negativtest: Fehleingaben, falsche Reihenfolge, Grenzen — hier finden sich die meisten Fehler.
- Smoke-Test: schneller Grobcheck, ob das System überhaupt startet.
Test-Driven Development (TDD)
Umgekehrter Ablauf, in drei Schritten wiederholt:
- Red: Test schreiben, der noch fehlschlägt.
- Green: so viel Code schreiben, dass er grün wird (nicht mehr).
- Refactor: aufräumen — Tests bleiben grün.
Vorteil: hohe Testabdeckung, klare Anforderungen, weniger Regressionen. Nachteil: Umdenken nötig, am Anfang langsamer.
Testpyramide
Viele schnelle Unit-Tests unten, weniger Integrationstests in der Mitte, wenige langsame Ende-zu-Ende-Tests oben. Die Pyramide ist der Gegenentwurf zum häufig anzutreffenden umgekehrten Zustand (viele brüchige E2E-Tests, kaum Unit-Tests).
Qualitätssicherung über das Testen hinaus
- Code Review: Vier-Augen-Prinzip vor dem Merge.
- Statische Analyse: Werkzeuge finden Stil- und Fehlerrisiken ohne Ausführung (Linter).
- Continuous Integration: jeder Push baut und testet automatisch.
- Definition of Done: wann gilt eine Aufgabe als fertig (getestet, dokumentiert, reviewt)?
Typische Prüfungsfallen
- Verifikation und Validierung vertauschen: „richtig gebaut" gegen „das Richtige gebaut".
- Unit-Test für Integration halten — ein Test, der eine Datenbank braucht, ist kein isolierter Unit-Test.
- Nur positive Tests planen — Negativtests finden die Fehler.
- TDD-Reihenfolge umdrehen: Test zuerst, dann Code.
- „Getestet = fehlerfrei" — Tests zeigen Fehler, sie beweisen nicht ihre Abwesenheit.
Weiter üben
Das Grundlagenwissen steht hier frei — geübt wird in der Lernplattform: über 1.300 Prüfungsfragen mit ausführlicher Erklärung zu jeder Antwort, Fortschritt im eigenen Konto.