ISTQB-4.0-Kapitel3-Statischer Test

• Verbesserung der Qualität

• Finden von Anomalien bzw. Fehlerzuständen 

• -Bewertung von Merkmalen wie Lesbarkeit, Vollständigkeit, Korrektheit, Testbarkeit und Konsistenz

Statische Tests können sowohl zur Verifizierung, als auch zur VAlidierung eingesetzt werden.

Tester, Fachbereichsvertreter (Product Owner, Businessanalysten etc.) und Entwickler arbeiten beim Example-Mapping, beim gemeinsamen Schreiben von User-Storys und bei der Verfeinerung (Refinement) des Backlogs zusammen, um sicherzustellen, dass die User-Storys und die zugehörigen Arbeitsergebnisse definierten Kriterien entsprechen, z. B. der Definition-of-Ready.

Reviewverfahren können angewendet werden, um sicherzustellen, dass die User-Storys vollständig und verständlich sind und testbare Akzeptanzkriterien enthalten. Indem sie die richtigen Fragen stellen, können Tester die vorgeschlagenen User-Storys analysieren, hinterfragen und verbessern.

Es sind keine Testfälle erforderlich und in der Regel können Werkzeuge verwendet werden.

In CI-Frameworks (Continuous Integration)

Die statische Analyse dient:

• hauptsächlich zur Erkennung spezifischer Fehlerzustände im Code
• Bewertung der Wartbarkeit und Sicherheit
• zur Prüfung der Rechtschreibung und der Lesbarkeit

Fast jedes Arbeitsergebnis kann mit statischen Tests untersucht werden. Beispiele hierfür sind:

• Spezifikation der Anforderungen
• Quellcode
• Testkonzepte
• Testfälle
• Produkt-Backlog-Einträge
• Test-Chartas
• Projektdokumentation
• Verträge
• Modelle

Jedes Arbeitsergebnis, das gelesen und verstanden werden kann, kann Gegenstand eines Reviews sein.

(Zusatzinformationen vom Foliensatz:

• Spezifikationen, z. B. Fachanforderungen, technische Anforderungen und IT-Sicherheitsanforderungen, Abnahmekriterien
• Produkt-Backlog-Elemente wie Epics, User Storys und Definition-of-Ready sowie Definition-of-Done, Test-Chartas
• Architektur und Entwurfsspezifikationen, Benutzeranleitungen, Handbücher
• Verträge, Projektpläne, Zeitpläne und Budgetpläne
• Testkonzepte, Testspezifikationen, Testskripte, Testberichte )

Für die statische Analyse benötigen Arbeitsergebnisse jedoch eine Struktur, anhand derer sie überprüft werden können, Beispiele sind:

• Programmquellcode

• Modelle, wie Aktivitätsdiagramme oder Zustandsdiagramme

• Text mit einer formalen Syntax (Webseiten, Konfigurationsscripte)

Nicht statisch testbar sind solche Arbeitsergebnisse, die

• für den Menschen schwer zu interpretieren sind
• die nicht mit Hilfe von Werkzeugen analysiert werden können oder dürfen, z. B.:
  • ausführbarer Code von Drittanbietern, welcher aus rechtlichen Gründen nicht untersucht werden darf
  • Ausführbarer Code, der aufgrund von Obfuskation („Unkenntlichkeitmachung“)  nicht ohne größeren Aufwand wieder in eine analysierbare Struktur gebracht werden kann
  • Dynamisch generierter Code (zur Laufzeit generiert oder modifiziert wie bei einigen Skriptsprachen oder durch bestimmte Frameworks) kann nicht vollständig statisch analysiert werden, da sein endgültiger Zustand oder seine Ausführung vom Kontext zur Laufzeit abhängt

Den Grundsatz des frühen Testens.

• nicht erreichbarer Code
• nicht wie gewünscht implementierte Entwurfsmuster
• Fehlerzustände in nicht ausführbaren Arbeitsergebnissen

Statische Tests

• können die Qualität von Arbeitsergebnissen bewerten und Vertrauen in sie aufzubauen
• stellen durch die Überprüfung der dokumentierten Anforderungen durch die Stakeholder auch sicher, dass diese ihre tatsächlichen Bedürfnisse beschreiben
• schaffen ein gemeinsames Verständnis zwischen den beteiligten Stakeholdern
• verbessern auch die Kommunikation zwischen den beteiligten Stakeholdern