Zum Inhalt
wannacode

Arten von Reviews

Kurz gesagt: Ein Review hat fünf Schritte: Planung, Initiierung, individuelles Review, Kommunikation und Analyse sowie Korrektur und Bericht. Die Rollen sind Autor, Reviewer, Moderator, Protokollführer, Review-Leiter und Manager. Die Arten unterscheiden sich in der Förmlichkeit: informell, Walkthrough, technisches Review und Inspektion. Die Checkliste sagt, wonach man sucht, und geprüft wird das Dokument, nicht der Autor.

Problem

„Wir haben es geprüft“

Die Spezifikation der Rückgabe ist fertig. Die Analystin bringt sie zur Montagsbesprechung mit. Sechs Menschen sehen sie zum ersten Mal auf dem Bildschirm. Jemand fragt nach der Schriftart, zwei streiten darüber, wie es in der Datenbank gespeichert wird, der Inhaber sagt „sieht gut aus“. Eine Stunde später ist die Besprechung vorbei. Niemand hat etwas aufgeschrieben.

Zwei Wochen später stellt sich heraus, dass „14 Tage“ ab der Bestellung zählt, das Gesetz aber ab dem Erhalt. Alle waren in der Besprechung. Niemand hat den Text gelesen.

Die Besprechung war kein Review. Es waren Menschen, die sich um ein Dokument versammelt haben.

Die Idee

Die fünf Schritte

Ein echtes Review hat einen Prozess. Im ISTQB CTFL hat er fünf Schritte:

  1. Planung. Was wird geprüft, mit welchem Ziel, von wem, bis wann, mit welcher Checkliste, und wann ist das Review beendet.
  2. Initiierung. Alle bekommen das Dokument und kennen ihre Rolle und wonach sie suchen sollen.
  3. Individuelles Review. Alle lesen allein, vor der Besprechung, und schreiben ihre Befunde auf. Hier wird das Meiste gefunden.
  4. Kommunikation und Analyse. Die Befunde werden gemeinsam besprochen. Zu jedem: Ist es ein Problem, wie wichtig ist es, wer korrigiert es.
  5. Korrektur und Bericht. Der Autor korrigiert. Die Befunde und die Entscheidung werden festgehalten: Ist das Dokument angenommen, oder braucht es ein weiteres Review.

Die Montagsbesprechung war nur Schritt 4, ohne 1, 2 und 3. Deshalb ging es um die Schriftart.

Genauer, für Neugierige

CTFL v4.0.1 (Abschnitt 3.2) beschreibt den Prozess des Reviews von Arbeitsergebnissen und verweist auf den Standard ISO/IEC 20246. Wie viel vom Prozess eingehalten wird, hängt von der Art des Reviews ab: Ein informelles lässt fast alles aus, eine Inspektion folgt ihm vollständig.

Probier es aus

Bring den Prozess in die Reihenfolge

Bring die Schritte des Reviews in die Reihenfolge.

  1. Korrektur und Bericht: der Autor korrigiert, und die Entscheidung und die Befunde werden festgehalten
  2. Individuelles Review: alle lesen allein und schreiben ihre Befunde auf
  3. Initiierung: alle bekommen das Dokument und kennen ihre Rolle
  4. Kommunikation und Analyse: die Befunde werden gemeinsam besprochen, und es werden Entscheidungen getroffen
  5. Planung: was geprüft wird, von wem, bis wann, mit welcher Checkliste

Die Idee

Wer was tut

Rolle Was sie tut Im Review der Rückgabe
Autor hat das Dokument erstellt und korrigiert es die Analystin
Manager entscheidet, was geprüft wird, stellt Menschen und Zeit bereit der Teamleiter
Moderator (facilitator) leitet die Besprechung, achtet auf Zeit und Ton jemand Neutrales, nicht der Autor
Protokollführer (scribe) hält Befunde und Entscheidungen fest jemand aus dem Team
Reviewer liest und findet Probleme QA, ein Entwickler, das Lager, der Inhaber
Review-Leiter ist für das Review als Ganzes verantwortlich: wer teilnimmt, wann, wo oft derselbe wie der Moderator

In einem kleinen Team hat ein Mensch mehrere Rollen. Wichtig ist, dass es die Rollen gibt, nicht, dass es sechs Menschen sind.

Reviewer sind am nützlichsten, wenn sie von verschiedenen Stellen aus schauen. Das Lager fragt „Wer nimmt das zurückgegebene Produkt entgegen?“. Die Buchhaltung fragt „Wann wird das Geld erstattet?“. QA fragt „Und am Tag 14?“.

Probier es aus

Wessen Rolle ist es?

1. Die Analystin, die die Spezifikation der Gutscheincodes geschrieben hat, beantwortet Fragen und korrigiert dann den Text.
2. Jemand leitet die Besprechung: erteilt das Wort und führt das Gespräch zu den Befunden zurück, wenn zwei anfangen, darüber zu streiten, wie man es baut.
3. Jemand schreibt jeden Befund mit seiner Stelle auf und was dazu entschieden wurde.
4. Der Teamleiter entscheidet, dass das Review stattfindet, und gibt den Leuten Zeit dafür.
5. Der Tester und die Person aus dem Lager lesen die Spezifikation und suchen nach Problemen.

