Przegląd kodu jest opóźniony w stosunku do cyklu dostarczania / testowania

W naszym procesie Agile mamy 2-tygodniowe Sprinty. Zadania są dostarczane codziennie (codzienne wersje), a zespół testowy kończy testy natychmiast następnego dnia lub nawet tego samego dnia.

Mamy również recenzje kodu deweloperskiego, które wymagają trochę czasu (1-2 godziny), więc są zaplanowane 3 razy w tygodniu: od poniedziałku do piątku do piątku. Deweloperzy spotykają się i sugerują, jak ulepszyć / zmodyfikować kod.

Nasz problem polega na tym, że do czasu pojawienia się elementów akcji po przejrzeniu kodu większość zadań została już przetestowana. Testerzy nie chcą ponownie testować tego, co już przeszło testy. Nie dbają o wewnętrzne zmiany deweloperów.

Czy nie rozumiemy procesu zwinnego? Czy recenzje kodu są niezgodne z codziennym cyklem wydania / testu? Nie możemy przeprowadzać recenzji kodu każdego dnia, ponieważ zajmują one czas każdego.

Testerzy nie chcą ponownie testować, to tak jakby powiedzieć „koderzy nie chcą refaktoryzować”. To część pracy. Proces można przekształcić w następujący sposób: Zadania są tworzone. Kod jest generowany. Kod jest testowany. Kod jest sprawdzany. Niedoskonałości znajdują się w kodzie. Nowe zadania są tworzone w celu usunięcia tych niedoskonałości (np. Kod jest refaktoryzowany). Te nowe zadania wymagają nowych testów.

Jeśli masz zamiar przejrzeć kod w pewnym momencie, sprawdzenie go wcześniej nie jest droższe. I wygląda na to, że masz kosztowny proces testowania, więc nie chcesz testować dwa razy. Dlatego tańsze jest przejrzenie kodu przed testowaniem. Przeglądanie kodu po testowaniu nie przyspiesza pracy. Sprawia, że ​​działa wolniej i kusi cię do dostarczenia źle napisanego, ale pomyślnie przetestowanego kodu. Z czasem cały ten niezbadany kod sprawi, że praca będzie wolniejsza. Następnie bardziej wydajny konkurent dostarcza lepszy produkt przy niższych kosztach i gra się kończy.

Ponadto zautomatyzuj testowanie. Testy ręczne są już 1970 rokiem.

Jeśli masz trudności z otrzymaniem recenzji kodu w czasie, który masz przed QA, powinieneś rozważyć uczynienie recenzji kodu bardziej lekkimi, ponieważ Code Review w Agile Teams, część II, o której pisze @Dukeling.

Przekonałem się, że nawet najprostsza rzecz, którą można nazwać przeglądem kodu, przynosiła korzyści: przed zatwierdzeniem kodu (lub przekazaniem DVCS) zadzwoń do innego programisty i pomóż mu wprowadzić zmiany. Może to potrwać pięć lub dziesięć minut. Celem tego przeglądu kodu jest „Czy ma to sens dla drugiego programisty?” Nie chodziło o to, by nie dopracowywać się przy wdrażaniu projektów lub by całkowicie dostosować się do osobistych pomysłów recenzenta dotyczących tego, jak powinien być napisany. Dało to następujące korzyści:

• Poprawiona wspólna wiedza na temat działania kodu
• Złapano mylący lub potencjalnie błędny kod, ponieważ czynność wyjaśnienia kodu wystarczył, aby autor przemyślał różne rzeczy
• Pomagał stopniowo ewoluować idiomy i styl zespołu, ponieważ ułatwiało to wytłumaczenie
• Bardzo mało narzekania zespołu

Głębsze recenzje kodu absolutnie działają lepiej, aby znaleźć problemy. Ale musisz być w stanie je wykonać i działać na nich, aby uzyskać wartość. Lekki proces, który możesz wykonywać cały czas, może być bardziej pomocny niż proces wagi ciężkiej, który się odkłada lub tylko dodaje rzeczy do zaległości.

Jednym z rozwiązań tego problemu jest szybkie przejrzenie kodu przez innego uczestnika po zakończeniu historii użytkownika, aby nie było żadnych podstawowych / oczywistych błędów w kodzie.

Ale to musi się zdarzyć przed cyklem testowym. Wtedy po teście byłoby mniej zmian kodu, gdy robisz większe recenzje ze wszystkimi zespołami razem.

Z brzmienia tego wynika, że ​​testerzy nie chcą ponownie testować, ponieważ testowanie jest procesem bolesnym / kosztownym.

Automatyzacja testów zarówno przez programistów, jak i testerów jest ogromną korzyścią dla zespołów próbujących pracować w zwinny sposób. Im tańsze, łatwiejsze i bardziej reprodukowalne są twoje testy, tym więcej możesz je wykonać - i tym mniejszy opór będziesz musiał coś zmienić.

Czy wykonałeś szybki refaktor w oparciu o opinie twórców? Naciśnij duży czerwony przycisk, który uruchamia twój zestaw regresji / zadymienia i wykonaj krótką ręczną procedurę, aby sprawdzić, czy nie pojawiły się problemy wizualne. Łatwo!

Gdy znajdziesz się w takim miejscu, ponowne testowanie nie będzie uciążliwe - będzie to druga natura.