ВУЗ: Не указан
Категория: Не указан
Дисциплина: Не указана
Добавлен: 18.04.2021
Просмотров: 1796
Скачиваний: 4
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 31/84
1.8.2011
© International Software Testing Qualifications Board
3 Statischer Test (K2)
60 Minuten
Lernziele für den Abschnitt statischer Test
Die Lernziele legen fest, was Sie nach Beenden des jeweiligen Moduls gelernt haben sollten.
3.1 Statische Prüftechniken und der Testprozess (K2)
LO-3.1.1 Arbeitsergebnisse der Softwareentwicklung, die mit den verschiedenen statischen Prüf-
techniken geprüft werden, erkennen. (K1)
LO-3.1.2 Bedeutung und Nutzen statischer Methoden für die Bewertung von Arbeitsergebnissen der
Softwareentwicklung beschreiben können. (K2)
LO-3.1.3 Unterschiede zwischen statischen und dynamischen Techniken erklären können, wobei
Ziele und zu identifizierende Fehlerarten sowie die Rolle dieser Techniken im Softwarele-
benszyklus zu beachten sind. (K2)
3.2 Reviewprozess (K2)
LO-3.2.1 Aktivitäten, Rollen und Verantwortlichkeiten eines typischen formalen Reviews wiederge-
ben können. (K1)
LO-3.2.2 Unterschiede zwischen den verschiedenen Reviewarten (informelles Review, technisches
Review, Walkthrough und Inspektion) erklären können. (K2)
LO-3.2.3 Faktoren für die erfolgreiche Durchführung eines Reviews erklären können. (K2)
3.3 Werkzeuggestützte statische Analyse (K2)
LO-3.3.1 Typische Fehlerzustände
und Fehler wiedergeben können, die durch eine statische Analy-
se identifiziert werden können, und sie mit Reviews und dynamischen Tests vergleichen.
(K1)
LO-3.3.2 Den typischen Nutzen der statischen Analyse anhand von Beispielen beschreiben können.
(K2)
LO-3.3.3 Typische Fehlerzustände im Quellcode und Entwurf, die durch eine werkzeuggestützte
statische Analyse identifiziert werden können, auflisten. (K1)
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 32/84
1.8.2011
© International Software Testing Qualifications Board
3.1 Statische Prüftechniken und der Testpro-
zess (K2)
15 Minuten
Begriffe
Dynamisches Testen, statischer Test
Hintergrund
Anders als das dynamische Testen, welches die Ausführung der Software voraussetzt, beruhen stati-
sche Prüftechniken auf der „manuellen“ Überprüfung (Reviews) oder automatisierten Analysen (stati-
sche Analyse) des Codes oder anderer Projektdokumentation, ohne den Programmcode auszuführen.
Reviews sind eine Möglichkeit, Arbeitsergebnisse der Softwareentwicklung (einschließlich Code) zu
prüfen und können problemlos bereits lange vor der dynamischen Testdurchführung durchgeführt
werden. Fehlerzustände, die durch Reviews in den frühen Phasen des Softwarelebenszyklus entdeckt
werden (z.B. Fehlerzustände in den Anforderungen), sind häufig bedeutend kostengünstiger zu behe-
ben, als solche, die erst während der Testdurchführung bei Ausführung des Programmcodes gefun-
den werden.
Ein Review kann komplett als manuelle Aktivität durchgeführt, aber ebenso durch Werkzeuge unter-
stützt werden. Die wichtigste manuelle Tätigkeit ist die Prüfung und Kommentierung des Arbeitser-
gebnisses. Jedes Arbeitsergebnis der Softwareentwicklung kann einem Review unterzogen werden,
einschließlich Anforderungsspezifikationen, Designspezifikationen, Quellcode, Testkonzepte, Testspe-
zifikationen, Testfälle, Testskripte, Anwenderhandbücher oder Web-Seiten.
Vorteile von Reviews sind frühe Aufdeckung und Korrektur von Fehlerzuständen, Verbesserung der
Softwareentwicklungsproduktivität, reduzierte Entwicklungsdauer, reduzierte Testkosten und -dauer,
Reduzierung der Kosten während der Lebensdauer, weniger Fehlerzustände und verbesserte Kom-
munikation. Reviews können beispielsweise Auslassungen in Anforderungen aufdecken (z.B. fehlende
Funktionen), die durch einen dynamischen Test vermutlich nicht gefunden würden.
Reviews, statische Analyse und dynamischer Test haben das gleiche Ziel, nämlich Fehlerzustände zu
identifizieren. Sie ergänzen sich: Die verschiedenen Methoden können verschiedene Arten von
Fehlern wirksam und effizient aufdecken. Verglichen mit dem dynamischen Test finden statische Prüf-
techniken eher Ursachen der Fehlerwirkungen (Fehlerzustände) als Fehlerwirkungen selbst.
Zu den typische Fehlerzuständen, die effektiver und effizienter durch Reviews als durch dynamische
Tests zu finden sind, gehören: Abweichungen von Standards, Fehlerzustände in Anforderungen, Feh-
lerzustände im Design, unzureichende Wartbarkeit und fehlerhafte Schnittstellenspezifikationen.
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 33/84
1.8.2011
© International Software Testing Qualifications Board
3.2 Reviewprozess (K2)
25 Minuten
Begriffe
Eingangskriterien, formales Review, Gutachter, informelles Review, Inspektion, Metrik, Moderator,
Peer Review, Protokollant, technisches Review, Walkthrough
Hintergrund
Die verschiedenen Arten von Reviews variieren zwischen informell, charakterisiert durch fehlende
schriftlichen Vorgaben für die Gutachter, und systematisch, charakterisiert durch die Einbindung eines
Reviewteams, dokumentierte Reviewergebnisse und dokumentierte Abläufe zur Durchführung von
Reviews. Der Formalismus eines Reviewprozesses ist abhängig von Faktoren wie Reife des Entwick-
lungsprozesses, gesetzlichen oder regulatorischen Anforderungen oder der Notwendigkeit eines Prüf-
nachweises.
Die Art und Weise, wie ein Review durchgeführt wird, ist abhängig von den festgelegten Zielen des
Reviews (z.B. Finden von Fehlerzuständen, Erwerben von Verständnis, Ausbildung von Testern und
neuen Teammitgliedern
oder einer Diskussion und Entscheidungsfindung im Konsens).
3.2.1 Aktivitäten eines formalen Reviews (K1)
Ein typisches formales Review besteht aus folgenden Hauptaktivitäten:
1. Planen
•
Festlegen von Review-/Prüfkriterien
•
Auswahl der beteiligten Personen
•
Besetzen der Rollen
•
Festlegen der Eingangs- und Ausgangskriterien bei mehr formalen Reviewarten (z.B. In-
spektion)
•
Auswahl der zu prüfenden Dokumententeile
•
Prüfen der Eingangskriterien (bei formaleren Reviewarten)
2. Kick-off
•
Verteilen der Dokumente
•
Erläutern der Ziele, des Prozesses und der Dokumente den Teilnehmern gegenüber
3. Individuelle Vorbereitung
•
Vorbereiten der Reviewsitzung durch Prüfung des/der Dokuments/e
•
Notieren von potenziellen Fehlerzuständen, Fragen und Kommentaren
4. Prüfen/Bewerten/Festhalten der Ergebnisse (Reviewsitzung)
•
Diskussion oder Protokollierung, mit dokumentierten Ergebnissen oder Protokollen (bei
formaleren Reviewarten)
•
Festhalten von Fehlerzuständen, Empfehlungen zum Umgang mit ihnen oder Entschei-
dungen über die Fehlerzustände
•
Prüfen/Bewerten und Protokollieren von Problemen während eines physischen Treffens
oder Nachverfolgen von elektronischer Gruppenkommunikation
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 34/84
1.8.2011
© International Software Testing Qualifications Board
5. Überarbeiten
•
Beheben der gefundenen Fehlerzustände typischerweise durch den Autor
•
Protokollieren des aktualisierten Fehlerstatus (in formalen Reviews)
6. Nachbereiten
•
Prüfen, ob Fehlerzustände zugewiesen wurden
•
Sammeln von Metriken
•
Prüfen von Ausgangskriterien (bei formaleren Reviewarten)
3.2.2 Rollen und Verantwortlichkeiten (K1)
Bei einem typischen formalen Review findet man folgende Rollen:
•
Manager: Die Person, die über die Durchführung von Reviews entscheidet, Zeit im Projekt-
plan zur Verfügung stellt und überprüft, ob die Reviewziele erfüllt sind.
•
Moderator: Die Person, die das Review eines Dokuments bzw. von einigen zusammengehö-
renden Dokumenten leitet, einschließlich der Reviewplanung, der Leitung der Sitzung und der
Nachbereitung nach der Sitzung. Falls nötig, kann der Moderator zwischen den verschiede-
nen Standpunkten vermitteln. Er ist häufig die Person, von der der Erfolg des Reviews ab-
hängt.
•
Autor: Der Verfasser oder die Person, die für das/die zu prüfende/n Dokument/e hauptver-
antwortlich ist.
•
Gutachter: Personen mit einem spezifischen technischen oder fachlichen Hintergrund (auc h
Prüfer oder Inspektoren genannt), die nach der nötigen Vorbereitung im Prüfobjekt Befunde
identifizieren und beschreiben (z.B. Fehlerzustände). Gutachter sollten so gewählt werden,
dass verschiedene Sichten und Rollen im Reviewprozess vertreten sind. Sie sollten an alle n
Reviewsitzungen teilnehmen können.
•
Protokollant: Die Person, die alle Ergebnisse, Probleme und offenen Punkte dokumentiert,
die im Verlauf der Sitzung identifiziert werden.
Softwareprodukte oder darauf bezogene Arbeitsergebnisse aus verschiedenen Perspektiven zu be-
trachten und Checklisten zu nutzen, kann Reviews wirksamer und effizienter machen. So kann eine
Checkliste helfen, bisher unentdeckte Probleme aufzudecken, wenn sie typische Anforderungsprob-
leme enthält und unterschiedliche Perspektiven einnimmt, beispielsweise vom Benutzer, Wartungs-
personal, Tester oder Operator.
3.2.3 Reviewarten (K2)
Ein einzelnes Softwareprodukt oder ein darauf bezogenes Arbeitsergebnis kann Gegenstand von
mehr als einem Review sein. Falls mehr als nur eine Reviewart eingesetzt wird, kann die Reihenfolge
variieren. Ein informelles Review beispielsweise könnte vor einem technischen Review durchgeführt
werden oder eine Inspektion einer Anforderungsspezifikation kann vor einem Walkthrough mit Kun-
den durchgeführt werden. Die Hauptcharakteristika, optionale Bestandteile und Zwecke allgemeiner
Reviewarten sind:
Informelles Review
•
kein formaler Prozess
•
kann in Form des Programmierens in Paaren (pair programming) durchgeführt werden oder
ein technischer Experte unterzieht Entwurf und Quellcode einem Review
•
Ergebnisse können dokumentiert werden
•
Nutzen variiert abhängig von den Gutachtern
•
Hauptzweck: Günstiger Weg eine Verbesserung zu erreichen
Certified Tester
Foundation Level Syllabus
(Deutschsprachige Ausgabe)
Version 2011
Seite 35/84
1.8.2011
© International Software Testing Qualifications Board
Walkthrough
•
Sitzung geleitet durch den Autor
•
kann in Form von Szenarien, Probeläufen oder im Kreis gleichgestellter Mitarbeiter (Peer Re-
view) stattfinden
•
Open-End-Sitzungen
•
wahlweise der Sitzung vorausgehende Vorbereitung der Gutachter
•
wahlweise Vorbereitung eines Reviewberichts, der eine Liste der Befunde enthält
•
wahlweise Protokollant (der aber nicht der Autor ist)
•
kann in der Praxis von informell bis sehr formal variieren
•
Hauptzweck: Lernen, Verständnis erzielen, Fehlerzustände finden
Technisches Review
•
dokumentierter und definierter Fehlerfindungsprozess, der gleichgestellte Mitarbeiter und
technische Experten sowie optional Personen aus dem Management einschließt
•
kann als Peer Review ohne Teilnahme des Managements ausgeführt werden
•
idealerweise durch einen geschulten Moderator geleitet (nicht der Autor)
•
Vorbereitung vor der Sitzung durch Gutachter
•
wahlweise Nutzung von Checklisten
•
Vorbereitung eines Reviewberichts, der folgende Punkte enthält: die Liste der Befunde, eine
Gesamtbewertung, inwieweit das Softwareprodukt die Anforderungen erfüllt, und Empfehlun-
gen in Bezug auf die Befunde, wo angebracht
•
kann in der Praxis von informell bis sehr formal variieren
•
Hauptzweck: Diskussion, Entscheidungen treffen, Alternativen bewerten, Fehlerzustände fin-
den, technische Probleme lösen und prüfen, ob Übereinstimmung mit Spezifikationen, Plänen,
Bestimmungen und Standards existiert
Inspektion
•
geleitet durch einen geschulten Moderator (nicht der Autor)
•
gewöhnlich durchgeführt als Prüfung durch gleichgestellte Mitarbeiter
•
definierte Rollen
•
schließt das Sammeln von Metriken ein
•
formaler Prozess basierend auf Regeln und Checklisten
•
spezifizierte Eingangs- und Ausgangskriterien für die Abnahme des Softwareprodukts
•
Vorbereitung vor der Sitzung
•
Inspektionsbericht mit Liste der Befunde
•
formaler Prozess für Folgeaktivitäten (optional mit Komponenten zur Prozessverbesserung)
•
wahlweise Vorleser
•
Hauptzweck: Fehlerzustände finden
Walkthroughs, technische Reviews und Inspektionen können in einer Gruppe von gleichgestellten
Kollegen (Peers), d.h. Kollegen aus der gleichen organisatorischen Ebene, durchgeführt werden. Die-
se Art von Review wird auch „Peer Review“ genannt.
3.2.4 Erfolgsfaktoren für Reviews (K2)
Erfolgsfaktoren für Reviews beinhalten:
•
Jedes Review hat klar definierte Ziele.
•
Abhängig von den Reviewzielen werden geeignete Personen ausgewählt.
•
Tester sind geschätzte Gutachter, die einen Beitrag zum Review leisten. Weiterhin lernen sie
auch das Produkt kennen, was sie befähigt Tests früher vorzubereiten.
•
Gefundene Fehlerzustände werden positiv aufgenommen und werden objektiv zur Sprache
gebracht.
•
Menschliche und psychologische Aspekte werden beachtet, es beispielsweise als eine positi-
ve Erfahrung für den Autor zu gestalten.