Jak zmusić młodszych programistów do pisania testów? [Zamknięte]

Mamy młodszego programistę, który po prostu nie pisze wystarczającej liczby testów.
Muszę go narzekać co dwie godziny, "czy pisałeś testy?"
Próbowaliśmy:

• Pokazanie, że projekt staje się prostszy
• Pokazanie tego zapobiega wadom
• Robiąc to z ego mówiąc, że tylko źli programiści tego nie robią
• W ten weekend 2 członków zespołu musiało przyjść do pracy, ponieważ jego kod miał odniesienie NULL, a on go nie testował

Moja praca wymaga stabilnego kodu najwyższej jakości i zwykle wszyscy go „rozumieją” i nie ma potrzeby przepychania testów. Wiemy, że możemy zmusić go do napisania testów, ale wszyscy wiemy, że przydatne testy to te napisane, gdy się w to wkręca.

Czy znasz więcej motywacji?

To jedna z najtrudniejszych rzeczy do zrobienia. Nakłanianie ludzi do tego .

Czasami jednym z najlepszych sposobów, aby pomóc młodszym programistom „zdobyć to” i nauczyć się właściwych technik od seniorów, jest programowanie w parach.

Spróbuj tego: w nadchodzącym projekcie sparuj młodszego faceta ze sobą lub innym starszym programistą. Powinni pracować razem, na zmianę „prowadzący” (czyli ten, który pisze na klawiaturze) i „coaching” (spoglądając przez ramię kierowcy i wytykając im sugestie, błędy itp.). Może się to wydawać marnowaniem zasobów, ale znajdziesz:

1. Że ci faceci razem mogą tworzyć kod bardzo szybko i wyższej jakości.
2. Jeśli twój młodszy facet nauczy się wystarczająco dużo, aby „zdobyć to”, a starszy facet kieruje go właściwą ścieżką (np. „Ok, teraz zanim przejdziemy dalej, napiszmy na teście na tę funkcję”). Będzie to warte zasobów, które ty zobowiązuj się do tego.

Może również ktoś z twojej grupy poprowadzi prezentację Unit Testing 101 autorstwa Kate Rhodes. Myślę, że to świetny sposób na wzbudzenie entuzjazmu ludzi testami, jeśli zostaną dobrze dostarczone.

Inną rzeczą, którą możesz zrobić, jest poproszenie swoich młodych twórców o ćwiczenie Kata gry w kręgle, które pomoże im nauczyć się rozwoju sterowanego testami. Jest w Javie, ale można go łatwo dostosować do dowolnego języka.

Miej przegląd kodu przed każdym zatwierdzeniem (nawet jeśli jest to 1 minuta „Zmieniłem nazwę tej zmiennej”), aw ramach przeglądu kodu przejrzyj wszystkie testy jednostkowe.

Nie podpisuj zatwierdzenia, dopóki testy nie zostaną wprowadzone.

(Również - jeśli jego praca nie była testowana - dlaczego w pierwszej kolejności była w wersji produkcyjnej? Jeśli nie jest testowana, nie wpuszczaj jej, nie będziesz musiał pracować w weekendy)

Dla siebie zacząłem nalegać, aby każdy znaleziony i naprawiony błąd był wyrażony jako test:

1. „Hmmm, to nie w porządku…”
2. Znajdź możliwy problem
3. Napisz test, pokaż, że kod zawodzi
4. Naprawić problem
5. Pokaż, że nowy kod przechodzi
6. Zapętl, jeśli pierwotny problem nadal występuje

Staram się to robić nawet podczas pracy i kończę mniej więcej w tym samym czasie, tylko z częściowym zestawem testów już na miejscu.

(Nie mieszkam w komercyjnym środowisku programistycznym i często jestem jedynym koderem pracującym nad określonym projektem).

Wyobraź sobie, że jestem pozorowanym programistą o imieniu ... Marco. Wyobraź sobie, że nie tak dawno skończyłem szkołę i tak naprawdę nigdy nie musiałem pisać testów. Wyobraź sobie, że pracuję w firmie, która tak naprawdę nie narzuca lub nie prosi o to. DOBRZE? dobry! Teraz wyobraź sobie, że firma przechodzi na używanie testów i próbują przekonać mnie do tego. Podam nieco złośliwą reakcję na wspomniane do tej pory pozycje, tak jakbym nie prowadziła żadnych badań na ten temat.

Zacznijmy od twórcy:

Pokazanie, że projekt staje się prostszy.

Jak można pisać więcej, uprościć sprawę. Musiałbym teraz uważać na zdobywanie większej liczby przypadków itp. To sprawia, że ​​jest to bardziej skomplikowane, jeśli o mnie chodzi. Podaj mi solidne szczegóły.

