3. Statische Prüftechniken und der Testprozess Flashcards
(31 cards)
Statische Tests
Anders als das dynamische Testen, welches die Ausführung der Software voraussetzt, beruhen statische Prüftechniken auf der „manuellen“ Überprüfung (Reviews) oder automatisierten Analysen (statische
Analyse) des Codes oder anderer Projektdokumentation,ohne den Programmcode auszuführen.
Reviews
Ein Review kann komplett als manuelle Aktivität durchgeführt, aber ebenso durch Werkzeuge unterstützt werden.
Die wichtigste manuelle Tätigkeit ist die Prüfung und Kommentierung des Arbeitsergebnisses.
Jedes Arbeitsergebnis der Softwareentwicklung kann einem Review unterzogen werden, einschließlich Anforderungsspezifikationen, Designspezifikationen, Quellcode, Testkonzepte, Testspezifikationen,
Testfälle, Testskripte, Anwenderhandbücher oder Web-Seiten.
Reviews, statische Analyse und dynamische Tests
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üftechniken eher Ursachen der Fehlerwirkungen (Fehlerzustände) als Fehlerwirkungen selbst.
Vorteile von Reviews
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 Kommunikation.
Reviews können beispielsweise Auslassungen in Anforderungen aufdecken (z.B. fehlende Funktionen), die durch einen dynamischen Test vermutlich nicht gefunden würden.
Typische Fehlerzustände
die durch Reviews aufgedeckt werden
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
- Fehlerzustände im Design
- unzureichende Wartbarkeit und
- fehlerhafte Schnittstellenspezifikationen.
Mögliche Ziele eines Reviews
- Finden von Fehlerzuständen
- Erwerben von Verständnis
- Ausbildung von Testern und neuen Teammitgliedern oder
- einer Diskussion und Entscheidungsfindung im Konsens.
Aktivitäten eines formalen Reviews
- Planen
- Kickk-off
- Individuelle Vorbereitung
- Prüfen/Bewerten/Festhalten der Ergebnisse (Reviewsitzung)
- Überarbeitung
- Nachbearbeitung
Aktivitäten eines formalen Reviews
Planen
- Festlegen von Review-/Prüfkriterien
- Auswahl der beteiligten Personen
- Besetzen der Rollen
- Festlegen der Eingangs- und Endekriterien bei mehr formalen Reviewarten (z.B. Inspektion)
- Auswahl der zu prüfenden Dokumententeile
- Prüfen der Eingangskriterien (bei formaleren Reviewarten)
Aktivitäten eines formalen Reviews
Kick-off
- Verteilen der Dokumente
- Erläutern der Ziele, des Prozesses und der Dokumente den Teilnehmern gegenüber
Aktivitäten eines formalen Reviews
Individuelle Vorbereitung
- Vorbereiten der Reviewsitzung durch Prüfung des/der Dokuments/e
- Notieren von potenziellen Fehlerzuständen, Fragen und Kommentaren
Aktivitäten eines formalen Reviews
- *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 Entscheidungen über die Fehlerzustände
- Prüfen/Bewerten und Protokollieren von Problemen während eines physischen Treffens oder Nachverfolgen von elektronischer Gruppenkommunikation
Aktivitäten eines formalen Reviews
Überarbeiten
- Beheben der gefundenen Fehlerzustände typischerweise durch den Autor
- Protokollieren des aktualisierten Fehlerstatus (in formalen Reviews)
Aktivitäten eines formalen Reviews
Nachbereiten
- Prüfen, ob Fehlerzustände zugewiesen wurden
- Sammeln von Metriken
- Prüfen von Endekriterien (bei formaleren Reviewarten)
Formale Reviews
Rollen und Verantwortlichkeiten
Bei einem typischen formalen Review findet man folgende Rollen:
- Manager
- Moderator
- Autor
- Gutachter
- Protokollant
Formale Reviews - Rollen
Manager
Die Person, die
- über die Durchführung von Reviews entscheidet,
- Zeit im Projektplan zur Verfügung stellt und
- überprüft, ob die Reviewziele erfüllt sind.
Formale Reviews - Rollen
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 verschiedenen Standpunkten vermitteln.
- Er ist häufig die Person, von der der Erfolg des Reviews abhängt.
Formale Reviews - Rollen
Autor
Der Verfasser oder die Person, die für das/die zu prüfende/n Dokument/e hauptverantwortlich ist.
Formale Reviews - Rollen
Gutachter
- Personen mit einem spezifischen technischen oder fachlichen Hintergrund (auch 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 allen Reviewsitzungen teilnehmen können.
Formale Reviews - Rollen
Protokollant
- Die Person, die alle Ergebnisse, Probleme und offenen Punkte dokumentiert, die im Verlauf der Sitzung identifiziert werden.
Reviews und Checklisten
Softwareprodukte oder darauf bezogene Arbeitsergebnisse aus verschiedenen Perspektiven zu betrachten und Checklisten zu nutzen, kann Reviews wirksamer und effizienter machen.
So kann eine Checkliste helfen, bisher unentdeckte Probleme aufzudecken, wenn sie typische Anforderungsprobleme enthält und unterschiedliche Perspektiven einnimmt, beispielsweise vom Benutzer, Wartungspersonal,
Tester oder Operator.
Reviewarten
- Informelles Review
- Walkthrough
- Technisches Review
- Inspektion
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
Walkthrough
- Sitzung geleitet durch den Autor
- kann in Form von Szenarien, Probeläufen oder im Kreis gleichgestellter Mitarbeiter (Peer Review) 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
- Empfehlungen 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 finden,
- technische Probleme lösen und
- prüfen, ob Übereinstimmung mit Spezifikationen, Plänen, Bestimmungen und Standards existiert