> ## Documentation Index
> Fetch the complete documentation index at: https://docs.baenninger.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Reviews

Ein Review ist eine Form des statischen Tests, bei der Arbeitsergebnisse (wie Anforderungen oder Code) durch eine oder mehrere Personen systematisch begutachtet werden, ohne dass das Testobjekt auf einem Rechner ausgeführt wird.

## Nutzen

Der Hauptzweck von Reviews liegt in der Prävention. Indem Fehlerzustände und Unstimmigkeiten frühzeitig erkannt werden, noch bevor sie in nachfolgende Entwicklungsschritte einfliessen, lassen sich Zeit und Kosten für aufwendige Nachbesserungen sparen.

<AccordionGroup>
  <Accordion title="Qualitätssteigerung">
    Dokumente werden auf Merkmale wie Lesbarkeit, Vollständigkeit, Korrektheit und Testbarkeit geprüft.
  </Accordion>

  <Accordion title="Wissensaustausch">
    Die gemeinsame Prüfung fördert ein einheitliches Verständnis im Team und verbessert die Arbeitsmethoden der Beteiligten.
  </Accordion>

  <Accordion title="Wartbarkeit">
    Reviews identifizieren Schwachstellen wie schlechte Modularisierung oder schwer verständlichen Code, was die langfristigen Wartungskosten senkt.
  </Accordion>

  <Accordion title="Frühes Feedback">
    Besonders in agilen Projekten ermöglichen Reviews eine schnelle Rückmeldung zu User Stories und Anforderungen.
  </Accordion>
</AccordionGroup>

## Vorgehen

Ein formaler Reviewprozess nach dem ISTQB-Standard umfasst typischerweise fünf Hauptaktivitäten.

<Steps>
  <Step title="Planung">
    Hier werden die Ziele, die Reviewart sowie Rollen und Verantwortlichkeiten festgelegt. Zudem werden Eingangs- und Endekriterien definiert, um den Erfolg messbar zu machen.
  </Step>

  <Step title="Reviewbeginn">
    Die Unterlagen werden verteilt, und das Team wird über den Sinn und die Ziele der Prüfung informiert.
  </Step>

  <Step title="Individuelles Review">
    Jeder Gutachter bereitet sich einzeln vor, liest das Dokument intensiv und notiert potenzielle Fehlerzustände oder Fragen.
  </Step>

  <Step title="Kommunikation und Analyse">
    In einer Sitzung werden die Befunde diskutiert und bewertet. Das Team gibt eine Empfehlung ab, ob das Dokument akzeptiert oder überarbeitet werden muss.
  </Step>

  <Step title="Behebung und Berichterstattung">
    Der Autor korrigiert die Fehler. Bei formalen Reviews wird der Status der Fehler verfolgt und ein Abschlussbericht erstellt, der oft auch Metriken zur Prozessverbesserung enthält,.
  </Step>
</Steps>

## Formen

Reviews variieren je nach angestrebter Formalität und Zielsetzung.

<AccordionGroup>
  <Accordion title="Informelles Review">
    Die einfachste Form ohne vorgeschriebenen Prozess. Ein Kollege liest das Dokument gegen (Buddy-Check), was oft zu schnellem Feedback und Wissensaustausch führt.
  </Accordion>

  <Accordion title="Walkthrough">
    Der Autor leitet die Sitzung und führt die Teilnehmer durch das Arbeitsergebnis. Typische Nutzungsszenarien werden „im Trockenen“ durchgespielt, um Unklarheiten aufzudecken.
  </Accordion>

  <Accordion title="Technisches Review">
    Hier liegt der Fokus auf der Konsensbildung unter Fachexperten. Ein geschulter Moderator leitet die Sitzung, um technische Probleme zu lösen und eine gemeinsame Sicht auf das Dokument zu erreichen.
  </Accordion>

  <Accordion title="Inspektion">
    Die formalste Reviewart mit streng definierten Rollen (Moderator, Protokollant, Reviewer). Sie nutzt Checklisten und sammelt Metriken, um die Qualität des Dokuments und des Entwicklungsprozesses kontinuierlich zu optimieren.
  </Accordion>
</AccordionGroup>

## Clean-Code-Prinzipien

Reviews sind das primäre Werkzeug, um die Einhaltung der Clean-Code-Prinzipien systematisch zu prüfen und sicherzustellen.