ISTQB Certified Tester Foundation Level 3

dieses Moduls
Siehe Modul 1, Anhang A, Beschreibung der Lernzielstufen

ausgeführt

G

Styleguides, z.B.
zur Programmierung
zu Nutzeroberflächen

der Anforderungen
Nicht realisierbares Design
Falsche Schnittstellenspezifikationen
Code mit unzureichender Wartbarkeit
Abweichungen von Standards und einzuhaltenden Richtlinien
Prozessfehler, die weitere Fehlerzustände verursachen

selten auffällt

Wartungsprobleme, z.B.
Unerwünschter Testcode
„Magische“ Zahlen
Schlechte Kommentierung

Logisch falsche Konstrukte

GetAccount (AccNumber)
If account in credit (AccNumber)
add to account (AccNumber ,sum)
else
issue letter (AccNumber)
delete account (AccNumber+1)
endif

If current_account > 100
add to account (AccNumber ,sum)
else
issue letter (AccNumber)
If Test then
delete account (AccNumber+1)
endif

Sum = GetCurrentAccount (AccNumber)
if (Sum = 0)
issue letter (AccNumber)
Print (Sum)

c, c++ !

100 ??

Test ??

!!!

1998

Reviews & Inspections (R&I) für 4.000 Personen an 40 Standorten

Zentrales R&I Competence Team aus 7 Personen leitet Einführung

„Buy-in“ durch Roadshows, Trainingspakete und lokale
Steuerung der Prozesse.

Lokale R&I „Champions“ an den einzelnen Standorten

Einsparungen: 1.800.000 Pfund

Return on investment (ROI) 4:1 (Schwankung 3:1 < > 6:1)

Geschätzte Zeitersparnis: 30.000 Personenstunden
10% der Arbeitsstunden

Ein 6-monatiges Projekt bräuchte ohne
Inspektionen fast 3 Wochen länger !

Bilanz R&I bei Ericsson Telecom

beseitigt
Wartungskosten um Faktor 28 reduziert

Quelle : Software Inspections,
Tom Gilb & Dorothy Graham

Etwa 5 bis 15% der Entwicklungskosten abhängig von
Anzahl der Dokumente im Review
Tiefe und Art des Reviews
Erfahrung mit der Durchführung

Kosteneffizienz

Kosten von Reviews

komplementär, da sie auf verschiedene Fehlerarten abzielen
Statische Techniken finden primär Fehlerzustände
Dynamische Techniken finden primär Fehlerwirkungen
Statische Techniken brauchen keinen lauffähigen Code ? Früherkennung / Vermeidung von Fehlerzuständen
Definitionen:
Dynamischer Test: Prüfung des Testobjekts durch Ausführung auf einem Rechner.
Statische Analyse: Die Durchführung der Analyse eines Artefakts (z.B. Anforderung oder Quelltext) ohne Ausführung der Software.

G

G

ist
Reviewprozess: Planung, Vorbereitung, Durchführung und Nachbereitung eines Reviews [nach IEEE 610]
Peer Review: Ein Review eines Arbeitsergebnisses durch Kollegen des Erstellers mit dem Ziel, Fehlerzustände aufzudecken und Verbesserungsvorschläge zu identifizieren. Beispiele sind Inspektion, technisches Review und Walkthrough.
Reviews können sehr informell oder sehr formal (strukturiert und geregelt) sein. Der Grad des Formalismus ist abhängig von
Reife des Entwicklungsprozesses
Regulatorischen Anforderungen
Bedarf an einem Prüfnachweis

Reviews im Allgemeinen

G

G

G

identifizieren und ihnen eine Reviewrolle zuordnen
Welche Spezialisten werden als Gutachter benötigt?
Wer soll die Rolle des Moderators übernehmen?
Eingangsdokument(e) festlegen (z.B. Anforderungsspezifikation)
Nach dem Kick-Off stellt der Moderator sicher, dass die vereinbarte Planung eingehalten wird und dass die Reviewsitzung stattfinden kann.
Kick-Off
Planung und Reviewprozess abstimmen
„Commitment“ der Teilnehmer einholen (vor allem der Gutachter)
Eingangsdokument(e) verteilen
Individuelle Vorbereitung
Überprüfen des Dokuments und Notieren von Fehlerzuständen

Bemerkung: Besonderheiten für Inspektionen (formale Reviewart) werden auf Seite 23 gelistet

Moderator geleitet)
Festhalner der Fehlerzustände
Empfehlungen und Entscheidungen treffen
Erstellen eines Protokolls (optional)
Überarbeitung
Behebung der Fehlerzustände und Fragen beantworten (meist durch den Autor)
Nachbereitung
Prüfung der Überarbeitung (meist durch den Moderator)
Freigabe des Dokuments
Sammeln von Metriken

Bemerkung: Besonderheiten für Inspektionen (formale Reviewart) werden auf Seite 23 gelistet

Coaching - Leitung der Meetings
- Nachbereitung - Metriken

Autor - Hauptverantwortlich für das zu prüfende Dokument
- Meist „passive“ Teilnahme an Meetings
- Notwendige Dokumentenanpassungen

