03 [L] Statischer Test

1. die Verbesserung der Qualität

2. die Aufdeckung von Fehlerzuständen

3. die Bewertung von Merkmalen wie Lesbarkeit, Vollständigkeit, Korrektheit, Testbarkeit und Konsistenz.

Fast jedes Arbeitsergebnis kann mit statischen Tests untersucht werden. Beispiele hierfür sind 

1. Dokumente zur Spezifikation von Anforderungen

2. Quellcode

3. Testkonzepte

4. Testfälle

5. Produkt-Backlog-Elemente

6. Test-Chartas

7. Projektdokumentation

8. Verträge

9. Modelle

Jedes Arbeitsergebnis, das gelesen und verstanden werden kann, kann Gegenstand eines Reviews sein. 

Für die statische Analyse benötigen Arbeitsergebnisse jedoch eine Struktur, anhand derer sie überprüft werden können, z. B. Modelle, Code oder Text mit einer formalen Syntax.

Zu den Arbeitsergebnissen, die sich nicht für statische Tests eignen, gehören solche, die für den Menschen schwer zu interpretieren sind und die nicht mit Hilfe von Werkzeugen analysiert werden sollten, z. B. ausführbarer Code von Drittanbietern, welcher aus rechtlichen Gründen nicht untersucht werden darf.

1. Der Statische Test kann Fehlerzustände in den frühesten Phasen des SDLC aufdecken und erfüllt damit den Grundsatz des frühen Testens

2. Es können Fehlerzustände aufgedeckt werden, die durch dynamische Tests nicht erkannt werden können, 

   • z. B. nicht erreichbarer Code

   • nicht wie gewünscht implementierte Entwurfsmuster

   • Fehlerzustände in nicht ausführbaren Arbeitsergebnissen.

3. Durch die Überprüfung der dokumentierten Anforderungen können die Stakeholder auch sicherstellen, dass diese Anforderungen ihre tatsächlichen Bedürfnisse beschreiben.

4. Die Kommunikation zwischen den beteiligten Stakeholdern wird verbessert. Aus diesem Grund ist es empfehlenswert, eine Vielzahl von Stakeholdern in statische Tests einzubeziehen.

5. Fehlerzustände im Code können durch statische Analyse effizienter aufgedeckt werden als durch dynamische Tests, was in der Regel sowohl zu weniger Codefehlern als auch zu einem geringeren Gesamtentwicklungsaufwand führt.

1. Beim statischen Test werden Fehlerzustände direkt gefunden, während beim dynamischen Test Fehlerwirkungen auftreten, aus aus denen Fehlerzustände ermittelt werden.

2. Statischer Test kann leichter Fehlerzustände aufdecken, die auf Pfaden durch den Code liegen, die selten ausgeführt werden oder die schwer durch dynamische Tests zu erreichen sind.

3. Statischer Test kann auf nicht ausführbare Arbeitsergebnisse angewandt werden, während dynamischer Test nur auf ausführbare Arbeitsergebnisse angewandt werden kann.

4. Statischer Test kann zur Messung von Qualitätsmerkmalen verwendet werden, die nicht von der Ausführung des Codes abhängen (z. B. Wartbarkeit), während dynamischer Test zur Messung von Qualitätsmerkmalen verwendet werden kann, die von der Ausführung des Codes abhängen (z. B. Performanz).

Weil es Fehler gibt, die teilweise nur von der jeweils einen Technik gefunden werden.

1. Fehlerzustände in Anforderungen, z. B. Inkonsistenzen, Mehrdeutigkeiten, Widersprüche, Auslassungen, Ungenauigkeiten, Duplikationen

2. Fehlerzustände im Entwurf, z. B. ineffiziente Datenbankstrukturen, schlechte Modularität

3. Bestimmte Arten von Fehlerzuständen im Code, z. B. Variablen mit undefinierten Werten, nicht deklarierte Variablen, unerreichbarer oder duplizierter Code, übermäßige Komplexität des Codes

