Vom Groben ins Feine
Im ersten Teil dieser Reihe [1] haben wir u.a. das statische Testen dem dynamischen Testen gegenübergestellt. Reviews und Code-Analyse wurden dabei zunächst nur grob umrissen. In diesem Artikel werden nun einige Details zu diesen beiden Themen näher beleuchtet.
Statisches Testen mit Reviews
Typische Prüfobjekte der statischen Tests sind Anforderungsdokumente, Spezifikationen, der Source Code des Softwareproduktes selbst, sowie weitere schriftliche Ergebnisse eines Softwareentwicklungsprozesses. Das Prüfen solcher Dokumente kann mit verschiedenen Arten von Reviews erfolgen. In der Regel sind dabei die folgenden Rollen vertreten: Ein Moderator, mehrere Gutachter, sowie ein oder mehrere Autoren des zu begutachtenden Dokuments. Darüber hinaus sollte es zum Grundverständnis aller Beteiligten gehören, dass ausschließlich Dokumente begutachtet werden und nicht der oder die Autoren zu bewerten sind. In der Norm IEEE 1028 sind folgende vier Review-Arten definiert:
- Technischer Review
- Informeller Review
- Walkthrough
- Inspection
Bevor auf die Unterschiede der einzelnen Review-Arten eingegangen wird, betrachten wir den fünfstufigen Review-Prozess. Dieser dient grundsätzlich als Leitfaden und Orientierung für alle Review-Arten, auch wenn er nicht bei jeder Art von Review im Detail befolgt werden kann:
Planung
In der Planung entscheidet das Management, welche Dokumente berücksichtigt werden, welche Review-Art angewandt wird, wie viel Zeit die Durchführung des Review beanspruchen darf und welche Personen geeignet sind, den Review durchzuführen.
Einführung
Häufig wird diese Stufe auch als „Vorbesprechung“ oder „Initialisierung“ bezeichnet. Sie dient dazu, alle am Review beteiligten Personen (Gutachter) mit Informationen zu versorgen. Dazu werden u.a. die Ziele des Review kommuniziert sowie die Review-Gegenstände (Dokumente) bereitgestellt. Hierbei können auch Checklisten für die Prüfkriterien hilfreich sein. Die Einführung kann in Form einer Einladung (E-Mail) kommuniziert werden oder auch durch ein erstes Vorabtreffen des Review-Teams.
Vorbereitung
Vor der eigentlichen Review-Sitzung sollten sich die Teilnehmer auf die Sitzung gut vorbereitet haben d.h. jeder hat bereits die zur Verfügung gestellten Dokumente gelesen, ist die Checklisten durchgegangen und hat Fragen bzw. Unklarheiten formuliert. Nur auf Basis dieser Vorarbeit macht eine Review-Sitzung überhaupt Sinn.
Review-Sitzung
Eine Review-Sitzung sollte nicht länger als 2 Stunden dauern, kann aber an einem Folgetag fortgesetzt werden. Der Moderator darf die Sitzung abbrechen, wenn ein vernünftiges Ergebnis nicht absehbar ist, zu wenig Teilnehmer erschienen sind oder die Teilnehmer nicht ausreichend vorbereitet sind.
Wichtig ist, wie eingangs bereits erwähnt, dass das Dokument (Prüfobjekt) zur Diskussion steht und nicht der Autor. Dieser darf selbst natürlich nicht gleichzeitig als Gutachter agieren, sollte aber anwesend sein. Jeder Gutachter muss angemessen Zeit haben, seine Befunde vorzutragen. Alle Befunde sind zu protokollieren und zu gewichten. Die Entwicklung von Lösungen ist allerdings nicht die Aufgabe des Review-Teams. Abschließend ist seitens der Gutachter eine Empfehlung hinsichtlich der Abnahme des Prüfobjektes abzugeben.
Nachbereitung
In der Nachbereitung entscheidet das Management, ob sie den Empfehlungen des Review folgen oder sie eigenverantwortlich ablehnen. Der Autor wird seinerseits die protokollierten Befunde korrigieren und dem Management vorlegen. War das Resultat des ersten Review nicht befriedigend, wird ein zweiter Review durchgeführt. Dieser kann dann in verkürzter Form stattfinden.
Auch der Review-Prozess selbst sollte bewertet und ggf. angepasst und damit kontinuierlich verbessert werden. Häufig wiederkehrende Fehlerarten, Mängel und Befunde weisen auf generelle Schwächen im Softwareentwicklungsprozess hin.
 |