Gutachter - Person mit notwendigem technischem oder fachlichem
(Reviewer, Inspektor) Hintergrund, um Befunde identifizieren zu können
- Einzelprüfung des Dokuments
- Vorbereitung der Meetings
- „Aktive“ Teilnahme an Meetings

Manager - Entscheidung über Reviewgegenstand
- Ansetzen des Reviews
- Zeit im Projektplan zur Verfügung stellen
- Überprüfung der Zielerreichung

Protokollant - Aufzeichnung der Meetingresultate
(Protokollführer) - Versorgt den Leiter mit Informationen zur effektiven
Steuerung der Meetings

: Software Inspections,
Tom Gilb & Dorothy Graham

Definierte Eingangs- und Endebedingungen. Formalisierte Nachverfolgung. Leiter ist speziell geschult. Primärziel ? Fehlerzustände finden

Informelles
Review

Kein formaler Prozess. Häufig praktiziert als billige aber kaum definierte Reviewmethode. Dokumentation optional. Nutzen variiert abhängig vom Gutachter (z.B. technischer Leiter oder Teamkollege).
Primärziel ? Kostengünstiges Fehler finden

Technisches
Review

Fehlersuche durch technisch orientierte Personen. Häufig als Peer Review ohne Management-Beteiligung. Große Bandbreite bezüglich der Formalität. Ergebnisse werden dokumentiert. Primärziele ? Diskussion, Bewertung, Fehler finden, Problemlösung, Entscheidung

Walkthrough

Der Autor verliest ein Dokument und erläutert den gewöhnlich gleichgestellten Teilnehmern spezielle Inhalte, Annahmen oder Entscheidungen. Durchspielen von Szenarien. Oft sehr langwieriger Prozess. Große Bandbreite bezüglich der Formalität.
Primärziele ? Know-How-Transfer, Konsensbildung, Fehler finden

(*Siehe auch IEEE 1028
und die formalen Definitionen, Seite 44)
Alle Reviewarten können als Peer Reviews gestaltet werden

und Kriterien begonnen bzw. beendet)
Rollenspezifische Prozeduren unterstützen den Prozess
Checklisten unterstützen die Prüfung und definieren schwere und geringfügige Fehler
Hohe Effektivität durch eine relativ geringe, durch Metriken regulierte Prüfgeschwindigkeit
Prozessverbesserung kann zu einem integralen Bestandteil des Inspektionsprozesses definiert werden
Rollen und Verantwortlichkeiten erfordern spezielles Training
Meetings laufen formaler ab mit weniger Diskussion und schnellerer Fehlererfassung. Autor ist nur „passiv“ dabei

viele
übersehen

Rolle, bitte prüfe
in diesem Dokument“ das Dokument anhand dieser
Prozedur nach dieser Checkliste“

In der Regel das Teile des Dokuments, die speziell für
gesamte Dokument den Prüfer ausgewählt werden

Ein spezielles Dokument Das Dokument selbst und alle
bei der Erstellung verwendeten
Dokumente

„Dies hier sieht irgendwie „Verstoß gegen Regel N aus
nicht richtig aus“ Checkliste ABC“

Wenig kontrolliert mit viel Strikte Moderation, auf maximal 2
Diskussionen und häufig mit Stunden begrenzt, kaum Diskussion,
Zeitüberschreitung. Autor ist sehr fokussiert. Meeting findet nicht
an Debatten über Lösungen statt, bevor die Eingangskriterien
und Rechtfertigungen beteiligt. erfüllt sind. Autor bleibt passiv.

Aspekt

Der Prüfer liest das Dokument Der Prüfer wertet das Dokument
relativ schnell durch und macht anhand von Richtlinien und
sich Notizen Checklisten methodisch aus

Ansatz bei der Prüfung

Umfang der Prüfung

Prüfgegenstand

Umgang mit Fehlern

Durchführung
des Meetings

Prüfmethode

95%

variabel

6 - 8

8 - 30

* Effektivität : Aufdeckungsquote von Fehlerzuständen

Quelle : Software Inspections,
Tom Gilb & Dorothy Graham

10

Effektiv

Einführung
für großen
Teilnehmerkreis

Geringer
Aufwand

Geringer
Aufwand,
findet Fehler

Anfangs-
investitionen

Relativ
aufwendig

Uneffektiv,
trügerische
Sicherheit

Subjektiv

Ja

Opt.

Ja

Ja

Ja

Opt.

Opt.

Opt.

Im
Protokoll

Opt.

Im
Protokoll

Opt.

Opt. = optional

Check-
listen

Ja

Opt.

Nein

Nein

Quelle : Software Inspections,
Tom Gilb & Dorothy Graham

usw.) anhand von Anforderungen und Spezifikationen
Bewertung und Prüfung von Dokumenten anhand von Standards für alle Produkte des Unternehmens
Früherkennung von Fehlerzuständen
Aufbau von Vertrauen in das Projekt, noch bevor der Code entsteht
Verbesserung des Prozesses, der zur Entstehung des geprüften Dokuments führte