Pokazanie tego zapobiega wadom.

Wiem to. Dlatego nazywa się je testami. Mój kod jest dobry i sprawdziłem go pod kątem problemów, więc nie wiem, gdzie te testy mogłyby pomóc.

Robiąc to z ego mówiąc, że tylko źli programiści tego nie robią.

Och, więc myślisz, że jestem złym programistą tylko dlatego, że nie robię tak często używanych testów. Jestem obrażony i pozytywnie zły na Ciebie. Wolę mieć pomoc i wsparcie niż słowa.

@ Justin Standard : Na początku nowego propect sparuj młodszego faceta ze sobą lub innym starszym programistą.

Och, to jest tak ważne, że środki zostaną wydane na upewnienie się, że widzę, jak się wszystko robi, i otrzymam pomoc w tym, jak to się robi. Jest to pomocne i mogę po prostu zacząć robić to częściej.

@ Justin Standard : Przeczytaj prezentację dotyczącą testów jednostkowych 101 autorstwa Kate Rhodes.

Ach, to była ciekawa prezentacja, która sprawiła, że ​​pomyślałem o testowaniu. Uderzyło to w niektóre punkty, które powinienem rozważyć, i mogło trochę wpłynąć na moje poglądy.

Chciałbym zobaczyć bardziej atrakcyjne artykuły i inne narzędzia, które pomogą mi w zrozumieniu, że to właściwy sposób robienia rzeczy.

@ Dominic Cooney : Poświęć trochę czasu i podziel się technikami testowania.

Ach, to pomaga mi zrozumieć, czego się ode mnie oczekuje, jeśli chodzi o techniki, i umieszcza w moim worku wiedzy więcej przedmiotów, których mógłbym użyć ponownie.

@ Dominic Cooney : odpowiadaj na pytania, przykłady i książki.

Posiadanie osoby wskazującej (ludzi), która odpowie na pytanie, jest pomocne, może zwiększyć prawdopodobieństwo, że spróbuję. Dobre przykłady są świetne i daje mi to do czego dążyć i do czego szukać odniesienia. Książki, które są bezpośrednio związane z tym zagadnieniem, stanowią świetne źródło informacji.

@ Adam Hayle : Surprise Review.

Powiedz co, stworzyłeś coś, na co nie jestem przygotowany. Czuję się z tym nieswojo, ale zrobię co w mojej mocy. Będę teraz przestraszony i lekko przestraszony przed ponownym pojawieniem się, dziękuję. Jednak taktyka zastraszania mogła zadziałać, ale ma swój koszt. Jeśli jednak nic innego nie działa, może to być tylko potrzeba.

@ Rytmis : Elementy są uznawane za wykonane tylko wtedy, gdy mają przypadki testowe.

Och, ciekawe. Widzę, że naprawdę muszę to teraz zrobić, w przeciwnym razie niczego nie dokończę. To ma sens.

@ jmorris : Get Rid / Sacrifice.

spojrzenia, spojrzenia, spojrzenia - Jest szansa, żebym się nauczył, a przy wsparciu i pomocy mogę stać się bardzo ważną i funkcjonalną częścią zespołów. To jest teraz jeden z moich utrudnień, ale to nie potrwa długo. Jednak jeśli po prostu tego nie rozumiem, rozumiem, że pójdę. Myślę, że to zrozumiem.

W końcu wsparcie mojego zespołu odgrywa w tym wszystkim dużą rolę. Zawsze mile widziane jest posiadanie czasu, aby ktoś mi pomógł i wyprowadził mnie z dobrych nawyków. Wtedy posiadanie dobrej sieci wsparcia byłoby świetne. Zawsze byłoby mile widziane, gdyby ktoś przyszedł później kilka razy i przejrzał kod, aby zobaczyć, jak wszystko przebiega, nie w recenzji jako takiej, ale bardziej jako przyjazna wizyta.

Rozumowanie, przygotowywanie, nauczanie, kontynuacja, wsparcie.

Zauważyłem, że wielu programistów widzi wartość testowania na racjonalnym poziomie. Jeśli słyszałeś takie rzeczy jak „tak, wiem, że powinienem to sprawdzić, ale naprawdę muszę to zrobić szybko”, to wiesz, o co mi chodzi. Jednak na poziomie emocjonalnym czują, że coś zrobili tylko wtedy, gdy piszą prawdziwy kod.

Zatem celem powinno być jakoś uświadomienie im, że testowanie jest w rzeczywistości jedynym sposobem mierzenia, kiedy coś jest „zrobione”, a tym samym dać im wewnętrzną motywację do pisania testów.