Abb. 1: Kontrollflussdiagramm (Quelle [1]).
Review-Arten
Nachdem wir die fünf Stufen des Review-Prozesses betrachtet haben, gehen wir nun auf die Unterschiede der vier Review-Arten ein:
Technisches Review
Ein technischer Review dient der fachlichen Prüfung eines Dokuments (z.B. Architekturentwurf). Hier werden Fragen geklärt wie:
- Entspricht der Entwurf der Spezifikation?
- Sind noch Fragen offen, die geklärt werden müssen?
- Sind bereits Fehler erkennbar?
- Gibt es Alternativen?
- Was muss entschieden werden?
Der eingangs beschriebene Prozess sollte bei dieser Review-Art genauestens befolgt werden.
Informeller Review
Ein informeller Review entspricht rein inhaltlich dem technischen Review. Man führt ihn jedoch meist durch, um Zeit zu sparen und hält sich dabei auch nicht exakt an den Review-Prozess. Oft wird er vom Autor selbst initiiert und hat den Charakter eines Gegenlesens.
Eine schriftliche Rückmeldung (z.B. per E-Mail) des Korrektors oder das Rücksenden des korrigierten Prüfobjekts sind als Ergebnis akzeptabel. Informelle Reviews erfahren wegen ihres geringen Aufwands eine hohe Akzeptanz.
Walkthrough
Der Walkthrough wird meist im Kreis gleichgestellter Mitarbeiter durchgeführt. Das Ziel ist es Fehler, Unklarheiten und Probleme in Dokumenten zu finden. Hier übernimmt der Autor selbst die Präsentation, dabei gibt es keine ausgewiesene Moderatorenrolle oder Hierarchien. Walkthroughs zeichnen sich u.a. durch theoretische Probeläufe und das Durchspielen von Szenarien aus. Diese Review-Art ist ebenfalls weniger formalistisch als der beschriebene Prozess und generiert daher auch einen geringeren zeitlichen Aufwand.
Inspection
Von allen Review-Arten ist die Inspection die formalste Variante. Die genaue Vorgehensweise wird in den Normen IEEE 610 und IEEE 1028 detailliert beschrieben. Der Review-Prozess wird dabei mit zusätzlichen Details befolgt. Entsprechend genau und detailreich wird in einer Inspection geprüft. Auch hierbei geht es um die Aufdeckung von Mängeln und Fehlern in Dokumenten. Zusätzlich wird das Prüfobjekt auf Verstöße von Standards sowie auf die Nicht-Konformität gegenüber der Spezifikationen untersucht.
Zu Beginn eines Review muss somit abgewogen werden, welchem Zweck er dienen soll und welche Review-Art somit für das Projekt optimal ist. Dies obliegt der Entscheidung des Projektmanagers bzw. des Managements. Grundsätzlich können kleine Reviews in Form eines Gegenlesens durch eine andere Person niemals schaden und verbessern grundsätzlich die Qualität eines Dokuments.
Alle betrachteten Review-Arten haben trotz ihrer Unterschiede Eines gemeinsam: Sie betrachten Produkte oderTeilprodukte (Dokumente), die während des Entwicklungsprozesses erstellt werden. Der Projektverlauf oder der Entwicklungsprozess als solcher wird dabei nicht betrachtet.
Reviews die sich mit dem Projektverlauf beschäftigen, werden Managementreviews (IEEE 1028) oder auch Projektreviews genannt. Das Ziel dieser Art von Review ist die Analyse des Entwicklungsprozesses an sich. Hierbei werden Fragen gestellt wie:
- Wurden die Vorgaben eingehalten?
- Sind die Arbeitsaufgaben umgesetzt worden?
- Wie effektiv waren die Verbesserungen/Veränderungen?
Des Weiteren wird das Projekt hinsichtlich der Wirtschaftlichkeit und zeitlicher Aspekte betrachtet. Auch das Management des Projektes selbst wird dabei kritisch begutachtet. Managementreviews können weitaus zeitintensiver sein als die anderen vorgestellten Review-Arten.
Insbesondere die kritische Auseinandersetzung mit dem Managementprozess, kann zu einer nachhaltigen Verbesserung im aktuellen aber auch bei zukünftigen Projekten führen.
Code-Analysen im White-Box-Test
Kommen wir nun zum Bereich der Code-Analyse. Wie bereits im ersten Teil dieser Artikelreihe erwähnt, gehört die (Quell-)Code-Analyse zu den White-Box-Tests. „White“ ist hier als Synonym für „sichtbar“ zu verstehen - soll heißen der Quellcode selbst ist das zu analysierende Testobjekt und nicht etwa das Verhalten des laufenden Programms. Die gebräuchlichsten, in der Regel werkzeugunterstützten Testverfahren der Code-Analyse, sind folgende:
- Anweisungsüberdeckung
- Zweigüberdeckung
- Test der Bedingungen
- Pfadüberdeckung
Jedes dieser Testverfahren hat eine spezielle Aufgabe, die den Quellcode hinsichtlich verschiedener Kriterien qualitativ beurteilen soll. Man spricht bei diesen Testverfahren auch von Kontrollflussverfahren. Ein typisches Kontrollflussdiagramm ist in Abbildung 1 dargestellt.
Anweisungsüberdeckung
Bei der Anweisungsüberdeckung stehen die einzelnen Anweisungen im Fokus der Untersuchung. Das Ziel ist es, eine möglichst hohe Anzahl an Anweisungen zu überprüfen. Dabei wird in einem ersten Schritt versucht, die zu überprüfenden Anweisungen in einen Kontrollflussgraphen (siehe Abbildung 1) zu transferieren. Spätestens hier wird klar, dass dies sinnvollerweise nur mit Programmstücken möglich sein wird, da sich komplexe Gesamtprogramme kaum vernünftig in einem solchen Graphen abbilden lassen. Beim Ausführen der Tests ist nun darauf zu achten, dass zuvor festgelegte Anweisungen (Knoten) durchlaufen werden und somit der festgelegte Überdeckungsgrad erreicht wird. Ist dies der Fall, war der Test erfolgreich.
Zweigüberdeckung
Etwas spezifischer wird es bei den Tests hinsichtlich der Zweigüberdeckung. Hier stehen nicht die Knoten im Fokus der Aufmerksamkeit, sondern die Kanten des Kontrollgraphen. Genauer gesagt werden hier die Bedingungen überprüft (IF, THEN, ELSE, SWITCH etc.). Bei Tests auf Zweigüberdeckung wird verlangt, dass immer alle Bedingungen inklusive Rücksprünge und Schleifenanfänge (nicht aber jeder Schleifendurchlauf) berücksichtigt werden. Dies schließt sogar leere ELSE-Zweige mit ein. Um eine 100 prozentige Testabdeckung zu gewährleisten muss jede Kante demnach mindestens einmal durchlaufen worden sein.
Test der Bedingungen
Eine weitere und deutlich komplexere Testmethode ist der Test der Bedingungen. Anders als bei der Zweigüberdeckung wird jedoch nicht immer nur eine Bedingung isoliert betrachtet, sondern eine voneinander abhängige Hierarchie von Bedingungen. So kann eine Bedingung von mehreren logisch voneinander abhängigen (atomaren) Teilbedingungen abhängig sein.
Eine solche Bedingung kann von der Zweigabdeckung nicht oder nur sehr schwer berücksichtigt werden. Beim Test der Bedingungen können mehrere Strategien angewandt werden, die hier nur kurz angerissen werden sollen:
- Einfache Bedingungsüberdeckung: Hier gilt die Forderung, dass jede atomare Teilbedingung einer Entscheidung einmal mit true und einmal mit false getestet werden muss.
- Mehrfachbedingungsüberdeckung: Hier gilt die Forderung, dass alle Kombinationen der atomaren Teilbedingungen berücksichtigt werden müssen. Das Problem dieser Art der Überprüfung ist zum einen der Umfang aber auch die Schwierigkeit, dass nicht immer alle Kombinationen durch Testdaten realisierbar sind.
- Minimale Mehrfachbedingungsüberdeckung: Die Forderung, alle Kombinationen zu berücksichtigen wird hierbei aufgeweicht und dahingehend reduziert,dass nur solche Kombinationen geprüft werden sollen,die zu einer Änderung des Wahrheitswertes führen. Beispielbedingung: if (a && b). Wenn a = false ist, spielt der Wert b keine Rolle mehr. Somit entfällt der Test von b = true oder b = false.
Pfadüberdeckung
Die bisher vorgestellten Kontrollflussverfahren berücksichtigen Schleifen und Wiederholungen nur unzureichend. Diese können mit der Pfadüberdeckung getestet werden. Dieses Verfahren fordert die Ausführung aller unterschiedlichen Pfade durch ein Testobjekt. Ein Pfad wird dabei als Abfolge von Programmteilen in einem Programmstück definiert. Die Pfade berücksichtigen zusätzlich die Abhängigkeiten von Zweigen und Schleifen (sämtliche Durchläufe) untereinander. Aufgrund der Betrachtung von Bedingungen und ggf. auch von Schleifen ist die Pfadüberdeckung die komplexeste Art der Code-Analyse und damit auch die aufwendigste.
Fazit
Erneut kann dieser Artikel lediglich Ansporn sein, sich detaillierter mit dem Thema Qualtiätssicherung zu beschäftigen. Insbesondere der Bereich der Code-Analyse ist ein sehr komplexes Thema, in welches man mit mathemathischen Formeln, Metriken und anderen Berechnungsmodellen beliebig tief eintauchen kann. Wer sich damit eingehender beschäftigen möchte, dem sei das Buch von Peter Liggesmeyer [2] zu empfehlen, welches auch als Basis für diesen Artikel diente.
Durch unser umfangreiches Dienstleistungangebot auf dem Gebiet der Qualitätssicherung verfügen wir über qualifizierte Experten, die Sie gern diesbezüglich beraten, unterstützen und Ihre Fragen beantworten.
Bildnachweis: fotolia.com | durchblick | drubig-photo