4. Abweichungen von (Coding-)Standards, z. B. mangelnde Einhaltung von Namenskonventionen in Programmierstandards

5. Falsche Spezifikation von Schnittstellen, z. B. nicht übereinstimmende Anzahl, Art oder Reihenfolge von Parametern

6. Spezifische Arten von Schwachstellen in der IT-Sicherheit, z. B. Pufferüberläufe

7. Lücken oder Ungenauigkeiten in der Überdeckung der Testbasis, z. B. fehlende Tests für ein Abnahmekriterium

1. Es ermöglicht die frühzeitige Kommunikation von potenziellen Qualitätsproblemen.

2. Es verhindert Auseinanderdriften von Vorstellungen und somit Probleme, wie Nacharbeiten oder sogar Projektscheitern.

3. Es ermöglicht dem Dev-Team ein besseres Verständnis des Produkts und ein besseres Priorisieren von Anforderungen.

1. Planung

2. Reviewbeginn

3. Individuelles Review

4. Kommunikation und Analyse

5. Behebung und Berichterstattung

Nein, der Prozess wird je nach Use-Case angepasst, bspw. abhängig von der Formalität des Reviews.

Nein, sie können mehrfach ausgeführt werden, wenn das getestete Ergebnis bspw. sehr umfangreich ist.

Festlegung von

1. Umfang (einschl. Zweck)

2. Zu überprüfendes Arbeitsergebnis

3. Zu bewertende Qualitätsmerkmale

4. Schwerpunkte

5. Endekriterien

6. Normen

7. Aufwand für das Review

8. Zeitrahmen

Während des Reviewbeginns geht es darum, sicherzustellen, dass jeder und alles, der oder was benötigt wird, vorbereitet ist, um mit dem Review zu starten.

1. Dazu gehört auch, dass jeder Teilnehmer Zugang zu dem zu prüfenden Arbeitsergebnis hat,

2. seine Rolle und Verantwortlichkeiten versteht / erklärt bekommt und

3. alles erhält, was er für die Durchführung des Reviews benötigt.

Beim individuellen Reviev führt jeder Gutachter führt ein eigenständiges Review durch, um die Qualität des zu prüfenden Arbeitsergebnisses zu bewerten und

• Anomalien,

• Empfehlungen

• und Fragen zu identifizieren

Die Gutachter protokollieren alle von ihnen identifizierten Anomalien, Empfehlungen und Fragen.

 Da es sich bei den während eines Reviews festgestellten Anomalien nicht unbedingt um Fehlerzustände handelt, werden alle diese Anomalien analysiert und diskutiert werden.Für jede Anomalie sollte eine Entscheidung über

1. ihren Status,

2. ihre Verantwortlichkeit und

3. die erforderlichen Maßnahmen getroffen werden.

Zusätzlich wird auch über

1. die Qualität des geprüften Arbeitsergebnisses

2. und über die erforderlichen Folgemaßnahmen entscheiden.

Nach Abschluss der Maßnahmen kann ein Folgereview erforderlich sein.

1. Für jeden Fehlerzustand sollte ein Fehlerbericht erstellt werden, damit die Korrekturmaßnahmen nachverfolgt werden können.

2. Wenn die Endekriterien erreicht sind, kann das Arbeitsergebnis abgenommen werden.

3. Über die Ergebnisse des Reviews wird berichtet

1. Manager

2. Autor

3. Moderator (auch Facilitator genannt)

4. Protokollant

5. Gutachte

6. Reviewleiter

Entscheidet, was geprüft werden soll, und stellt Ressourcen wie Personal und Zeit für das Review zur Verfügung.

Erstellt und korrigiert das zu untersuchende Arbeitsergebnis des Reviews.

Sorgt für einen effektiven Ablauf der Reviewsitzungen, einschließlich Mediation, Zeitmanagement und einer geschützten Reviewumgebung, in der jeder frei sprechen kann.