Obawiam się, że to dużo trudniejsze niż powinno być. Usłyszysz wiele wymówek w rodzaju „Bardzo mi się spieszy, przepiszę to później, a potem dodam testy” - i oczywiście dalsze działania nigdy się nie zdarzają, ponieważ, co zaskakujące, „re tak zajęty w przyszłym tygodniu .

Oto, co bym zrobił:

• Pierwszy raz ... "będziemy robić ten projekt razem. Mam zamiar napisać testy, a ty napiszesz kod. Zwróć uwagę, jak piszę testy, bo tak to robimy tutaj i tego właśnie będę się po tobie spodziewać ”.

• Następnie… „Gotowe? Świetnie! Najpierw spójrzmy na testy, które napędzają Twój rozwój. O, żadnych testów? Daj mi znać, kiedy to się stanie, a my przełożymy przeglądanie Twojego kodu. Jeśli potrzebujesz pomocy w sformułowaniu testów, daj mi znać, a pomogę Ci ”.

On już to robi. Naprawdę. Po prostu tego nie zapisuje. Nieprzekonany? Zobacz, jak przechodzi przez standardowy cykl rozwoju:

• Napisz kawałek kodu
• Skompiluj to
• Biegnij, żeby zobaczyć, co robi
• Napisz następny fragment kodu

Krok # 3 to test. On już przeprowadza testy, po prostu robi to ręcznie. Zadaj mu pytanie: „Skąd wiesz jutro, że kod z dnia dzisiejszego nadal działa?” Odpowie: „To taka mała ilość kodu!”

Zapytaj: „Co powiesz na przyszły tydzień?”

Kiedy nie ma odpowiedzi, zapytaj: „Jak chciałbyś, aby Twój program informował Cię, kiedy zmiana przerywa coś, co zadziałało wczoraj?”

O to właśnie chodzi w automatycznym testowaniu jednostkowym.

Jako młodszy programista wciąż próbuję nabrać zwyczaju pisania testów. Oczywiście nie jest łatwo nabrać nowych nawyków, ale myśląc o tym, co sprawi, że to zadziała, muszę dać +1 komentarzom dotyczącym recenzji kodu i coachingu / programowania w parach.

Warto też podkreślić długoterminowy cel testowania: upewnienie się, że to, co działało wczoraj, nadal działa dziś, w przyszłym tygodniu i w przyszłym miesiącu. Mówię to tylko dlatego, że przeglądając odpowiedzi, nie zauważyłem, że zostały one wymienione.

Robiąc przegląd kodu (jeśli zdecydujesz się to zrobić), upewnij się, że twój młody programista wie, że nie chodzi o to, aby go poniżyć, ale o ulepszenie kodu. Ponieważ w ten sposób jego pewność siebie jest mniej narażona na uszkodzenie. I to jest ważne. Z drugiej strony, tak samo jest z wiedzą, jak mało wiesz.

Oczywiście tak naprawdę nic nie wiem. Mam jednak nadzieję, że słowa były przydatne.

Edycja: [ Justin Standard ]

Nie poniżaj się, to, co masz do powiedzenia, jest w zasadzie słuszne.

Jeśli chodzi o recenzje kodu: przekonasz się, że nie tylko młodszy programista nauczy się w trakcie tego procesu, ale także recenzenci. Każdy uczestnik przeglądu kodu uczy się, czy jest to proces oparty na współpracy.

Szczerze mówiąc, jeśli masz do wprowadzenia że wiele wysiłku w uzyskanie mu coś zrobić, to być może trzeba pogodzić się z myślą, że może po prostu nie być dobrym rozwiązaniem dla zespołu, a może trzeba iść. To niekoniecznie oznacza zwolnienie go ... może to oznaczać znalezienie innego miejsca w firmie, w którym jego umiejętności są bardziej odpowiednie. Ale jeśli nie ma innego miejsca ... wiesz, co robić.

Zakładam, że jest też całkiem nowym pracownikiem (<1 rok) i prawdopodobnie niedawno skończył szkołę ... w takim przypadku może nie być przyzwyczajony do tego, jak rzeczy działają w środowisku korporacyjnym. Takie rzeczy większości z nas mogłyby ujść na sucho na studiach.

