Die Codeüberprüfung bleibt hinter dem Bereitstellungs- / Testzyklus zurück

In unserem Agile-Prozess haben wir zweiwöchige Sprints. Aufgaben werden täglich zugestellt (tägliche Builds), und das Testteam führt die Tests sofort am nächsten oder sogar am selben Tag durch.

Wir haben auch Dev-Code-Reviews, die einige Zeit (1-2 Stunden) benötigen, so dass sie 3-mal pro Woche stattfinden: Mo-Mi-Fr. Entwickler kommen zusammen und schlagen vor, wie Code verbessert / umgestaltet werden kann.

Unser Problem ist, dass die meisten Aufgaben bereits getestet wurden, wenn Aktionselemente nach einer Codeüberprüfung angezeigt werden. Tester möchten nicht erneut testen, was bereits ihre Tests bestanden hat. Sie kümmern sich nicht um interne Entwickleränderungen.

Verstehen wir den agilen Prozess falsch? Sind Code-Reviews mit einem täglichen Release- / Testzyklus nicht kompatibel? Wir können nicht jeden Tag Code-Reviews durchführen, da sie die Zeit aller beanspruchen.

Tester, die nicht erneut testen möchten, sind so etwas wie "Codierer, die nicht umgestalten möchten". Es ist Teil des Jobs. Der Prozess kann folgendermaßen angepasst werden: Aufgaben werden erstellt. Code wird generiert. Code wird getestet. Code wird überprüft. Unvollkommenheiten sind im Code zu finden. Es werden neue Aufgaben erstellt, um diese Mängel zu beheben (z. B. wird der Code überarbeitet). Diese neuen Aufgaben erfordern neue Tests.

Wenn Sie den Code irgendwann überprüfen möchten, ist es nicht teurer, die Überprüfung vorzeitig durchzuführen. Und es scheint, dass Sie einen teuren Testprozess haben, sodass Sie nicht zweimal testen möchten. Daher ist es günstiger, den Code vor dem Testen zu überprüfen. Das Überprüfen des Codes nach dem Testen beschleunigt die Arbeit nicht. Es wird langsamer und verleitet Sie dazu, schlecht geschriebenen, aber erfolgreich getesteten Code zu liefern. Mit der Zeit wird all dieser nicht überprüfte Code die Arbeit immer langsamer machen. Dann liefert ein effizienterer Wettbewerber ein besseres Produkt zu geringeren Kosten und das Spiel ist vorbei.

Automatisieren Sie außerdem das Testen. Manuelle Prüfung ist so 1970.

Wenn Sie Schwierigkeiten haben, Codeüberprüfungen in der Zeit vor der Qualitätssicherung durchzuführen , sollten Sie in Erwägung ziehen , Codeüberprüfungen einfacher zu gestalten , wie dies in Codeüberprüfung in agilen Teams, Teil II , beschrieben wird.

Ich fand, dass sogar die einfachste Sache, die man als Codeüberprüfung bezeichnen kann, Vorteile bringt: Bevor Sie Code schreiben (oder ein DVCS einschieben), rufen Sie einen anderen Entwickler an und führen Sie ihn durch Ihre Änderungen. Dies kann fünf oder zehn Minuten dauern. Das Ziel dieser Codeüberprüfung ist: "Ergibt dies für den anderen Entwickler einen Sinn?" Ziel war es nicht, Designimplementierungen herauszufiltern oder den persönlichen Vorstellungen des Rezensenten darüber, wie es hätte geschrieben werden sollen, vollständig zu entsprechen. Es gab diese Vorteile:

• Verbesserte gemeinsame Kenntnis der Funktionsweise des Codes
• Gefangener verwirrender oder möglicherweise fehlerhafter Code, da die Erklärung des Codes ausreichte, um den Autor zum Umdenken zu bewegen
• Hat dazu beigetragen, Team-Idiome und -Stile schrittweise zu entwickeln, da es einfacher war, Dinge zu erklären
• Sehr wenig Murren vom Team

Tiefere Codeüberprüfungen funktionieren besser, um Probleme zu finden. Aber Sie müssen in der Lage sein, sie auszuführen und danach zu handeln, um den Wert zu erhalten. Ein unkomplizierter Prozess, den Sie die ganze Zeit ausführen können, kann hilfreicher sein als ein unkomplizierter Prozess, der immer wieder aus dem Gleichgewicht gerät oder lediglich den Rückstand vergrößert.

Eine Lösung für dieses Problem besteht darin, eine schnelle Überprüfung des Codes durch einen anderen Peer durchzuführen, sobald eine User Story abgeschlossen ist, damit der Code keine grundlegenden / offensichtlichen Fehler enthält.

Dies muss jedoch vor dem Testzyklus geschehen. Dann würde es nach dem Test weniger Codeänderungen geben, wenn Sie größere Überprüfungen mit allen Teams zusammen durchführen.

Nach den Geräuschen wollen Tester nicht erneut testen, da das Testen ein schmerzhafter / teurer Prozess ist.

Die Testautomatisierung durch Entwickler und Tester ist ein großer Vorteil für Teams, die versuchen, agil zu arbeiten. Je billiger, einfacher und reproduzierbarer Ihre Tests sind, desto mehr können Sie sie ausführen - und desto weniger Widerstand können Sie gegen Änderungen leisten.

Haben Sie einen schnellen Refactor basierend auf einem Entwickler-Feedback durchgeführt? Drücken Sie die große rote Taste, die Ihre Regressions- / Rauchsuite ausführt, und führen Sie eine kurze manuelle Überprüfung durch, um festzustellen, ob möglicherweise Probleme mit der Sicht aufgetreten sind. Einfach!

Sobald Sie an einem Ort wie diesem sind, wird das erneute Testen keine lästige Pflicht sein - es wird eine zweite Natur sein.