3 Statischer Test: Aufzählungen Flashcards
Statische Analyse
prüft AE hinsichtlich…
LZ
FORM & STRUKTUR
- formale Beschreibung Anforderung
- Vorhandensein Code-Dokumentation
- Entwurfsregeln & Architekturmuster
- Rechtschreibung & Grammatik
Einsatzgebiete
Reviews & statische Analysen:
Gegenüberstellung
LZ
Review:
- jedes AE, von dem
- Teilnehmer wissen, wie es zu lesen & zu verstehen ist
Statische Analysen:
jedes AE mit
- FORMALER Struktur, für die es ein geeignetes
- statisches Analysewerkzeug gibt
- auch AE, die in natürlicher Sprache geschrieben sind
(z.B. Prüfung Rechtschreibung, Grammatik und Lesbarkeit)
Statischer Test:
Vorteile & SWELZ
(Fließtext Lehrplan)
LANG
LZ
Früherer Einsatz im SWELZ möglich
- vor Einsatz dynamischer Tests oder
- sogar vor Erstellen Code
=> frühes Erkennen von FZ
=> früh gefundene FZ lassen sich kostengünstiger entfernen, insbesondere im Vergleich zur Situation nach Auslieferung
(= “nachdem SW auf Zielumgebung gebracht & aktiv in Nutzung”)
Kosteneinsparung im Vergleich zu Einsatz dynamische Tests insbesondere unter Berücksichtigung
zusätzliche Kosten
- Aktualisierung anderer Arbeitsergebnisse
- Durchführung Fehlernachtests & Regressionstests
Statischer Test:
Vorteile & SWELZ
(Fließtext Lehrplan)
KURZ
LZ
Früherer Einsatz im SWELZ möglich
=> frühes Erkennen von FZ
=> früh gefundene FZ lassen sich kostengünstiger entfernen
=> statische Testverfahren fast immer
EFFIZIENTER als dynamische
SWELZ und Fehleranfälligkeit
Dojo
Die meisten Fehler werden in den
frühen Phasen begangen
- Analyse
- Entwurf
(Gleichzeitig Aufwand Fehlerbehebung
- je früher
- desto geringer)
Statische & dynamische Tests:
Gemeinsamkeit & Unterschiede
LZ
Gemeinsam: Testziele
Unterschied: FEHLERART
- dynamische Tests: Fehlerwirkung
- statische Tests: Fehlerzustand, auch diejenigen, die keine FW verursachen (z.B. selten genutzter oder schwer erreichbarer Pfad)
Unterschied Fokus:
- dynamische Tests: extern sichtbares Verhalten
- statische Tests: Konsistenz & interne Qualität des AE verbessern
Statische & dynamische Tests:
interne & externe Qualität
Dojo
LZ
Statische Tests
- Konsistenz &
- interne Qualität von AE
Dynamische Tests
- extern sichtbares Verhalten des TO
- externe Qualität
Informelle <=> formale Reviews
Dojo
LZ
Informelle Reviews:
- folgen keinem definierten Prozess
- kein formal dokumentiertes Ergebnis
Formale Reviews:
- Dokumentierte Vorgehensweise für Durchführung
- Dokumentierte Ergebnisse
- Teilnahme von Teams
Review-Prozess:
Hauptaktivitäten
LZ
Planung
Review-Beginn/ Kick-off
Individuelles Review
Befundkommunikation & -analyse
Fehlerbehebung & Bericht/ Follow-up
Nachbereitung/ Lessons learnt (optional)
FORMALES Review:
Rollen Aufzählung
LZ
Autor
Management
Moderator
Review-Leiter
Gutachter
Protokollant
Rollen FORMALER Review im
Review-Prozess
Hauptaktivitäten & Verantwortlichkeiten
LZ
Planung: Management
Reviewbeginn/ Kick-off: alle
Individuelles Review: individueller Gutachter
Befundkommunikation & -analyse: alle, Dokumentation durch Protokollant
Fehlerbehebung & Bericht/ Follow-up:
Autor AE, Review-Leiter/Moderator
Nachbereitung/ Lessons learnt (optional): Review-Leiter/ Moderator
Review-ARTEN
LZ
Informell
Walkthrough
Technischer Review
Inspektion
Informelles Review:
Gutachter &
weitere Punkte
neben Zweck und Kategorien Formalität
LZ
Beispiele:
Buddy-Check, Pairing, Paarweiser Review
in agiler Entwicklung verbreitet
Gutachter:
- ein Kollege Autor oder mehrere Personen
- Nutzen hängt stark von Person Gutachter ab (Qualifikation, Erfahrung)
Walkthrough Formen
LZ
Szenarios
Dry Run (Probelauf)
Simulationen
Technisches Review:
Gutachter
LZ
Gutachter sollten
- fachspezifische Kollegen des Autors und
- fachspezifische Experten in der gleichen oder in anderen Disziplinen sein
Inspektion:
Rollen
LZ
Nutzung verpflichtend von beschriebenen
klar definierten Rollen
plus evtl. Vorleser:
- liest AE Review-Sitzung laut vor,
- häufig paraphrasiert (d.h. sinngemäß, in eigenen Worten) wiedergibt
Autor kann NICHT als
- Review-Leiter
- Vorleser oder
- Protokollant agieren
Inspektion:
Formale Steuerung
LZ
Nutzung von
- vorab festgelegten
Eingangs- und -Endekriterien - weiteren Metriken, um
gesamten Softwareentwicklungsprozess zu verbessern, einschließlich des Inspektionsprozesses
Review-VERFAHREN für
individuellen Review:
AUFZÄHLUNG
LZ
Ad-hoc-Review
Checklistenbasierte Reviews
Szenarien & Dry Runs
Perspektivischer Review
Rollenbasierter Review
Review-Verfahren: Checklistenbasiert
LZ
Checklisten sollten
- bei Reviewbeginn verteilt werden
- auf potenziellen FZ & Erfahrungen basieren
- spezifisch auf Art geprüftes AE zugeschnitten
- regelmäßig ergänzt, um in früheren Reviews übersehene Befundarten
Immer auch mögliche FZ außerhalb Checkliste berücksichtigen!
Review-Verfahren: Szenariobasiert
LZ
Strukturierte Richtlinien, wie Gutachter AE durchlesen sollen
Immer auch FZ außerhalb Szenarien berücksichtigen!
Mit AE werden
- auf Basis der ERWARETEN Nutzung Probeläufe (Dry Runs) durchgeführt
Szenarien bessere Richtlinien als
- einfache Checklisteneinträge
Szenarien müssen in angemessenem Format dokumentier sein wie Anwendungsfälle
Review-Verfahren: Rollenbasiert
LZ
Konzentration auf eine bestimmte Rolle unterstützt
- zielgerichtete Prüfung des AE
Typische Rollen:
- Arte von Endanwendern ( Kinder/ Senioren, (un)erfahren..)
- Rollen innerhalb Organisation (Benutzeradministrator, Systemadministrator…)
Review-Verfahren: Perspektivisch
LZ
Gutachter leiten
- auf Basis ihrer Perspektive
- aus zu prüfendem AE weitere AE ab
Effektives Verfahren für Review von
- Anforderungen
- technischen AE
Voraussetzung:
- korrekte Einbeziehung &
- angemessene Gewichtung
Perspektiven verschiedener Stakeholder
Reviews:
Erfolgsfaktoren
ORGANISATION
Überblick
LZ
- Ziele
- Passende Review-Arten
- Geeignete Review-Verfahren
- Checklisten: aktuell & Hauptrisiken
- Frühe & häufige Rückmeldungen FZ an Autoren
- Zeitliche Planung
- Unterstützung Management
- Reviews in Qualitäts- und Testrichtlinien Org, integriert