Jeśli tak jest, jedną rzeczą, którą znalazłem, jest coś w rodzaju „zaskakującej recenzji nowego pracownika”. Nie ma znaczenia, jeśli nigdy wcześniej tego nie robiłeś ... on tego nie będzie wiedział. Po prostu usiądź i powiedz mu, że przejrzysz jego występ i pokażesz mu prawdziwe liczby ... weź swój normalny arkusz recenzji (masz formalny proces przeglądu, prawda?) I zmień nagłówek, jeśli chcesz, tak to wygląda urzędnik i pokaż mu, gdzie stoi. Jeśli pokażesz mu w bardzo formalnym otoczeniu, że nie robienie testów negatywnie wpływa na jego ocenę wyników, a nie tylko „dręczenie” go tym, miejmy nadzieję, że zrozumie. Musisz mu pokazać, że jego działania faktycznie na niego wpłyną, niezależnie od tego, czy będzie to opłacalne, czy w inny sposób.

Wiem, możesz trzymać się z daleka od robienia tego, ponieważ nie jest to oficjalne ... ale myślę, że masz rozsądek, aby to zrobić i prawdopodobnie będzie to o wiele tańsze niż konieczność zwolnienia go i zwerbowania kogoś nowego.

Jako młodszy programista pomyślałem, że ujawnię, jak to było, gdy znalazłem się w podobnej sytuacji, jak twój młodszy programista.

Kiedy po raz pierwszy wyszedłem z uniwersytetu, stwierdziłem, że poważnie mnie to uniemożliwiło radzenie sobie z prawdziwym światem. Tak, znałem podstawy JAVA i trochę filozofii (nie pytaj), ale to wszystko. Kiedy po raz pierwszy dostałem pracę, było to co najmniej zniechęcające. Powiem ci, że byłem prawdopodobnie jednym z największych kowbojów w okolicy, zhakowałbym razem małą poprawkę błędu / algorytm bez komentarzy / testów / dokumentacji i wysłałbym to za drzwi.

Miałem szczęście być pod okiem życzliwego i bardzo cierpliwego starszego programisty. Na szczęście dla mnie postanowił usiąść ze mną i spędzić 1-2 tygodnie na przeglądaniu mojego zhakowanego wspólnego kodu. Wyjaśniłby, gdzie popełniłem błąd, subtelniejsze punkty c i wskaźniki (chłopak to mnie zdezorientował!). Udało nam się napisać całkiem przyzwoitą klasę / moduł w około tydzień. Wszystko, co mogę powiedzieć, to to, że gdyby starszy programista nie zainwestował czasu, aby pomóc mi na właściwej ścieżce, prawdopodobnie nie wytrzymałbym zbyt długo.

Na szczęście dwa lata później mam nadzieję, że niektórzy z moich kolegów mogą nawet uznać mnie za przeciętnego programistę.

Zdobądź punkty do domu

1. Większość uniwersytetów bardzo źle przygotowuje studentów do realnego świata
2. Programowanie w parach naprawdę mi pomogło. Nie chcę przez to powiedzieć, że pomoże wszystkim, ale dla mnie zadziałało.

Przypisz je do projektów, które nie wymagają „stabilnego kodu najwyższej jakości”, jeśli o to Ci chodzi i pozwól jr. programista nie działa. Niech to oni „przychodzą w weekend” i naprawiają błędy. Zjedz dużo obiadów i porozmawiaj o praktykach tworzenia oprogramowania (nie wykładach, ale dyskusjach). Z czasem zdobędą i rozwiną najlepsze praktyki wykonywania powierzonych im zadań.

Kto wie, może nawet wymyślą coś lepszego niż techniki, których obecnie używa twój zespół.

Jeśli młodszy programista lub ktokolwiek inny nie widzi wartości w testowaniu, ciężko będzie go do tego zmusić… kropka.

Zmusiłbym młodszego programistę do poświęcenia weekendu na naprawienie błędu. Jego działania (lub ich brak) nie wpływają na niego bezpośrednio. Zaznacz też, że nie zobaczy postępów i / lub podwyżek płac, jeśli nie poprawi swoich umiejętności w testowaniu.

W końcu, nawet z całą twoją pomocą, zachętą, mentorem, może nie pasować do twojego zespołu, więc pozwól mu odejść i poszukaj kogoś, kto to dostanie.

Drugi komentarz RodeoClown na temat przeglądu kodu przy każdym zatwierdzeniu. Kiedy zrobi to kilka razy, przyzwyczai się do testowania różnych rzeczy.

Nie wiem jednak, czy musisz blokować takie zatwierdzenia. W moim miejscu pracy każdy ma wolne zobowiązanie do wszystkiego, a wszystkie komunikaty SVN o zmianach (z różnicami) są wysyłane e-mailem do zespołu.

Uwaga: naprawdę potrzebujesz dodatku colour-diffs do thunderbirda, jeśli planujesz to zrobić.

