ISTQB-4.0-Kapitel3-Statischer Test

Während des Reviewbeginns geht es darum, sicherzustellen, dass jeder Beteiligte und alles, was benötigt wird, vorbereitet ist, um mit dem Review zu
starten. Dazu gehört auch, dass jeder Teilnehmer Zugang zu dem zu prüfenden Arbeitsergebnis hat, seine Rolle und Verantwortlichkeiten versteht und alles erhält, was er für die Durchführung des Reviews benötigt.

• Teilnehmer des Reviews bereiten sich individuell auf eine Begutachtiung vor

• Die Gutachter setzen sich intensiv mit dem zu prüfenden Arbeitsergebnis auseinander, indem sie

  • ein oder mehrere Reviewverfahren anwenden

  • die zur Verfügung gestellten Dokumente als Prüfgrundlage verwenden

  • sich auf bestimmte Aspekte beschränken

• Notieren die erkannten potenziellen Fehlerzustände, Empfehlungen, Fragen oder sonstigen Kommentare

• Alle Anomalien müssen analysiert und diskutiert werden
• Für jede Anomalie wird:
  • eine Entscheidung über ihren Status
  • ihre Verantwortlichkeit
  • die erforderlichen Maßnahmen

getroffen.

Dies geschieht in der Regel in einer Reviewsitzung, in der die Teilnehmer auch über die Qualität des geprüften Arbeitsergebnisses und über die erforderlichen Folgemaßnahmen entscheiden. Ggf. ist ein Folgereview erforderlich.

• Für jeden Fehlerzustand sollte ein Fehlerbericht erstellt werden, damit die Korrekturmaßnahmen nachverfolgt werden können.
• Wenn die Endekriterien erreicht sind, kann das Arbeitsergebnis abgenommen werden.
• Über die Ergebnisse des Reviews wird berichtet.

• Manager
• Autor
• Moderator (Facilitator)
• Protokollant
• Gutachter
• Reviewleiter

Der Manager entscheidet, was geprüft werden soll, und stellt Ressourcen wie Personal und Zeit für das Review zur Verfügung.

Der Autor erstellt und korrigiert das zu prüfende Arbeitsergebnis.

Der Moderator (auch Facilitator genannt)  sorgt für einen effektiven Ablauf der Reviewsitzungen, einschließlich Mediation, Zeitmanagement und einer geschützten Reviewumgebung, in der jeder frei sprechen kann.

Der Protokollant sammelt Anomalien von Gutachtern und zeichnet Reviewinformationen auf, z. B. Entscheidungen und neue Anomalien, die während der Reviewsitzung gefunden werden.

Der Gutachter führt Reviews durch. Ein Gutachter (auch Reviewer genannt) kann ein Projektmitarbeiter, ein Fachexperte oder ein anderer Stakeholder sein.

Der Reviewleiter übernimmt die Gesamtverantwortung für das Review, z. B. die Entscheidung, wer daran teilnimmt, und die Organisation, wann und wo das Review stattfindet.

• Softwareentwicklungslebenszyklus-Modell
• Reife des Entwicklungsprozesses
• Komplexität der zu prüfenden Arbeitsergebnisse
• rechtlichen oder regulatorischen Anforderungen
• der Notwendigkeit für einen Prüfnachweis

Die Reviewart ist abhängig von festgelegten Zielen des Reviews, z.B.

• Finden von Fehlerzuständen
• Verständnisgewinnung, Training von Testern oder neuen Mitgliedern
• Diskussion und Entscheidung durch Konsens

aber auch nach Faktoren wie

• dem Projektbedarf,
• den verfügbaren Ressourcen
• der Art des Arbeitsergebnisses und seinen Risiken
• dem Unternehmensbereich
• der Unternehmenskultur.

Das Hauptziel ist die Aufdeckung von Anomalien.

Dier Walkthrough dient ...

