Kapitel 3

Überprüfung ohne Ausführung, finden von Fehlerzuständen (Ursachen); GrundIdee: Prävention, Fehlerzustände so früh wie möglich beheben

Ausführung des Quellcode prüfen, Finden von Fehlerwirkungen (Symptomen)

• Spezifikationen

• Epics, User-Stories und Abnahmekriterien

• Architektur und Entwurfsspezifikationen

• Benutzeranleitungen, Handbücher

• Verträge, Projektpläne, Zeitpläne und Budgetpläne

• Modelle wie Aktivitätsdiagramme oder Zustandsdiagramme

• Programmquellcode

• Testkonzepte, Testspezifikationen, Testskripte, Testberichte

• Webseiten

ISTQB: Eine Art des statischen Tests, während der ein Arbeitsprodukt oder ein Prozess von einer oder mehreren Personen beurteilt werden, um Befunde zu erheben und um Verbesserungspotentiale zu identifizieren.

• Planung

• Reviewbeginn

• Individuelles Review

• Befundkommunikation und -analyse

• Fehlerbehebung und Bericht

• Definition des Reviewumfangs ("review scope")

• Identifiziere die Reviewmerkmale und -Charakteristiken

• Auswahl und Festlegung geeigneter Reviewer

• Verteilung der Reviewdokumente (so früh wie möglich)

• Kick-off / Überblicksmeeting mit Reviewleiter und Reviewteilnehmer

• Teilnehmer des Reviewteams bereiten sich individuell vor

• Reviewer: intensiv mit Dokumenten auseinandersetzen, Beschärunkg auf bestimmte Aspekte ratsam, Einteilung des Prüfobjekts ratsam

• Notieren von erkannten potenziellen Fehlerzuständen, Empfehlungen, Fragen oder sonstigen Kommentaren

• Ad-hoc-Review

• checklistenbasiertes Review

• szenariobasiertes Review

• rollenbasiertes Review

• perspektivisches Lesen

• wenige / gar keine Vorgaben für Durchführung

• Reviewer: Prüfobjekt von vorne nach hinten lesen, identifizierne und dokumentieren Befunden asap

• Erwartung: Reviewer erfassen möglichst viele Befunde & Fehlerzustände

• Vorteile: Erfordert wenig Vorbereitung

• Nachteile: Erfolg hängt stark von den Fähigkeiten der Reviewer ab; es kann zu vielen doppelt berichteten Befunden kommen

• systematische Vorgehensweise

• systematische Vorgehensweise

• Reviewer nutzt Checklisten

• Fragen der Checkliste: Fokus auf potenzielle FEhlerzustände; aus Erfahrungen abgeleitet; auf Art des Prüfobjekts zugeschnitten; identifizierte und bekannte Risiken abdecken; regelmäßig überarbeiten (neue Erfahrungen einfließen lassen)

• Vorteile: Systematische Abdeckung typischer Fehlerarten

• Nachteile: Fehlerzustände außerhalb der Cehckliste können übersehen werden; zeitintensiver als ein informelles Ad-hoc Review

• Reviewer bekommen strukturierte Richtlinien für Review

• Bewertung des Prüfobjekts bzgl. der Eignung für vorgegebene Szenarien: Verwendung des Prüfobjekts durch Endkunden, weitere Entwicklung auf Basis des Prüfobjekts, Ableiten von Testfällen aus dem Prüfobjekt

• Probeläufe mit dem Prüfobjekt auf Basis der erwarteten Nutzung

• Vorteile: Systematische Abdeckung der vorgegebenen Szenarien

• Nachteile: Fehlerzustände außerhalb der Szenarien können übersehen werden

• Reviewer bewerten das Prüfobjekt aus der Perspektive individueller Stakeholder-Rollen, z. B. Endanwender oder spezifische Rollen innerhalb einer Organisation

• Vorteile: Stakeholer-spezifische Fehlerzustände können gefunden werden

• Nachteile: Fehlerzustände außerhalb der Rollen können übersehen werden; mache Reviewer haben Schwierigkeiten, andere Perspektiven einzunehmen

• Spezialfall von rollenbasierten Review

• Prüfobjekt so *nutzen*, wie es der Stakeholder tun würde; Test leitet Testfälle ab; Endnutzer bedienen die entworfene Benutzungsschnittstelle

• Wichtig: angemessenes Einbeziehen der unterschiedlichen Standpunkte, basierend auf Risiken

• Vorteile: mehr Tiefe im individuellen Review; weniger Doppelungen von Befunden