Mój szef lub ja (dwaj „starsi” programiści) skończymy czytać zmiany, a jeśli jest coś takiego jak „zapomniałeś dodać testy jednostkowe”, po prostu piszemy e-mail lub rozmawiamy z tą osobą, wyjaśniając, dlaczego potrzebne testy jednostkowe lub cokolwiek innego. Zachęcamy wszystkich do przeczytania commits, ponieważ jest to świetny sposób na zobaczenie, co się dzieje, ale młodsi deweloperzy nie komentują zbyt wiele.

Możesz pomóc zachęcić ludzi do tego, by przyzwyczaić się do tego, okresowo mówiąc takie rzeczy jak „Hej, bob, czy widziałeś to zobowiązanie, które zrobiłem dziś rano. Znalazłem tę fajną sztuczkę, w której możesz zrobić bla, bla, cokolwiek, przeczytaj zatwierdzenie i zobacz jak to działa!"

NB: Mamy 2 "starszych" programistów i 3 młodszych. To może się nie skalować lub może być konieczne dostosowanie procesu przy większej liczbie programistów.

1. Uczyń pokrycie kodu częścią recenzji.
2. Uczyń „napisanie testu, który ujawni błąd” jako warunek wstępny naprawy błędu.
3. Wymagaj określonego poziomu pokrycia, zanim kod będzie można zarejestrować.
4. Znajdź dobrą książkę o programowaniu sterowanym testami i wykorzystaj ją, aby pokazać, jak testowanie może przyspieszyć rozwój.

Mnóstwo psychologii i pomocnych technik „mentoringowych”, ale, szczerze mówiąc, sprowadza się to po prostu do „pisania testów, jeśli chcesz jutro nadal mieć pracę”.

Możesz to sformułować w dowolny sposób, który uważasz za odpowiedni, szorstki lub miękki, to nie ma znaczenia. Ale faktem jest, że programiści nie są opłacani za to, by po prostu poskładać kod i sprawdzić go - płacą im za staranne złożenie kodu, następnie złożenie testów, następnie przetestowanie kodu, NASTĘPNIE sprawdzenie całości. (Przynajmniej tak to brzmi z twojego opisu.)

Dlatego jeśli ktoś odmówi wykonywania swojej pracy, wyjaśnij mu, że może jutro zostać w domu, a ty zatrudnisz kogoś, kto BĘDZIE wykonywał tę pracę.

Ponownie, możesz zrobić to wszystko delikatnie, jeśli uważasz, że jest to konieczne, ale wielu ludzi potrzebuje po prostu dużego, mocnego uderzenia w życie w prawdziwym świecie i wyświadczyłbyś im przysługę, dając im to.

Powodzenia.

Zmień na chwilę zakres jego pracy, aby zajmować się wyłącznie pisaniem testów i utrzymywaniem testów. Słyszałem, że wiele firm robi to dla nowych, niedoświadczonych ludzi od jakiegoś czasu, kiedy zaczynają.

Dodatkowo, rzuć wyzwanie, gdy on jest w tej roli: Napisz testy, które a) zakończą się niepowodzeniem w obecnym kodzie a) spełnią wymagania oprogramowania. Miejmy nadzieję, że spowoduje to, że stworzy solidne i dokładne testy (ulepszając projekt) i sprawi, że będzie lepszy w pisaniu testów na czas ponownej integracji z rdzeniem rozwoju.

edit> spełnia wymagania oprogramowania, co oznacza, że ​​nie pisze on tylko testów, aby celowo złamać kod, gdy kod nigdy nie zamierzał lub nie musiał uwzględniać tego przypadku testowego.

Jeśli twój kolega nie ma doświadczenia w pisaniu testów, być może ma on trudności z testowaniem wykraczającym poza proste sytuacje, co objawia się nieodpowiednim testowaniem. Oto, czego chciałbym spróbować:

• Poświęć trochę czasu i podziel się technikami testowania, takimi jak wstrzykiwanie zależności, szukanie skrajnych przypadków itp. Ze swoim współpracownikiem.
• Zaproponuj odpowiedź na pytania dotyczące testowania.
• Przeprowadź przez chwilę przegląd kodu testów. Poproś współpracownika, aby przejrzał Twoje zmiany, które są przykładem dobrych testów. Spójrz na ich komentarze, aby zobaczyć, czy naprawdę czytają i rozumieją Twój kod testowy.
• Jeśli istnieją książki, które szczególnie dobrze pasują do filozofii testowania Twojego zespołu, daj jej egzemplarz. Może pomóc, jeśli opinia o przeglądzie kodu lub dyskusje odwołują się do książki, tak aby miał wątek do przeczytania i śledzenia.