Die Idee

Die vier Arten

Reviews unterscheiden sich darin, wie förmlich sie sind. Je riskanter das Dokument, desto mehr Förmlichkeit lohnt sich.

Art Wer leitet Ziel Im Shop
informelles Review niemand; kein Prozess Probleme finden, schnell „schau dir kurz die Kriterien an“
Walkthrough der Autor Probleme finden, dass die Menschen das Dokument verstehen und sich einigen die Analystin führt das Lager durch die Spezifikation der Rückgabe
technisches Review ein Moderator Konsens und eine Entscheidung über eine technische Frage wie Rabatte berechnet werden
Inspektion ein geschulter Moderator so viele Probleme wie möglich finden; Kennzahlen verbessern den Prozess die Spezifikation der Zahlung

Ein informelles Review ist nicht schlecht. Es ist das häufigste und billigste. Aber wenn ein Fehler die Kunden Geld kostet, wie bei der Zahlung, lohnt sich der volle Prozess.

Genauer, für Neugierige

Im CTFL v4.0.1 ist die Inspektion die einzige Art, bei der der Prozess vollständig eingehalten wird und Kennzahlen erhoben werden. Dort darf der Autor nicht Review-Leiter oder Protokollführer sein. Die Art wird nach dem Ziel, dem Risiko, der Kultur des Teams und den Anforderungen des Bereichs gewählt: In regulierten Bereichen (Medizin, Verkehr) sind Inspektionen oft Pflicht.

Probier es aus

Welche Art ist es?

1. Der Entwickler schreibt im Chat: „Schau dir kurz die Kriterien an, bevor ich anfange.“ Der Kollege antwortet mit zwei Anmerkungen.
2. Die Analystin versammelt den Inhaber, das Lager und QA und geht die Spezifikation der Rückgabe Zeile für Zeile durch, damit alle sie verstehen.
3. Drei erfahrene Entwickler und der Architekt treffen sich, um zu entscheiden, wie der Shop Rabatte berechnet, nachdem jeder den Vorschlag gelesen hat.
4. Die Spezifikation der Zahlung durchläuft den vollen Prozess: geschulte Rollen, eine Checkliste, jeder Befund erfasst, ihre Zahl von Projekt zu Projekt verfolgt.

Die Idee

Die Checkliste

Wer liest, „um zu sehen, ob alles in Ordnung ist“, sieht wenig. Wer Fragen hat, sieht viel. Eine Checkliste (checklist) ist eine Liste von Fragen, die an jedes Dokument einer Art gestellt werden.

Eine Checkliste für Anforderungen im Shop:

  • Sagt sie, wer (Kunde, Mitarbeiter, irgendein Besucher)?
  • Gibt es ein Maß statt „schnell“, „bequem“, „übersichtlich“?
  • Ist klar, was an der Grenze passiert (50,00 €, Tag 14, das 10. Stück)?
  • Sagt sie, was im negativen Fall passiert (Stornierung, Fehler, abgelaufener Code)?
  • Gibt es eine geschlossene Liste statt „usw.“?
  • Sagt sie, was, nicht wie?
  • Widerspricht sie einer anderen Anforderung?

Die Checkliste lebt. Jedes Mal, wenn ein Fehler durch ein Review rutscht, fragt das Team „welche Frage hätte ihn gefunden?“ und ergänzt sie.

Und eine Regel zum Ton: Geprüft wird das Dokument, nicht der Autor. „Die Grenze ist hier nicht klar“, nicht „du hast nicht an die Grenze gedacht“. Ein Review, in dem jemand vor Gericht gestellt wird, wiederholt man nicht gern.

Genauer, für Neugierige

CTFL v4.0.1 nennt außerdem, was Reviews erfolgreich macht: klare Ziele und Endekriterien; die richtige Art für das Ziel; kleine Teile, damit die Reviewer nicht ermüden; genug Zeit zur Vorbereitung; Unterstützung durch das Management; eine Kultur, in der ein Review zum Lernen da ist, nicht zur Strafe. Neben Checklisten gibt es andere Arten zu lesen: szenariobasiert (der Reviewer geht das Dokument an einer konkreten Anwendung durch) und perspektivenbasiert (einer liest als Kunde, ein anderer als Tester, ein dritter als das Lager).

Übung

Ein Review mit einer Checkliste

1. Welche Frage fängt es ab? Wähle für jede Anforderung die Frage der Checkliste, die das Problem findet.

1. Die Anforderung: „Der Kunde bekommt für jede Bestellung Treuepunkte.“ Welche Frage der Checkliste findet ein Problem?
2. Die Anforderung: „Die Lieferung ist bei Bestellungen über 50 € kostenlos.“ Welche Frage findet ein Problem?
3. Die Anforderung: „Der Rabatt wird im Feld discount_pct der Tabelle orders gespeichert.“ Welche Frage findet ein Problem?

Test

Teste dich

1. Was gilt für das individuelle Review?
2. Welche Art von Review ist die förmlichste?
3. Wer leitet einen Walkthrough?
4. Warum bespricht ein Review das Dokument und nicht den Autor?
5. Warum ist eine Checkliste nützlich?

Erstellt von Ivo Gergov im Rahmen der Kampagne von Evo Tech für zugängliche Programmierausbildung ·