Mit Ausnahme der Inspektionen...
Konsensbildung über ein breites Spektrum an Themen im Projekt

Methoden
Einplanung benötigter Zeit und Ressourcen für Reviews
Lernfähigkeit: Neben reiner Fehlerkorrektur werden auch die Fehlerursachen untersucht und bekämpft
Identifizierte Prozessverbesserungen werden angegangen
Überwindung von Widerständen gegen Formalien
Der Reviewprozess wird durch Standards (z.B. Rollen und Checklisten) sinnvoll unterstützt
Klar definierte Ziele

Know-How ein
Werden früh mit dem Produkt vertraut
Einsatz von Techniken ist angepasst an Teilnehmer und Reviewgegenstand
Offener und positiver Umgang mit
Gefundenen Fehlern
Verbesserungsvorschlägen
Fragen
Berücksichtigung psychologischer Aspekte
Gegenseitige Wertschätzung
Vermeidung von Vorwürfen und Rechtfertigungen

Früherkennung realer oder potenzieller Fehlerzustände, die vom Compiler nicht und mit dynamischen Testmethoden nur unter hohem Aufwand gefunden werden.
Aufschlüsse über Design und Code, die einen wertvollen Beitrag zur Risikobewertung liefern.
Methoden sind z.B. Datenfluss- und Kontrollflussanalyse
Toolunterstützung notwendig, bspw. auch als automatische Kontrolle beim Einchecken in einem Konfigurationsmgmt.werkzeug

werden kann, z.B. implizite Typumwandlung

Solche Fehlerzustände werden häufig mit Tools ausgewertet

Zum Beispiel, Compiler können undeklarierte oder uninitialisierte Variablen entdecken

werden referenziert

Potentieller Datenfluss-Fehler:
subtotal1 wird ohne
Aufruf neu definiert

können:
Nicht ausführbare Anweisungen („Toter Code“)
Endlosschleifen
Mehrere Eingänge oder Ausgänge für Schleifen
Nicht definierte, nicht verwendete Sprungziele
Schlechter Stil, z.B. komplexe Zeigerarithmetik
Übertriebene Komplexität („Zyklomatische Komplexität“)
Abweichungen von Styleguides zur Codestruktur

abs(calculate_subtotal(2))
sum = subtotal1 + subtotal2
count = int (subtotal1 / subtotal2)
if (sum < count) then
count = 0
endif
do while count >= 0
sum = sum + bonus
end do
count = count -1
write (sum)

Sonstiger Fehler:
Nicht abgefangene
Division durch Null

Kontrollflussfehler:
Anweisung wird
nie ausgeführt

Kontrollflussfehler:
Endlosschleife für
count >= 0

Sonstiger Fehler:
Möglicher
Integerüberlauf

Datenflussanomalie:
count wird neu-
definiert : Verwendung

Zahl = Anzahl Verzweigungen + 1
Anzahl unabhängiger Pfade
Höhere CC bedeutet einen komplexeren Kontrollfluss
Hohe Komplexität bedeutet häufig:
Code oder Design sind schwach strukturiert
Code oder Design sind fehlerträchtig
CC kann verwendet werden als Metrik für die relative Wahrscheinlichkeit (d.h. das Risiko), dass ein vorliegendes Design oder Codestück Fehlerzustände enthält.

Statische Analysen

von Informationen (nützlich in der Wartung):
Variablennutzung
Referenzen zwischen Variablen, deren Bezeichnern und Verwendung in Funktionen (Cross Reference Listen)
Datentypkonflikte
Speicherbelegung
Generierung von Metriken

hohem Aufwand durch dynamische Tests aufgedeckt werden
Wird durch Tools unterstützt
Häufig früher durchführbar als dynamische Tests
Auch auf Design anwendbar
Objektive Aussagen über die Qualität von Design und Code

Gefundene Fehler müssen auf Wichtigkeit interpretiert werden
Output der Tools muss gefiltert werden, um die Informationen überschaubar zu halten
Objektive Bewertung der Metriken ist entscheidend, um das „Na und?“ Problem zu vermeiden
Fehler beim Betrieb des Systems (Timing, Speicherbelegung) werden nicht gefunden

Früherkennung von Abhängigkeiten und Inkonsistenzen in
Softwaremodellen (z.B. Links)
Schnittstellen (von Modulen, Komponenten, Systemen)
Fehlervermeidung (wenn neben individuellen Fehlern auch systematische Ursachen identifiziert und bekämpft werden)
Aufdeckung von Sicherheitsschwächen

der Dokumentation zu finden
Es gibt verschiedene Reviewtypen: Walkthrough, Technisches Review, Informelles Review, Inspektion ...
Ein Review kann als Prozess beschrieben werden
Inspektionen sind formaler, aber auch effektiver bei der Fehlersuche
Inspektionen verwenden Prozeduren und Checklisten
Inspektionen sind kosteneffizient!
Statische Analysen liefern Informationen über Qualität von Design bzw. Code und finden Fehlerzustände, ohne den Code auszuführen