• der Bewertung der Qualität
• dem Aufbau von Vertrauen in das Arbeitsergebnis
• der Schulung von Gutachtern
• der Erzielung eines Konsenses
• der Generierung neuer Ideen
• der Motivation und Befähigung von Autoren
• zur Verbesserung und der Aufdeckung von Anomalien.

Die Ziele eines Technischen Reviews sind

• das Erreichen eines Konsenses
• die Entscheidungsfindung in Bezug auf ein technisches Problem
• die Aufdeckung von Anomalien
• die Bewertung der Qualität
• der Aufbau von Vertrauen in das Arbeitsergebnis
• die Entwicklung neuer Ideen
• die Motivation und Befähigung der Autoren zur Verbesserung.

Das Hauptziel besteht darin, die maximale Anzahl von Anomalien zu finden.

Weitere Ziele sind

• die Bewertung der Qualität
• der Aufbau von Vertrauen in das Arbeitsergebnis
• die Motivation und Befähigung der Autoren zur Verbesserung.

• Die Festlegung klarer Ziele und messbarer Endekriterien.
• Auswahl der geeigneten Reviewart.
• Durchführung von Reviews in kleinen Einheiten.
• Lieferung von Feedback aus Reviews an die Stakeholder und Autoren.
• Bereitstellung von ausreichend Zeit für die Teilnehmer zur Vorbereitung auf das Review.
• Unterstützung des Reviewprozesses durch das Management.
• Einbeziehung der Reviews in die Unternehmenskultur.
• Angebot geeigneter Schulungen für alle Teilnehmer
• Moderation der Sitzungen

• 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

Das liegt daran, dass weniger Zeit und Aufwand für die Behebung von Fehlerzuständen im späteren Verlauf des Projekts aufgewendet werden müssen.

iI der Regel führt das Vorgehen zu weniger Fehler im Code, als auch zu einem geringeren Gesamtentwicklungsaufwand.

Statische Tests

• können leichter Fehlerzustände aufdecken, die auf selten ausgeführten Pfaden durch den Code liegen oder schwer durch dynamische Tests zu erreichen sind
• können auch auf nicht ausführbare Arbeitsergebnisse angewandt werden, z.B. informelle Texte, Modelle
• messen Qualitätsmerkmale ohne Ausführung des Codes (z. B. Wartbarkeit), während dynamische Tests Qualitätsmerkmalen während der Ausführung des Codes messen (z. B. Performanz)
• finden Fehlerzustände direkt, während beim dynamische Test Fehlerwirkungen auftreten, anhand derer die zugehörigen Fehlerzustände dann ermittelt werden müssen

Sowohl statischer Test als auch dynamischer Test (mit Analyse der Fehlerwirkungen) können zur Entdeckung von Fehlerzuständen führen, allerdings gibt es einige Fehlerzustände, die nur durch statischen oder dynamischen Test gefunden werden können.

• Fehlerzustände in Anforderungen, z. B. Inkonsistenzen, Mehrdeutigkeiten, Widersprüche, Auslassungen, Ungenauigkeiten, Duplikationen
• Fehlerzustände im Entwurf, z. B. ineffiziente Datenbankstrukturen, schlechte Modularität
• Bestimmte Arten von Fehlerzuständen im Code, z. B. Variablen mit undefinierten Werten, nicht deklarierte Variablen, unerreichbarer oder duplizierter Code, übermäßige Komplexität des Codes
• Abweichungen von Standards, z. B. mangelnde Einhaltung von Namenskonventionen in Programmierstandards
• Falsche Spezifikation von Schnittstellen, z. B. nicht übereinstimmende Anzahl, Art oder Reihenfolge von Parametern
• Spezifische Arten von Schwachstellen in der Sicherheit, z. B. Pufferüberläufe
• Lücken oder Ungenauigkeiten in der Überdeckung der Testbasis, z. B. fehlende Tests für ein Akzeptanzkriterium