Sammelt Anomalien von Gutachtern und zeichnet Reviewinformationen auf, z. B. Entscheidungen und neue Anomalien, die während der Reviewsitzung gefunden werden.

Führt Reviews durch. Ein Gutachter (auch Reviewer genannt) kann ein Projektmitarbeiter, ein Fachexperte oder ein anderer Stakeholder sein.

Übernimmt die Gesamtverantwortung für das Review, z. B. die Entscheidung, wer daran teilnimmt, und die Organisation, wann und wo das Review stattfindet.

1. Das SDLC

2. die Reife des Entwicklungsprozesses

3. die Kritikalität und Komplexität des zu prüfenden Arbeitsergebnisses

4. gesetzliche oder regulatorische Anforderungen

5. Bedarf eines Prüfnachweises 

1. Die Reviewziele

2. Projektbedarf

3. Verfügbare Ressourcen

4. Art des Arbeitsergebnisses

5. Unternehmensbereich und -kultur

1. Informelles Review

2. Walkthrough

3. Technisches Review

4. Inspektion

Ein informelles Review folgt keinem definierten Prozess und erfordert keine formalen, dokumentierten Ergebnisse. Das Hauptziel ist die Aufdeckung von Anomalien.

Ein Walkthrough wird vom Autor (des Arbeitsergebnisses) geleitet.

Ein individuelles Review vorab ist nicht verpflichtend.

Wird von einem Moderator geleitet.

Nur technisch qualifizierte Gutachter nehmen teil.

Ziele:

• Finden maximaler Anzahl an Anomalien

• Sammeln von Metriken, um den SDLC (und die Inspektion) zu verbessern

Die formalste Art des Reviews.Folgt dem generischen Reviewprozess

Autor ist weder Reviewleiter, noch Protokollant.

Aufdeckung von Anomalien

1. ✓ Aufdeckung von Anomalien

2. ✓ Bewerten der Qualität

3. ✓ Vertrauen in das Arbeitsergebnis aufbauen

4. ✓ Schulung von Gutachtern

5. ✓ Erzielung eines Konsenses

6. ✓ Generierung neuer Ideen

7. ✓ Motivation und Befähigung von Autoren zur Verbesserung

8. X Entscheidungsfindung in Bezug auf ein technisches Problem

1. ✓ Aufdeckung von Anomalien

2. ✓ Bewerten der Qualität

3. ✓ Vertrauen in das Arbeitsergebnis aufbauen

4. X Schulung von Gutachtern

5. ✓ Erzielung eines Konsenses

6. ✓ Generierung neuer Ideen

7. ✓ Motivation und Befähigung von Autoren zur Verbesserung

8. ✓ Entscheidungsfindung in Bezug auf ein technisches Problem

1. ✓ Aufdeckung von Anomalien

2. ✓ Bewerten der Qualität

3. ✓ Vertrauen in das Arbeitsergebnis aufbauen

4. X Schulung von Gutachtern

5. X Erzielung eines Konsenses

6. X Generierung neuer Ideen

7. ✓ Motivation und Befähigung von Autoren zur Verbesserung

8. X Entscheidungsfindung in Bezug auf ein technisches Problem

1. Die Festlegung klarer Ziele und messbarer Endekriterien. Die Bewertung der Teilnehmer sollte niemals ein Ziel sein.

2. Auswahl der geeigneten Reviewart

3. Durchführung von Reviews in kleinen Einheiten, um nicht die Konzentration verlieren.

4. Lieferung von Feedback aus Reviews an die Stakeholder und Autoren

5. Bereitstellung von ausreichend Zeit für die Teilnehmer zur Vorbereitung auf das Review

6. Unterstützung des Reviewprozesses durch das Management

7. Einbeziehung der Reviews in die Unternehmenskultur

8. Angebot geeigneter Schulungen für alle Teilnehmer, damit sie wissen, wie sie ihre Rolle erfüllen können.

9. Moderation der Sitzungen