Inhalt dieser Lerneinheit

Im Rahmen dieser Lerneinheit werden sie mit den folgenden Themen vertraut gemacht:

• Definition statische Test

• Reviews und Review-Prozess

• Review-Arten

• Werkzeuggestützte Test

Definition

Testen einer Komponente oder eines Systems auf Anforderungs- und Implementierungsebene ohne Ausführung der Software, z.B. durch Reviews oder statische Codeanalyse. Der statische Test ist eine Überprüfung, Vermessung und Darstellung eines Programms oder einer Komponente bzw. eines Dokuments, das eine formale Struktur hat.

Open

Reviews

Reviews sind eine Möglichkeit, Arbeitsergebnisse der Softwareentwicklung (einschliesslich Code) zu prüfen und können problemlos bereits lange vor der dynamischen Testrealisierung durchgeführt werden.

Manuelle Prüfmethode mit mehr oder weniger festgelegtem Ablauf, die (nach einer individuellen Vorbereitung der Gutachter) in einer Teamsitzung die Stärken und Schwächen eines schriftlich vorliegenden Prüfobjektes identifiziert.

Was kann durch Reviews geprüft werden?

• Projektauftrag,

• Projektplan,

• Anforderungsspezifikation,

• Designspezifikation,

• Quelltext,

• Testkonzept,

• Testspezifikationen,

• Testfälle,

• Testskripts,

• Anwenderhandbücher,

• Web-Seiten,

• Schulungsunterlagen

• Schulungsplan,

• etc.

Vorteile von Reviews

Fehler, die durch Reviews in den frühen Phasen des Software-Lebenszyklus entdeckt werden, sind bedeutend kostengünstiger zu beheben als solche, die erst während der Testdurchführung gefunden werden (z.B. Fehler in den Anforderungen). Zu den Vorteilen von Reviews zählen:

• Werden frühzeitig Fehler erkannt und beseitigt, führt dies zu einer Produktivitätssteigerung in der Entwicklung, da weniger Ressourcen für die Fehlererkennung und Beseitigung benötigt werden und diese somit der Entwicklung zur Verfügung stehen. Dies hat auch zur Folge, dass sich der Entwicklungsaufwand verkürzt.

• Werden Fehler frühzeitig erkannt und behoben, führt dies zu einer Verringerung der Kosten und der benötigten Zeiten für den dynamischen Test, da weniger Fehlerzustände im Testobjekt vorhanden sind.

• Durch die geringere Zahl an Fehlern und Ungenauigkeiten ist auch eine Kostenreduzierung während der Lebenszeit des Produkts zu erwarten. Beispielsweise können durch Reviews Ungenauigkeiten der Kundenwünsche in den Anforderungen aufgedeckt werden.

• Vorhersehbare Änderungswünsche nach der Inbetriebnahme des Softwaresystems sind damit im Vorfeld zu verhindern. Es ist auch eine reduzierte Fehlerhäufigkeit im Einsatz des Systems zu erwarten.

• Da die Überprüfungen durch Teams erfolgt, ergibt sich daraus ein Wissensaustausch unter den beteiligten Personen. Dies führt zur Optimierung der Arbeitsmethoden der einzelnen Personen und verbessert die Qualität weiterer Produkte.

• Da mehrere Personen an einem Review teilnehmen, ist eine klare und verständliche Darstellung der Sachverhalte notwendig.

• Oft bringt der Zwang zu einer klaren Darlegung den Autor bereits zu Einsichten, die er vorher nicht hatte. Das gesamte Team fühlt sich verantwortlich für die Qualität des untersuchten Prüfobjekts und Gesamtproduktes.

• Ein einheitliches Verständnis über das Prüfobjekt entwickelt sich. Reviews können Auslassungen (z.B. fehlende Anforderungen) und Funktionen aufdecken, die durch einen dynamischen Test (vermutlich) nicht aufzuspüren sind.

Fehlerzustände bei Reviews

Reviews können Auslassungen, bspw. die fehlende Umsetzung einer Anforderung oder fehlende Funktionen aufdecken, die durch einen dynamischen Test vermutlich nicht gefunden werden. Im Gegensatz zum dynamischen Test finden Reviews eher Fehlerzustände als Fehlerwirkungen. Zu den typischen Fehlerzuständen, die effektiver und effizienter durch Reviews als durch dynamische Tests zu finden sind, gehören (Liste nicht abschliessend):

• Abweichungen von Standards