Nie podkreślałbym szczególnie czynnika wstydu / winy. Warto zwrócić uwagę, że testowanie jest szeroko przyjętą dobrą praktyką, a pisanie i utrzymywanie dobrych testów to profesjonalna uprzejmość, więc Twoi koledzy z zespołu nie muszą spędzać weekendów w pracy, ale nie będę omawiać tych punktów.

Jeśli naprawdę potrzebujesz „stać się twardym”, zastosuj bezstronny system; nikt nie lubi czuć się wyróżniony. Na przykład Twój zespół może wymagać kodu, aby utrzymać określony poziom pokrycia testami (można grać, ale przynajmniej można je zautomatyzować); wymagać nowego kodu, aby mieć testy; wymagać od recenzentów rozważenia jakości testów podczas przeprowadzania recenzji kodu; i tak dalej. Stworzenie tego systemu powinno wynikać z konsensusu zespołu. Jeśli ostrożnie moderujesz dyskusję, możesz odkryć inne przyczyny, dla których testy Twojego kolegi nie są tym, czego oczekujesz.

Nauczanie go jest obowiązkiem jego mentora. Jak dobrze uczysz go / ją JAK testować. Programujesz z nim w parze? Junior najprawdopodobniej nie wie, JAK ustawić dobry test dla xyz.

Jako Junior świeżo upieczony zna wiele pojęć. Jakaś technika. Jakieś doświadczenie. Ale w końcu wszystko Junior jest POTENCJAŁEM. Prawie każda funkcja, nad którą pracują, będzie coś nowego, czego nigdy wcześniej nie robili. Jasne, że Junior mógł wykonać prosty wzór stanu dla projektu w klasie, otwierając i zamykając „drzwi”, ale nigdy nie zastosował wzorców w prawdziwym świecie.

Będzie tak dobry, jak dobrze będziesz uczyć. Gdyby potrafili „Po prostu to dostać”, czy myślisz, że zajęliby w pierwszej kolejności pozycję juniora?

Z mojego doświadczenia wynika, że ​​juniorzy są zatrudniani i mają prawie taką samą odpowiedzialność jak seniorzy, ale otrzymują po prostu niższe wynagrodzenie, a następnie są ignorowani, gdy zaczynają słabnąć. Wybacz mi, jeśli wyglądam na zgorzkniałą, bo jestem.

@ jsmorris

