Einordnung im CTFL-Lehrplan
Dass es im ISTQB Foundation Level (CTFL) 4.0.2 (und den Versionen davor) ein spezifisches Kapitel für statisches Testen (Kapitel 3) gibt, aber kein dediziertes Kapitel mit dem Namen „Dynamisches Testen“, liegt an der strukturellen Einordnung der Themen:
Statisches Testen als eigenständige Disziplin: Statisches Testen (Reviews und statische Analyse) ist eine in sich geschlossene Gruppe von Aktivitäten, die unabhängig von der Testausführung stattfinden. Es lässt sich daher gut in einem kompakten Kapitel zusammenfassen.
Dynamisches Testen ist das „Hauptthema“: Fast der gesamte restliche Lehrplan befasst sich mit Aspekten des dynamischen Testens, auch wenn das Wort nicht im Kapiteltitel steht. Es ist so umfangreich, dass es in mehrere Phasen und Techniken unterteilt wird:
Kapitel 2 (Testen im Softwarelebenszyklus): Behandelt Teststufen (wie Komponenten-, System- oder Abnahmetest), die fast ausschließlich dynamisch sind.
Kapitel 4 (Testverfahren): Hier werden die Techniken (Black-Box, White-Box, erfahrungsbasiert) erläutert, mit denen Testfälle für das dynamische Testen entworfen werden.
Kapitel 5 (Testmanagement): Behandelt die Planung und Steuerung, die primär auf die Durchführung dynamischer Tests ausgerichtet sind.
Zusammenfassend: Statisches Testen wird als spezielle Methode separat behandelt, während das dynamische Testen das „Rückgrat“ des gesamten Softwaretestens bildet und daher über mehrere Kapitel (Lebenszyklus, Verfahren, Durchführung) verteilt ist, statt in einem einzigen Kapitel isoliert zu werden.
① Was ist statisches Testen? — CTFL Kap. 3.1 · FL-3.1.1 (K1)
Statischer Test
Kein Ausführen des Codes
Static Testing
Beim statischen Test wird das Arbeitsergebnis ohne Ausführung geprüft — durch manuelle Durchsicht (Review) oder automatisierte Werkzeuge (statische Analyse).
Anwendbar auf: Anforderungen · Quellcode · Testkonzepte · Testfälle · Backlog-Einträge · Test-Chartas · Projektdokumentation · Verträge · Architekturbeschreibungen.
Nicht geeignet für: ausführbare Binärdateien, Arbeitsergebnisse die ein Werkzeug nicht lesen kann, oder schwer menschlich interpretierbar sind.
Anwendbar auf: Anforderungen · Quellcode · Testkonzepte · Testfälle · Backlog-Einträge · Test-Chartas · Projektdokumentation · Verträge · Architekturbeschreibungen.
Nicht geeignet für: ausführbare Binärdateien, Arbeitsergebnisse die ein Werkzeug nicht lesen kann, oder schwer menschlich interpretierbar sind.
Review
Statische Analyse
Frühe Fehlerfindung
Kein Testfall nötig
Dynamischer Test
Software wird ausgeführt
Dynamic Testing
Beim dynamischen Test wird die Software tatsächlich ausgeführt — Eingaben werden geliefert, Ausgaben mit Erwartungen verglichen.
Liefert: Fehlerwirkungen (Failures) → aus diesen werden durch Analyse die zugrundeliegenden Fehlerzustände (Defects) ermittelt.
Ergänzt den statischen Test — beide Methoden decken zusammen die meisten Fehlerzustände ab. Kein Ersatz füreinander.
Liefert: Fehlerwirkungen (Failures) → aus diesen werden durch Analyse die zugrundeliegenden Fehlerzustände (Defects) ermittelt.
Ergänzt den statischen Test — beide Methoden decken zusammen die meisten Fehlerzustände ab. Kein Ersatz füreinander.
Testfälle erforderlich
Fehlerwirkung sichtbar
Laufzeitumgebung nötig
Zusammenhang — Fehlerzustand vs. Fehlerwirkung: Statischer Test findet Fehlerzustände direkt (z.B. falscher Algorithmus im Code sichtbar). Dynamischer Test produziert eine Fehlerwirkung (z.B. falsches Ergebnis) — der Fehlerzustand muss dann erst durch Debugging gefunden werden. Statisch = direkt; dynamisch = indirekt — und statischer Test kann die Fehlerkette unterbrechen, bevor eine Fehlerwirkung überhaupt entstehen kann.
② Statisch vs. Dynamisch — CTFL Kap. 3.1 · FL-3.1.2 / FL-3.1.3 (K2)
Statischer Test ↔ Dynamischer Test — Vergleich der wesentlichen Merkmale
| Merkmal | Statischer Test | Dynamischer Test |
|---|---|---|
| Ausführung | Software wird nicht ausgeführt | Software wird ausgeführt |
| Fehlerfindung | Fehlerzustände werden direkt identifiziert | Fehlerwirkungen treten auf → Fehlerzustände durch Analyse ermitteln |
| Testobjekte | Alle lesbaren Arbeitsergebnisse: Code, Anforderungen, Testfälle, Dokumente… | Nur ausführbare Arbeitsergebnisse |
| Zeitpunkt | Sehr früh möglich — noch vor erster Codezeile (Anforderungsreviews) | Erst wenn lauffähige Software vorhanden ist |
| Werkzeuge | Statische Analyse-Werkzeuge (Linter, SAST), Checklisten | Testausführungswerkzeuge, Testrahmen, Emulatoren |
| Kosten | Kein Testfall nötig → oft kostengünstiger pro gefundenem Fehlerzustand | Testfalldesign, -ausführung und -umgebung verursachen Aufwand |
| Stärken | Inkonsistente Anforderungen · Toter Code · Sicherheitslücken · Schnittstellenfehler · Standardabweichungen | Laufzeitfehler · Performance · Integrationsfehler · Benutzerinteraktion |
| Qualitätsmerkmale | Misst laufzeitunabhängige Merkmale: z.B. Wartbarkeit | Misst laufzeitabhängige Merkmale: z.B. Performanz, Zuverlässigkeit |
③ Typische Fehlerzustände — durch statischen Test effizient aufdeckbar · FL-3.1.2 (K2)
In Anforderungen
Qualitätsprobleme der Spezifikation
Inkonsistenzen
Mehrdeutigkeiten
Widersprüche
Auslassungen
Ungenauigkeiten
Duplikationen
Dynamisch kaum findbar — inkonsistente Anforderungen führen zu inkonsistenten Testfällen die den Fehler nicht aufdecken.
Im Code
Strukturelle Code-Probleme
Unerreichbarer Code
Undefinierte Variablen
Nicht deklarierte Variablen
Duplizierter Code
Übermäßige Komplexität
Sicherheitslücken (Pufferüberläufe)
SAST-Werkzeuge erkennen diese automatisch — Verbindung zu Kap. 6 Testwerkzeuge.
Entwurf & Schnittstellen
Architektur- und Schnittstellenprobleme
Ineffiziente Datenbankstrukturen
Schlechte Modularität
Falsche Parameteranzahl/-typ/-reihenfolge
Standardabweichungen
Lücken in Testdeckung
Auch: nicht wie gewünscht implementierte Entwurfsmuster.
④ Frühzeitiges Stakeholder-Feedback — CTFL Kap. 3.2 · FL-3.2.1 (K1)
Warum früh?
Vorteile frühzeitigen Feedbacks
Wenn Stakeholder während des SDLC nur wenig einbezogen werden, entspricht das entwickelte Produkt oft nicht den tatsächlichen Anforderungen — ein teures Late-Stage-Problem.
Häufiges Feedback: beugt Missverständnissen vor · Anforderungsänderungen werden früher erkannt · Entwickler verstehen Erwartungen besser.
Häufiges Feedback: beugt Missverständnissen vor · Anforderungsänderungen werden früher erkannt · Entwickler verstehen Erwartungen besser.
Shift-Left
Missverständnisse vermeiden
Änderungskosten senken
Agile Praxis
Kollaborative Reviewformate
In agilen Projekten arbeiten Tester, Fachbereichsvertreter (Product Owner, Businessanalysten) und Entwickler gemeinsam — z.B. beim Example Mapping, beim Schreiben von User Stories und beim Backlog Refinement.
Statisches Testen ist kein reines Wasserfall-Konzept — es ist in Agile integriert, oft als kontinuierliche Peer Reviews und als Teil der Definition of Ready/Done.
Statisches Testen ist kein reines Wasserfall-Konzept — es ist in Agile integriert, oft als kontinuierliche Peer Reviews und als Teil der Definition of Ready/Done.
Example Mapping
User Story Review
Backlog Refinement
⑤ Aktivitäten des Reviewprozesses — ISO/IEC 20246 · FL-3.2.2 (K2)
Generischer Reviewprozess (ISO/IEC 20246) — sequenziell, aber iterierbar für große Arbeitsergebnisse
Schritt 1
Planung
Umfang & Zweck festlegen · Arbeitsergebnis wählen · Qualitätsmerkmale bestimmen · Endekriterien formulieren · Reviewart & Checklisten wählen · Teilnehmer & Zeitplan
→
Schritt 2
Reviewbeginn
Alle Beteiligten vorbereiten · Zugänge sicherstellen · Einführungssitzung · Fragen klären · Commitment einholen
→
Schritt 3
Individuelles Review
Jeder Gutachter prüft selbstständig · Anomalien, Empfehlungen & Fragen notieren · Reviewtechniken anwenden (Checkliste, szenariobasiert…)
→
Schritt 4
Kommunikation & Analyse
Anomalien diskutieren · Nicht jede Anomalie = Fehlerzustand · Status entscheiden: akzeptieren / ablehnen / zurückstellen · Verantwortlichkeiten festlegen
→
Schritt 5
Behebung & Berichterstattung
Fehlerbericht je Fehlerzustand · Korrekturen durchführen · Endekriterien prüfen · Reviewbericht erstellen · Abnahme des Arbeitsergebnisses
Wichtig — Anomalie ≠ Fehlerzustand: Im Reviewprozess werden zunächst Anomalien erfasst (alles was vom Erwarteten abweicht). Erst in Schritt 4 wird durch Diskussion entschieden ob eine Anomalie tatsächlich ein Fehlerzustand ist. Manche Anomalien sind begründete Designentscheidungen, keine Fehler.
⑥ Rollen und Verantwortlichkeiten — CTFL Kap. 3.2 · FL-3.2.3 (K1)
Manager
Entscheidet was geprüft wird · Stellt Ressourcen bereit (Personal, Zeit) · Trägt organisatorische Gesamtverantwortung
Reviewleiter
Übernimmt Gesamtverantwortung für das Review · Entscheidet über Teilnehmer · Organisiert Wann und Wo
Autor
Erstellt das zu prüfende Arbeitsergebnis · Korrigiert nach dem Review gefundene Fehlerzustände · Hat keine Moderationsrolle
Moderator (Facilitator)
Sorgt für effektiven Ablauf der Reviewsitzung · Mediation · Zeitmanagement · Schafft geschützte Umgebung in der jeder frei sprechen kann
Gutachter (Reviewer)
Führt das eigentliche Review durch · Kann Projektmitarbeiter, Fachexperte oder anderer Stakeholder sein · Identifiziert Anomalien
Protokollant
Sammelt Anomalien von Gutachtern · Zeichnet Reviewinformationen auf · Dokumentiert Entscheidungen und neue Anomalien aus der Sitzung
⚠ Prüfungshinweis: Eine Person kann mehrere Rollen gleichzeitig einnehmen. Außer: Der Autor moderiert nicht (zu befangen). ISO/IEC 20246 beschreibt weitere Detailrollen.
⑦ Vier Reviewarten im Vergleich — CTFL Kap. 3.2 · FL-3.2.4 (K2)
Informelles Review
Informal Review
FormalitätKeine — kein definierter Prozess
DokumentationKeine formalen Ergebnisse erforderlich
LeitungKein Moderator nötig
ZielAnomalien schnell aufdecken
TypischPair Programming, kurze Kollegenrunde, „Schau mal drüber“
Formalität: ●○○○
Niedrigschwellig
Walkthrough
Walkthrough
FormalitätGering bis mittel
LeitungVom Autor geleitet — erklärt Schritt für Schritt
DokumentationProtokoll optional, empfohlen
ZieleQualitätsbewertung · Schulung · Konsens · Neue Ideen · Autoren motivieren
TypischPräsentation Architekturkonzept, User-Story-Walkthrough
Formalität: ●●○○
Autor führt
Technisches Review
Technical Review
FormalitätMittel bis hoch
LeitungVon einem Moderator geleitet (nicht Autor)
GutachterTechnisch qualifiziert — Fachexperten
ZieleKonsens erzielen · Technische Entscheidungen treffen · Alternativen bewerten
DokumentationReviewbericht erforderlich
Formalität: ●●●○
Moderator führt
Inspektion
Inspection
FormalitätMaximal — formalste Reviewart
LeitungModerator (geschulter Inspektionsleiter)
ProzessFolgt dem vollständigen generischen Reviewprozess
ZielMaximum an Anomalien finden · Prozessverbesserung durch Metriken
DokumentationVollständiger Reviewbericht + Metriken verpflichtend
Formalität: ●●●●
Vollständiger Prozess
Metriken
Prüfungsfalle FL-3.2.4 (K2): Die vier Reviewarten unterscheiden sich primär nach Formalität und wer leitet: Informell (kein Prozess) → Walkthrough (Autor leitet) → Technisches Review (Moderator, Fachexperten) → Inspektion (vollständiger Prozess + Metriken). Merkhilfe: Je mehr Struktur, desto formaler — und nur beim Walkthrough leitet der Autor selbst.
⑧ Erfolgsfaktoren für Reviews — CTFL Kap. 3.2 · FL-3.2.5 (K1)
Klare Ziele & messbare Endekriterien — Bewertung der Teilnehmer darf kein Ziel sein
Geeignete Reviewart wählen — passend zu Arbeitsergebnis, Kontext, Risiko, Teilnehmern
Kleine Einheiten reviewen — verhindert Konzentrationsverlust bei Gutachtern
Feedback an Stakeholder und Autoren liefern — fördert Lernen und Verbesserung
Ausreichend Vorbereitungszeit für alle Teilnehmer einplanen
Management-Unterstützung sicherstellen — ohne sie scheitern formale Reviews
Reviews in Unternehmenskultur integrieren — Lernen als Normalzustand, nicht Ausnahme
Schulungen für alle Teilnehmer — jeder muss seine Rolle kennen und ausfüllen können
Sitzungen moderieren — Moderation sichert Struktur, Zeitrahmen und offenes Klima
⚠ Häufige Prüfungsfalle: Die Bewertung der Teilnehmer (Performance Review von Personen) darf niemals ein Reviewziel sein. Reviews bewerten Arbeitsergebnisse, nicht Personen. Explizit im Lehrplan genannt.
⑨ Querverbindungen zu anderen Kapiteln
Verbindung zu Kap. 1 — Testgrundlagen
Grundsatz des frühen Testens (Kap. 1.3): Statischer Test ist der direkteste Ausdruck dieses Grundsatzes — Fehlerzustände werden aufgedeckt bevor lauffähige Software existiert.
Fehlhandlung → Fehlerzustand → Fehlerwirkung (Kap. 1.2): Statischer Test unterbricht diese Kette beim Fehlerzustand — er verhindert dass aus einem Fehlerzustand überhaupt eine Fehlerwirkung entstehen kann.
Fehlhandlung → Fehlerzustand → Fehlerwirkung (Kap. 1.2): Statischer Test unterbricht diese Kette beim Fehlerzustand — er verhindert dass aus einem Fehlerzustand überhaupt eine Fehlerwirkung entstehen kann.
Verbindung zu Kap. 1.4.3 · Kap. 6
Testmittel (Kap. 1.4.3): Reviewprotokolle, Anomalienlisten und Reviewberichte sind selbst Testmittel — sie werden konfigurationsverwaltet und sind Teil der Testdokumentation.
Testwerkzeuge (Kap. 6): Statische Analyse-Werkzeuge (Linter, SAST-Tools) sind Testwerkzeuge — die automatisierte Form des statischen Tests ohne menschliche Durchsicht. Verbindung wird auf der Kap.-6-Seite vertieft.
Testwerkzeuge (Kap. 6): Statische Analyse-Werkzeuge (Linter, SAST-Tools) sind Testwerkzeuge — die automatisierte Form des statischen Tests ohne menschliche Durchsicht. Verbindung wird auf der Kap.-6-Seite vertieft.