• Fehler in Anforderungen

• Fehler im Design

• Unzureichende Wartbarkeit

• falsche Schnittstellenspezifikationen

Der Review-Prozess

Open

Rollen und Verantwortlichkeiten im Reviewprozess

Manager oder Projektleiter

Entscheidet über Durchführung von Reviews, stellt Zeit im Projektplan zur Verfügung und überprüft, ob die Review-Ziele erfüllt sind.

Moderator

Leitet die Review, einschliesslich der Review-Planung, Leitung der Sitzung und Nachbereitung.

Falls nötig kann der Moderator zwischen den verschiedenen Standpunkten vermitteln.

Er ist häufig die Person von welcher der Erfolg der Review abhängt.

Autor

Verfasser der zu prüfenden Dokumente.

Gutachter

Für diese Rolle sollten Personen mit einem spezifischen technischen oder fachlichen Hintergrund gewählt werden.

Auch sollten Gutachter so gewählt werden, dass verschiedene Sichtweisen vertreten sind.

Sie nehmen an allen Review-Sitzungen teil.

Protokollant

Dokumentiert alle Ergebnisse, Probleme und offenen Punkte die im Verlauf der Sitzung identifiziert werden.

Arbeitsmittel im Review-Prozess

Nachfolgende Arbeitsmittel für Reviews sind bereitzustellen:

• Vorgaben und Leitfäden zur Unterstützung der verschiedenen Rollen beim Review und der verschiedenen Review-Varianten.

• Checklisten und/ oder Fragenkataloge spezifisch für die Klassen der Prüflinge und die verschiedenen Aspekte.

• Review-Einladung.

• Mängelliste.

• Review-Bericht.

Grundsätze für Reviews

• Ein Review zielt darauf ab, die vorhandenen Fehler zu finden.

• Die für die Projektplanung zuständige Person sollte genügend Zeit für Reviews einkalkulieren.

• Zudem ist zu kontrollieren, ob sich die Teilnehmer ausreichend vorbereiten konnten.

• Gegebenenfalls ist es auch möglich/ nötig, den Review abzubrechen.

• An einem Review nehmen im Idealfall zwischen drei und sieben Personen über einen Zeitraum von maximal zwei Stunden teil.

• Der Moderator ist kein Gutachter.

• Der Autor verhält sich während des Reviews passiv, klärt jedoch Missverständnisse auf und beantwortet Fragen.

• Es steht der Prüfling im Fokus, nicht der Autor.

• Daher obliegt es dem Moderator, persönliche Angriffe gegen den Autor sowie unnötige Rechtfertigungen des Autors zu unterbinden.

• Die Probleme werden im Review Meeting nur genannt.

• Es werden keine Lösungswege diskutiert, erarbeitet oder vorgeschlagen.

Erfolgsfaktoren

• Jedes Review hat klare, vordefinierte Ziele.

• Die geeigneten Personen sind einzubinden, um die Review-Ziele zu erreichen.

• Gefundene Fehler werden positiv aufgenommen und sachlich angesprochen.

• Es gilt den Umgang mit den Fragen der Beteiligten und die damit verbundenen psychologischen Aspekte zu berücksichtigen, indem man bspw. versucht, den Review für den Autor zu einer positiven Erfahrung zu machen.

• Review-Techniken werden so angewendet, dass sie für Typ und Stufe der Arbeitsergebnisse in der Softwareentwicklung und für die Gutachter geeignet sind.

• Sind sie dafür geeignet, die Effektivität der Fehleridentifikation zu steigern, werden Checklisten und/ oder Rollen verwendet.

• Insbesondere für die eher formalen Methoden, wie bspw. Inspektionen, finden Schulungen zu den Review-Techniken statt.

• Das Management unterstützt den Review-Prozess durch die Bereitstellung einer angemessenen Zeit für Review-Aktivitäten in Projektplänen.

Review-Arten

Nachfolgende Aspekte gelten für informelle Reviews:

• Es ist kein formaler Prozess.

• Er kann als «Pair-Programming» (Scrum, eXtreme Programming) gestaltet werden.

• Es kann sein, dass ein technischer Leiter Entwurf und Quelltext prüft.

• Eine Dokumentation der gefundenen Fehler ist möglich.

• Der Nutzen ist stark abhängig von den Fähigkeiten des Gutachters.

• Das Hauptziel ist: kostengünstigster Weg und hoher Nutzen in kurzer Zeit.