Kiedyś starszy programista i „architekt” zganili mnie i testera (to była moja pierwsza praca poza college'em) w e-mailu za to, że nie spóźniłem się do późna i skończyłem tak „łatwe” zadanie poprzedniego wieczoru. Byliśmy przy tym przez cały dzień i zakończyliśmy o 19:00, biłem się od 11 rano przed lunchem i co najmniej dwa razy namawiałem każdego członka naszego zespołu o pomoc.

Odpowiedziałem i powiedziałem zespołowi: „Byłem rozczarowany od miesiąca. Nigdy nie otrzymałem pomocy od zespołu. Będę w kawiarni po drugiej stronie ulicy, jeśli będziesz mnie potrzebować. Jestem przepraszam, nie mogłem debugować 12-parametrowej metody 800 linii, od której prawie wszystko zależy. "

Po godzinnym ochłodzeniu się w kawiarni wróciłem do biura, złapałem swoje bzdury i wyszedłem. Po kilku dniach zadzwonili do mnie z pytaniem, czy przyjdę, powiedziałem, że tak, ale miałem rozmowę kwalifikacyjną, może jutro.

- Więc rzuciłeś?

W repozytorium źródłowym: używaj haków przed każdym zatwierdzeniem (na przykład hak przed zatwierdzeniem dla SVN)

W tym zaczepie sprawdź, czy istnieje co najmniej jeden przypadek użycia dla każdej metody. Użyj konwencji dla organizacji testów jednostkowych, którą można łatwo wymusić za pomocą haka przed zatwierdzeniem.

Na serwerze integracyjnym skompiluj wszystko i regularnie sprawdzaj pokrycie testów za pomocą narzędzia pokrycia testów. Jeśli pokrycie testu nie wynosi 100% dla kodu, zablokuj wszelkie zatwierdzenie dewelopera. Powinien wysłać Ci przypadek testowy, który obejmuje 100% kodu.

Tylko automatyczne sprawdzenia mogą dobrze skalować projekt. Nie da się wszystkiego sprawdzić ręcznie.

Deweloper powinien mieć możliwość sprawdzenia, czy jego przypadki testowe obejmują 100% kodu. W ten sposób, jeśli nie popełni w 100% przetestowanego kodu, jest to jego własna wina, a nie błąd typu „ups, przepraszam, zapomniałem”.

Pamiętaj: ludzie nigdy nie robią tego, czego oczekujesz, zawsze robią to, co sprawdzasz.

Po pierwsze, jak zauważa większość respondentów, jeśli facet nie widzi wartości w testowaniu, niewiele można z tym zrobić, a już wskazałeś, że nie możesz go zwolnić. Jednak porażka nie wchodzi w grę, więc co z kilkoma rzeczami, które możesz zrobić?

Jeśli Twoja organizacja jest wystarczająco duża, aby mieć ponad 6 programistów, zdecydowanie zalecam posiadanie działu kontroli jakości (nawet jeśli jest to tylko jedna osoba na początek). Najlepiej byłoby, gdyby stosunek 1 testera do 3-5 programistów. Rzecz w programistach jest taka, że ​​... są programistami, a nie testerami. Nie rozmawiałem jeszcze z programistą, który został formalnie nauczony prawidłowych technik zapewniania jakości.

Większość organizacji popełnia fatalny błąd, przypisując role testerów nowozatrudnionemu, osobie z NAJMNIEJSZYM kontaktem z Twoim kodem - najlepiej byłoby, gdyby starsi programiści zostali przeniesieni do roli QA, ponieważ mają doświadczenie w kodzie i (miejmy nadzieję) rozwinęli szósty zmysł wyczuwania zapachów kodu i punktów awarii, które mogą się pojawić.

Co więcej, programista, który popełnił błąd, prawdopodobnie nie znajdzie usterki, ponieważ zwykle nie jest to błąd składniowy (są one wychwytywane podczas kompilacji), ale błąd logiczny - i ta sama logika działa, gdy piszą testuj tak, jak podczas pisania kodu. Nie pozwól, aby osoba, która opracowała kod, testowała ten kod - znajdzie mniej błędów niż ktokolwiek inny.

W twoim przypadku, jeśli możesz sobie pozwolić na przekierowany wysiłek w pracy, uczyń tego nowego faceta pierwszym członkiem zespołu kontroli jakości. Niech przeczyta „Testowanie oprogramowania w prawdziwym świecie: ulepszanie procesu”, ponieważ oczywiście będzie potrzebował przeszkolenia w nowej roli. Jeśli mu się to nie spodoba, zrezygnuje, a twój problem nadal zostanie rozwiązany.

Nieco mniej mściwym podejściem byłoby pozwolenie tej osobie na zrobienie tego, w czym jest dobra (zakładam, że ta osoba została zatrudniona, ponieważ faktycznie jest kompetentna w części programistycznej pracy) i zatrudnienie testera lub dwóch do wykonania testów ( Studenci uniwersytetów często mają warunki dotyczące praktyki lub współpracy, chcieliby się ujawnić i są tani)

Uwaga boczna: Ostatecznie będziesz chciał, aby zespół kontroli jakości zgłosił się do dyrektora kontroli jakości lub przynajmniej nie do menedżera programisty, ponieważ przekazanie zespołu kontroli jakości raportu do menedżera, którego głównym celem jest ukończenie produktu, jest konfliktem między zainteresowanie.

Jeśli Twoja organizacja ma mniej niż 6 osób lub nie możesz uciec z utworzeniem nowego zespołu, polecam programowanie w parach (PP). Nie jestem całkowitym konwerterem wszystkich ekstremalnych technik programowania, ale zdecydowanie wierzę w programowanie w parach. Jednak obaj członkowie sparowanego zespołu programistów muszą być oddani, inaczej po prostu nie działa. Muszą przestrzegać dwóch zasad: inspektor musi w pełni zrozumieć, co jest zakodowane na ekranie lub poprosić programistę o wyjaśnienie; koder może zakodować tylko to, co potrafi wyjaśnić - żadne „zobaczysz”, „zaufaj mi” ani machanie ręką nie będą tolerowane.

Polecam PP tylko wtedy, gdy twój zespół jest w stanie to zrobić, ponieważ, podobnie jak testowanie, żadna ilość wiwatowania lub grożenia nie przekona kilku pełnych ego introwertyków do współpracy, jeśli nie czują się komfortowo. Jednak stwierdzam, że między wyborem pisania szczegółowych specyfikacji funkcjonalnych i przeglądaniem kodu a programowaniem w parach, PP zazwyczaj wygrywa.

Jeśli PP nie jest dla Ciebie, to TDD jest najlepszym rozwiązaniem, ale tylko wtedy, gdy jest brane dosłownie. Programowanie sterowane testami oznacza, że ​​piszesz testy NAJPIERW, uruchamiasz testy, aby udowodnić, że faktycznie zawodzą, a następnie piszesz najprostszy kod, aby działał. Kompromisem jest to, że teraz (powinieneś) mieć kolekcję tysięcy testów, które są również kodem i są tak samo prawdopodobne, jak kod produkcyjny, który zawiera błędy. Będę szczery, nie jestem wielkim fanem TDD, głównie z tego powodu, ale działa to dla wielu programistów, którzy wolą pisać skrypty testowe niż dokumenty przypadków testowych - trochę testowania jest lepsze niż żadne. Połącz TDD z PP, aby uzyskać większe prawdopodobieństwo pokrycia testu i mniej błędów w skrypcie.

Jeśli wszystko inne zawiedzie, poproś programistów o równoważność słoika przekleństw - za każdym razem, gdy programista zepsuje kompilację, musi włożyć 20, 50, 100 USD (cokolwiek jest umiarkowanie bolesne dla twojego personelu) do słoika, który trafia do twojego ulubionego ( zarejestrowana!). Dopóki nie zapłacą, unikaj ich :)

