Review-Individuelle Vorbereitung

Wie der Name bereits nahe legt, sind keine Vorgaben gegeben, wie die individuelle Vorbereitung beim Ad-hoc-Review durchzuführen ist. Der Reviewer liest das Arbeitsergebnis meist sequenziell und erkennt Probleme, Befunde oder Fehler und dokumentiert diese. Die Art der Dokumentation ist ebenso wenig vorgegeben. Ad-hoc-Reviews werden oft durchgeführt, da sie kaum bzw. keinerlei Vorbereitung erfordern. Da kein definiertes Vorgehen vorgeschrieben ist, ist das Ad-hoc-Review besonders stark von den Fähigkeiten des einzelnen Reviewers abhängig. Prüfen mehrere Reviewer ein Arbeitsergebnis, kommt es häufig vor, dass viele Probleme doppelt von den verschiedenen Reviewern gemeldet werden.

Zur Steigerung der Effektivität der Reviews können Checklisten eingesetzt werden, die ein strukturiertes Lesen unterstützen. Sie helfen bei der Aufdeckung von Unstimmigkeiten und Fehlern. Es kann festgelegt werden, welche Checklisten von welchem Reviewer genutzt werden sollen. Eine Review-Checkliste besteht aus einem Satz von Fragen, die auf potenziellen Fehlern basieren. Die Fragen ergeben sich aus der Erfahrung, z.B. aus früheren Projekten. Die Fragen der Checkliste können sich auch auf einzuhaltende Formalitäten oder Standards beziehen.

Der Hauptvorteil des checklistenbasierten Reviews liegt in der systematischen Abdeckung typischer Fehlerarten. Ein Nachteil wird darin gesehen, dass die Checkliste das Review zu stark fokussiert und Fehler "neben" den Checklistenfragen unerkannt bleiben. Es ist daher darauf zu achten, dass auch nach Fehlern "außerhalb" der Checkliste gesucht wird.

Beim rollenbasierten Review hat der Reviewer den Auftrag, das Prüfobjekt aus der Sicht einer bestimmten fachlichen Rolle zu prüfen. Dazu muss er sich in die jeweilige Rolle ausreichend hineinversetzen können oder selbst in der betreffenden Rolle tätig sein. Grundidee des rollenbasierten Vorgehens beim Review ist die Nutzung des Fachwissens der jeweiligen Rolle. Dieses muss von den Personen, die die Rolle einnehmen, "mitgebracht" werden. Es ist beispielsweise sehr sinnvoll, Tester an den Reviews der Anforderungen zu beteiligen. So wird frühzeitig geprüft, ob die Anforderungen ausreichend detailliert und präzise formuliert sind, um daraus Testbedingungen und Testfälle abzuleiten.

Weitere typische Rollen sind die von Stakeholdern, wie z.B. Endanwendern oder den späteren Betreibern der Systeme in einer Organisation. Kann der Endanwender oder der Betreiber nicht am Review teilnehmen - was die Regel sein wird -, sind die Rollen von den am Review teilnehmenden Personen einzunehmen. Dabei kann die Rolle "Endanwender" auch weiter präzisiert werden, z.B. in erfahrener oder unerfahrener Nutzer. Wird das Softwaresystem in einer Organisation eingesetzt, kann beispielsweise die Rolle des Administrators eingenommen werden.

Alle unterschiedlichen Rollen weisen so auf mögliche Fehler, Unstimmigkeiten und Lücken hin. Kernidee beim perspektivischen Vorgehen ist, dass jeder Reviewer aus einer unterschiedlichen Perspektive auf das Reviewobjekt schaut und damit verbunden andere Szenarien durchdenkt oder "durchspielt". Die erzielten Erkenntnisse werden nicht nur zur Bewertung des untersuchten Dokuments herangezogen, sondern können auch genutzt werden, um Dringlichkeit und Umfang von Korrekturmaßnahmen abzustimmen.