• Nachteile: Annahme anderer Perspektiven schwierig

• Kommunikation identifizierter potenzieller Fehlerzustände (z. B. in einer Reviewsitzung)

• Analyse pot. Fehlerzuständen, Zuweisung von Zuständigkeiten und Stauts

• Bewertung und Dokumentation von Qualitätsmerkmalen

• Bewertung der Reviewbefunde gegenüber den Endekriterien, um Reviewentscheidung bzgl. Reviewobjekt zu treffen (annehmen, ablehnen, Änderungen notwendig, ...)

• Behben von im geprüften Arbeitsergebnis gefundenen Fehlerzuständen (üblicherweise durch den Autor)

• Kommunikation von Fehlerzuständen an zuständige personen, wenn sie in einem Dokument gefunden wurden, das zu dem Prüfobjekt in Beziehung steht

• Aufzeichnung des aktualisierten Status der Fehlerzustände (in formalen Reviews)

• Sammeln von Metriken (formalere Reviewarten)

• Prüfen, ob Endekriterien erfüllt sind (formalere Reviewarten)

• Abnahme von Arbeitsergebnis, wenn Endekriterien erreicht

• ggf. Folgereview ansetzen, das aber oft kürzer ausfällt

• Management: entscheidet über Durchführung von Reviews, stellt Zeit zur Verfügung, Überprüfung der Erfüllung von Reviewzielen

• Reviewleiter: verantwortet Review, Entscheidung über Teilnehmer, Ort, Zeitpunkt des Reviews

• Moderator: Leitet Reviewsitzungen, vermittelt zwischen Standpunkten, Erfolg hängt häufig von ihm ab

• Autor: hauptverantwortlich für das zu prüfende Dokument; überarbeitet das Prüfobjekt nach dem Review

• Reviewer: Identifikation von Befunden im Prüfobjekt, besitzen fachlichen/technischen Hintergrund, auch Prüfer/Gutachter/Inspektoren genannt

• Protokollant: dokumentiert alle Ergebnisse, Probleme und offene Punkte, die im Verlauf der Sitzung identifiziert werden.

• Informelles Review: kein formaler/dokumentierter Ablauf

• Walkthrough: Autor leitet Reviewteilnehmer durch Arbeitsergebnis; Review können Fragen stellen und potenzielle Befunde kommentieren

• Technisches Review: formal, technisch qualifizierte Personen überprüfen Eignung des Arbeitsergebnisses für seine Verwendung, Überprüfung von Abweichungen von Spezifikation oder Standards

• Inspektion: formal; Identifizierung von Befunden in einem Arbeitsprodukt; Lieferung von Messungen zur Verbesserung des Reviewprozesses und des Softwareentwicklungsprozesses

• Fehlorebeseitung kostet Ressourcen, aber frühes Erkennen führt zu Produktivitätssteigerung in Entwiclkung

• Resultate: oft kürzere Entwicklungszeiten; weniger Fehler im dynamischen Test, weniger Aufwand; reduzierte Fehlerhäufigkeit im Einsatz des Systems

• Kostenreduzierung während der Produkt-Lebenszeit zu erwarten

• Überprüfungen im Team führen zu Wissensaustausch: Arbeitsmethoden, Wissen der einzelnen Personen verbessert; Qualität der Prozesse und der nachfolgenden produkte dieser Personen verbessert

• Beteiligung mehrerer Personen erfordert verständliche Darstellung,; alleine die klare Darlegung bringt den Autor zu neuen Einsichten

• Fehlende oder unklare Ziele

• Fehlende oder unzureichende Dokumentation

• Fehlende Unterstützung durch Management

• ur-Anomalie: Ein undefinierter Wert (u) einer Variablen wird auf einem Programmpfad gelesen (r)

• du-Anomalie: Die Variable erhält einen Wert (d) der allerdings ungültig (u) wird, ohne dass er zwischenzeitlich verwendet wurde

• dd-Anomalie: Die Variable erhält auf einem Programmpfad ein zweites Mal einen Wert (d), ohne dass der erste Wert (d) verwendet wurde

Software-Metriken sind Messungen bestimmter Merkmale von

– Software-Produkten

– Software-Projekten und

– Software-Prozessen

• zu deren

– Bewertung

– Planung und

– Überwachung

• Zyklmatische Zahl = Anzahl der linear unabhängigen Pfade im untersuchten Programmtext und gibt Hinwese zum Test- und Wartungsaufwand

• v(G) = e - v + 2

• eine Metrik für Komplexität von Code

Beides werden als statischen Tests bezeichnet.