Odkładając na bok żarty, najlepszym sposobem nakłonienia programisty do pisania testów jest nie pozwalanie mu programować. Jeśli chcesz programistę, zatrudnij programistę - Jeśli chcesz testów, zatrudnij testera. Zaczynałem jako młodszy programista 12 lat temu, przeprowadzając testy, które zmieniły się w moją ścieżkę kariery i nie zamieniłbym tego na nic. Solidny dział kontroli jakości, który jest odpowiednio pielęgnowany i ma uprawnienia i uprawnienia do ulepszania oprogramowania, jest tak samo cenny, jak programiści piszący oprogramowanie.

To może być trochę bez serca, ale sposób, w jaki opisujesz sytuację, brzmi tak, jakbyś musiał zwolnić tego gościa. Lub przynajmniej wyjaśnij to jasno: odmowa przestrzegania praktyk związanych z rozwojem domu (w tym pisania testów) i sprawdzanie błędnego kodu, który inni ludzie muszą wyczyścić, w końcu spowoduje zwolnienie.

Głównym powodem, dla którego młodsi inżynierowie / programiści nie poświęcają dużo czasu na projektowanie i wykonywanie skryptów testowych, jest to, że większość certyfikatów CS nie wymaga tego w dużym stopniu, więc inne obszary inżynierii są dalej omawiane w programach uniwersyteckich, takich jak wzorce projektowe.

Z mojego doświadczenia wynika, że ​​najlepszym sposobem na przyzwyczajenie młodszych profesjonalistów jest wyraźne uczynienie go częścią procesu. Oznacza to, że podczas szacowania czasu, jaki powinna zająć iteracja, czas projektowania, pisania i / lub wykonania przypadków powinien być uwzględniony w tym oszacowaniu czasu.

Wreszcie, przegląd projektu skryptu testowego powinien być częścią przeglądu projektu, a rzeczywisty kod powinien zostać przejrzany w przeglądzie kodu. To sprawia, że ​​programista jest odpowiedzialny za wykonanie właściwego testowania każdej linii kodu, który pisze, a starszy inżynier i współpracownicy są odpowiedzialni za udzielenie informacji zwrotnej i wskazówek dotyczących kodu i napisanego testu.

Opierając się na twoim komentarzu: „Pokazanie, że projekt staje się prostszy”, zakładam, że ćwiczysz TDD. Przeprowadzenie przeglądu kodu po fakcie nie zadziała. Cała sprawa dotycząca TDD polega na tym, że jest to projekt, a nie filozofia testowania. Jeśli nie napisał testów jako części projektu, nie odniesiesz wiele korzyści z pisania testów po fakcie - zwłaszcza od młodszego programisty. Skończy się na tym, że przegapi wiele przypadków narożnych, a jego kod nadal będzie kiepski.

Najlepszym rozwiązaniem jest posiadanie bardzo cierpliwego starszego programisty, który będzie z nim siedział i programował w parach. I po prostu kontynuuj, aż się nauczy. Lub się nie uczy, w takim przypadku musisz ponownie przydzielić go do zadania, do którego jest lepiej przystosowany, ponieważ w końcu frustrujesz swoich prawdziwych programistów.

Nie każdy ma taki sam poziom talentu i / lub motywacji. Zespoły deweloperskie, nawet te zwinne, składają się z osób z „Drużyny A” i osób z Zespołu „B”. Członkowie A-Team są tymi, którzy projektują rozwiązanie, piszą nietrywialny kod produkcyjny i komunikują się z właścicielami firm - cała praca, która wymaga nieszablonowego myślenia. Zespół B zajmuje się takimi sprawami, jak zarządzanie konfiguracją, pisanie skryptów, naprawianie ułomnych błędów i wykonywanie prac konserwacyjnych - wszystko to ma ścisłe procedury, które mają niewielkie konsekwencje w przypadku awarii.