Page tree
Skip to end of metadata
Go to start of metadata

Bitte sei proaktiv mit Deinem PR, kein "hands off" (smile)

Genereller Verlauf eines Reviews

  • Review von Code und Funktion, wie weiter unten beschrieben
  • Korrektes Gitflow-Branching prüfen. Ist der PR vom richtigen Branch abgezogen und geht in den richtigen Branch? Bitte unseren Gitflow-Strategie beachten.
  • Der Reviewer kann direkt mergen, wenn es keine Zweifel/Unsicherheiten gab. Bei Unsicherheiten entweder nur kommentieren oder im Review ein zweites Review anfragen und die Person als Reviewer einladen. KEIN Squash&Merge vornehmen, Gitflow-Strategie beachten.
  • Nach dem Merge den Branch löschen, wenn keine Folgeentwicklung auf diesem Branch ersichtlich ist. Möglich wäre ein MVP PR, der erstmal raus soll aber direkt im Anschluss soll in dem PR nochmal eine Ergänzung programmiert werden, dann kann der PR bestehen bleiben.
  • Nach dem Merge/Löschen das dazugehörige Ticket bearbeiten:
    • Status des Tickets auf Done
    • Urgency des Tickets auf Normal   Feueralarme bitte so lassen, die werden automatisch "entfeueralarmt", wenn sie auf "Deployed" geschoben werden

    • Fix Version auf die Release Version stellen, in der die Entwicklung online gehen wird. Bei Hotfixes ist es meist die letzte Minor Version, bei Features die nächste Minor Version. 
    • Related Tickets ansehen, sind dort weitere Tickets verlinkt?
      • Weitere Dev-Tickets mit demselben Problem ebenso bearbeiten wie dieses
      • Helpdesk Tickets (HEL-???) kommentieren und falls der Status "Muss entwickelt werden" ist, dann auf "Lösung kommunizieren" setzen, wenn das im Helpdesk Ticket erwähnte Problem sicher gelöst wurde

Code-/Funktions-Review

Generell

  • (warning) Ticket mit Anforderer durchgehen (short Demo), i.d.R. PO; UX oder User Support
  • Code auschecken, in der IDE prüfen, testen (s.u.)
  • Dokumentation überprüfen, alle Infos vorhanden? (#Busfaktor)
  • Alle Formen von Ausgaben, Rückgaben und Fehlern überprüfen
  • Wenn Feature-Toggle: Mit und ohne Feature testen

Client

Tests

  • UI durchklicken
  • alle Pfade (unterschiedliche Eingaben/Optionen resultieren unterschiedliche Ergebnisse) testen
  • Blackhat Tests (fehlerhafte Eingaben, spezielle Sonderzeichen, kaputt machen!)
  • Firefox und ein Webkit Browser testen
  • Mobil (Smartphone und Tablet oder mobile Devtools) und Desktop testen

Server

Tests

  • Blackhat Tests (API Routen mit verschiedenen Rechten und Params via Postman testen, alle CRUDs testen)
    • keine Fehler, die zum Absturz führen




  • No labels

2 Comments

  1. Sollte das nicht mit vernünftigen Unit Tests abgedeckt werden? Und falls dies im PR noch nicht geschehen, entsprechende Tests geschrieben werden?

    1. Grundsätzlich ja. Sobald unsere Testabdeckung über 80/90% ist und für alles BlackHat Tests geschrieben wurden, entferne ich den Punkt hier aus den manuellen Review-Guidelines (wink)