Nachfolgende Aspekte gelten beim Walkthrough:

• Die Sitzung wird durch den Autor geleitet.

• Es können Szenarien oder Probeläufe verwendet werden.

• Findet im Kreis gleichgestellter Mitarbeiter statt.

• Sind immer «Open-End»-Sitzungen.

• Möglich sind: eine der Sitzung vorausgehende Vorbereitung der Gutachter, ein Review-Bericht, eine Liste der Befunde und der Einsatz eines Protokollanten (der aber nicht der Autor ist).

• Variiert in der Praxis von informellen bis hin zu sehr formalen Varianten.

• Hauptziele: Lernen, Verständnis, Fehler finden

Nachfolgende Aspekte gelten beim technischen Review:

• Dokumentierter, definierter Fehlerfindungsprozess, der gleichgestellte Mitarbeiter (Peer-Review) und technische Experten einschliesst.

• Soll als Peer-Review ohne Teilnahme des Managements ausgeführt werden.

• Idealerweise von einem geschulten Moderator geleitet (nicht vom Autor).

• Vorbereitung der Gutachter (Studium der Unterlagen) vor der Sitzung.

• Nutzung von Checklisten, Review-Berichte und ein Liste der Befunde ist möglich.

• In Ausnahmefällen Beteiligung des Managements (wenn Entscheidungen getroffen werden müssen).

• In der Praxis: von informellen bis hin zu sehr formalen Varianten.

• Hauptziele: Diskussion, Entscheidungen treffen, Alternativen bewerten, Fehler finden, technische Probleme lösen und prüfen, ob Übereinstimmung mit Spezifikationen und Standards existiert.

Nachfolgende Aspekte gelten bei der Inspektion:

Wird geleitet von einem geschulten Moderator (nicht vom Autor).

Üblicherweise Prüfung durch gleichgestellte Mitarbeiter.

Es gibt definierte Rollen.

Es werden Metriken erfasst.

Ist ein formaler Prozess, basierend auf Regeln und Checklisten sowie Eingangsbedingungen und Endbedingungen.

Es braucht eine Vorbereitung der Gutachter vor der Sitzung.

Es werden ein Inspektionsbericht und ein Liste der Ergebnisse erstellt.

Es gibt einen formalen Prozess für die Folgeaktivitäten.

Optional kann ein Vorleser eingesetzt werden.

Möglicherweise führen die Resultate zu Prozessverbesserungen.

Hauptziel: Fehler finden.

Statische Analyse (werkzeuggestützt)

Statische Analyse

Überprüfung, Vermessung und Darstellung eines Programms oder einer Komponente (bzw. eines Dokumentes, das eine

formale Struktur hat).

Die statische Analyse zielt darauf ab, Fehler im Softwarequellcode oder in den Softwaremodellen zu finden.

Sie wird durchgeführt, ohne dass die untersuchte Software tatsächlich durch das Werkzeug ausgeführt wird.

Für Dokumente kann die werkzeuggestützte statische Analyse nur angewendet werden, wenn diese einen formalen Struktur unterliegen (HTML, XML).

Auch Programmtext kann mit Werkzeuge analysiert werden.

Vorteil statische Test

Nutzen der statischen Analyse

Nutzen der statischen Analyse Die statische Analyse hat nachfolgenden Nutzen:

• Bereits vor der Durchführung von dynamischen Tests können potenzielle Fehler erkannt werden.

• Sie warnt vor verdächtigen Aspekten in Code oder Design durch die Berechnung von Kennzahlen. (z. B. Komplexitätsmass nach McCabe).

• Sie ermöglicht das Aufdecken von Abhängigkeiten und Inkonsistenzen in der Software (nicht verbundene Links, nicht kompatible Schnittstellen u. ä.).

• Die Wartbarkeit von Code und Design wird dadurch verbessert.

• Lernt aus den Erfahrungen und das Gelernte wird im Entwicklungsprozess einbezogen, kann dadurch Fehlerzuständen vorbeugen.

Arten von Fehlern

• Referenzierung einer Variablen mit nicht definiertem Wert

• Inkonsistente Schnittstellen zwischen Modulen

• Syntax-Verletzungen von Code und Softwaremodellen

• Variablen, die nie verwendet werden

• Unerreichbarer (toter) Code

• Verletzung von Programmierkonventionen

• Sicherheitsschwachstellen

• Komplexität von Code

• Datenfluss durch Code

• Kontrollfluss durch Code

• Metriken und Messungen