Walkthrough

R 2.0.0

Was ist ein Walkthrough?

Was ist ein Walkthrough?

Eine Reviewart, bei der ein Autor die Reviewteilnehmer durch ein Arbeitsergebnis leitet und die Teilnehmer Fragen stellen und Auffälligkeiten kommentieren.

Anwendungsbeispiel

Anwendungsbeispiel
ALT MISSING

Christiane hat neu im Referat angefangen und ist dabei erste Testfallspezifikationen für einen Systemtest zu schreiben. Sicher, wie das in der Theorie geht, hat sie während einer ISTQB-Schulung gelernt, aber das jetzt in die Praxis umzusetzen, fällt ihr schwer. Aber da sieht sie ihren Kollegen Volker, mit dem sie zusammen die Schulung besucht hat. Vielleicht hat er Zeit mit ihr zusammen die Spezifikation durchzugehen?

ALT MISSING

"Gute Idee", findet auch Volker, "dann können wir gleich mal ausprobieren, was wir über verschiedene Reviewarten gelernt haben." Christiane überlegt: Wie war das nochmal? Ein "Informelles Review" ist zwar schnell erledigt, aber ein bisschen tiefer möchte sie ja doch in die Sache eindringen und vielleicht hat Volker ja auch noch ein paar Fragen, die sie beantworten kann. Also schlägt sie einen "Walkthrough" vor und stellt gleich einen anderthalbstündigen Termin für den Freitag ein. Als Anhang hängt sie an den Termin ihre Testfallspezifikationen an.

ALT MISSING

"Danke Volker, dass Du mein Reviewer sein möchtest, ich als Autor habe einen Raum gebucht und eine Protokollvorlage auf dem Projektlaufwerk gefunden, denn ich möchte unsere Ergebnisse dem gesamten Team zur Verfügung stellen." "Damit sind ja die Rollen verteilt", lacht Volker, „schreibst Du dann das Protokoll, bitte?" „Hatte ich vor", erwidert Christiane.

ALT MISSING

Das Review verläuft zügig: Volker hat eine Checkliste vorbereitet, die er aus einem Fachbuch kopiert hat. Dort werden die grundlegenden Anforderungen an eine Testfallspezifikation aufgeführt. Christiane freut sich: „Klasse, so was habe ich schon gesucht und konnte es im Internet nicht finden. Das lege ich nachher auf dem Projektlaufwerk ab, das können wir prima wiederverwenden". Sie gehen die einzelnen Punkte der Checkliste durch. „Schau mal. Du hast Dich bei der Versionierung nicht an die Projektvorgaben gehalten", ist einer von Volkers Punkten, die er sich an den Rand der Checkliste geschrieben hat. Ja, richtig! Christiane hatte die Vorgaben gelesen, und in den Dokumentenkopf eingearbeitet, aber übersehen, dass sie den Dateinamen nicht entsprechend angepasst hat. Na, das wäre eine schöne Sucherei auf dem Laufwerk geworden, denkt sie. Super, dass Volker das entdeckt hat!

ALT MISSING

Nach anderthalb Stunden sind sie alle Punkte der Checkliste durchgegangen. Christiane hat fleißig das Protokoll geschrieben und schlägt vor, dass sie einige Punkte der Checkliste mithilfe der Ergebnisse des Protokolls konkretisieren. Volker ist begeistert. "Tolle Idee, und das probieren wir dann nächste Woche bei meinen Spezifikationen aus, mal sehen, was ich alles übersehen habe!"

Beschreibung

Neben dem Erkennen von potenziellen Fehlern kann beim Walkthrough die Konformität mit einzuhaltenden Standards und den umzusetzenden Spezifikationen bewertet werden. Ebenso können Verbesserungen sowie alternative Umsetzungen diskutiert werden. Ideenaustausch über Verfahren oder Stilvariationen sind weitere "Nebeneffekte" und können als zusätzliche Qualifikation der Teilnehmer gesehen werden. Die Ergebnisse des Walkthrough sollen nach Möglichkeit im Konsens erzielt werden.

Schwerpunkt des Walkthrough bildet die Sitzung, die üblicherweise vom Autor des Arbeitsergebnisses geleitet wird. Die Ergebnisse sind aufzuschreiben. Formale Protokolle oder zusammenfassende Berichte der Reviewergebnisse sind nicht zwingend anzufertigen. Die Verwendung von Checklisten ist ebenso optional. Die individuelle Vorbereitung hat im Vergleich zum technischen Review und zur Inspektion den geringsten Umfang, es kann sogar ganz darauf verzichtet werden.

In der Reviewsitzung werden typische Benutzungssituationen, auch Szenarien genannt, ablauforientiert durchgespielt. Simulationen oder Probeläufe von Programmteilen "im Trockenen" (Dry Runs) sind ebenfalls möglich. Es können auch einzelnen Testfälle nachgespielt werden. Die Reviewer versuchen durch spontane Fragen, mögliche Fehler und Probleme aufzudecken.

Für die Nacharbeit ist der Autor verantwortlich, eine Kontrolle findet meist nicht statt.

Mehrwert

  • Ad-hoc-/Szenarien-basiertes Review welches keinem vorgeschriebenen Prozess folgt. Fokus liegt auf der Review-Sitzung

  • Erkennung potenzieller Fehler(-zustände), Know-How Transfer

  • Gegenseitiges Lernen und Austauschen unter KollegInnen

  • Protokolle potenzieller Fehlerzustände und Reviewberichte werden erstellt

  • Kann in der Praxis von recht informell bis hin zu sehr formal variieren

Prüfobjekte

  • Anforderung

  • Komponenten / Units / Module / Klasse

  • Code und Datenstrukturen

  • Datenbankmodule

  • Scripte (Shell- / Datenbank-)

Erforderliche Aktivitäten zur Umsetzung

Unter folgendem Link finden Sie die Planungs-Checkliste für diverse Reviewarten: Reifegradbestimmung & Entscheidungshilfen → Review

Kritische Erfolgsfaktoren

  • Definition von klaren Zielen

  • Auswahl von geeigneten Personen

  • Konstruktive Kritikfähigkeit (gefundene Fehler werden objektiv zur Sprache gebracht und positiv aufgenommen)

  • Psychologische Aspekte (insbesondere Sicherstellung einer positiven Erfahrung für den Autor)

  • Existenz einer Kultur von Lernen und Prozessverbesserung

  • Für die Nacharbeit ist der Autor verantwortlich, eine Kontrolle findet meist nicht statt.

Quellen