Jak przekonać kierownictwo do „inwestowania” w testy jednostkowe?

45

Jak przekonałeś swojego kierownika, aby pozwolił ci na test jednostkowy?

Przez „użycie” mam na myśli pozwolenie na rozwój, odprawę do kontroli źródła i utrzymanie testów jednostkowych w czasie itp.

Typowe zastrzeżenia kierownictwa to:

  1. Klient nie zapłacił za testy jednostkowe
  2. Projekt nie przewiduje czasu na testy jednostkowe
  3. Dług techniczny? Jaki dług techniczny?

Czy znasz inne zastrzeżenia? Jakie były twoje odpowiedzi?

Z góry dziękuję!

louisgab
źródło
6
Artofunittesting.com zawiera cały rozdział na ten temat.
StuperUser
6
Nie mieszaj testów z TDD, PROSZĘ ! To sprawia, że ​​ludzie myślą, że nie potrzebują testów, chyba że robią TDD!
P Shved
1
Ludzie, którzy potrzebują przekonania, są bardziej niż przekonujący. Rozważ swój scenariusz jako utraconą przyczynę.
Mark Canlas
@Pavel, na początku myślałem, że robisz dupki, ale masz rację. Chcę mieć „pozwolenie” na test jednostkowy, kropka. TDD to moja własna sprawa.
louisgab,
6
dlaczego czujesz potrzebę uzyskania pozwolenia na weryfikację działania kodu zgodnie z oczekiwaniami?
Jaap

Odpowiedzi:

25

Ostatnio natknąłem się na ten problem, gdy klient był przy naszej metodyce, ale wyższe kierownictwo dowiedziało się, że programiści spędzają czas na testowaniu, a nie rozwijają się i martwią się tym - w końcu mieli do dyspozycji osoby odpowiedzialne za kontrolę jakości! Blogowałem o tym, jak sobie z tym poradziłem:

http://practicalagility.com/show-them-the-numbers-its-results-that-matter/

Podsumowując, porównałem nasze szacunkowe godziny z faktycznymi godzinami dla projektu, a następnie porównałem nasz wskaźnik wad z współczynnikiem wad innych zespołów. W naszym przypadku liczby te wypadły korzystnie i nie było już żadnych obaw.

Mój wniosek oparty na tym doświadczeniu jest następujący:

... najlepszym sposobem, aby przekonać każdego, że twoje podejście do robienia czegoś jest praktyczne i pragmatyczne, to zrobić to i porównać z innymi podejściami. Ludziom nie zależy na dogmatach ani na tym, dlaczego uważasz, że coś powinno być najlepszym sposobem. Tylko pokazując ludziom liczby i mierząc skuteczność swojego podejścia, możesz naprawdę pokazać, że twoje praktyki są skuteczne.

Przy innych projektach współpracowaliśmy z programistami klientów, którzy nie stworzyli testów jednostkowych ani nie przeprowadzili TDD i musieliśmy utrzymać testy, które przełamują. Jednak bardzo łatwo jest sprzedać podejście TDD tym programistom klientów, kiedy możesz im powiedzieć, co złamali w kodzie, zanim się dowiedzą!

Więc w twoim przypadku zrobiłbym to ukradkiem, jeśli to konieczne (być może jest mały obszar kodu, który możesz zacząć testować, że często się zmienia lub za który jesteś odpowiedzialny), ale pamiętaj o swoich liczbach - co to jest wysiłek na stworzenie swoich testów? Jaka jest liczba wad? Jak to się ma do innych projektów / członków zespołu?

Moim zdaniem nikt nie powinien pytać o zgodę ani przeprosić za to, że chce właściwie wykonywać swoją pracę, a każdy profesjonalny programista powinien próbować testować swój kod za pomocą testów automatycznych, tam gdzie jest to możliwe i praktyczne. Mam nadzieję, że w twoim przypadku są to obie te rzeczy. Powodzenia!

Paddyslacker
źródło
Dzięki za odpowiedzi. Próbowałem link, ale wygląda na uszkodzony. Myślę, że chętnie bym go przeczytał, gdyby był dostępny.
Joe J
Joe, przepraszam za martwy link. Opublikowałem to na moim osobistym blogu, więc link powinien już działać.
Paddyslacker,
2
To dobra odpowiedź, ale nie każdy może łatwo porównać to, co robi z jakimś innym projektem. Nie pamiętam, gdzie go przeczytałem, ale najbardziej przekonującym argumentem dla przedsiębiorcy, którego widziałem, było porównanie testów jednostkowych z księgowością podwójnego zapisu. Naiwne dwukrotne wykonywanie liczb to strata czasu. Ale każdy, kto wie coś o rachunkowości, uznałby wykonanie jednej strony książek za niewybaczalnie nieodpowiedzialne zaniedbanie obowiązków. Testy jednostkowe to rozwój analogiczny do księgowości z podwójnym wpisem.
JimmyJames,
@JimmyJames, zgadzam się, że nie zawsze możesz porównać do innego projektu, i zgadzam się z twoją analogią dotyczącą podwójnej księgowości. Myślę, że jeśli zaczynasz używać testów jednostkowych na istniejącej bazie kodu bez testów, możesz porównać częstość defektów bazy kodu i inne mierniki między częścią objętą testami jednostkowymi a odkrytym kodem, aby mieć jakieś prawdziwe dane do utworzenia kopii zapasowej twoje podejście też.
Paddyslacker
@Paddyslacker Nie zgadzam się. Ale to trochę kurczak i jajko. Jeśli potrzebujesz pozwolenia na rozpoczęcie pisania testów jednostkowych, trudno jest użyć ich do udowodnienia, że ​​pozwolenie powinno zostać udzielone. To nie jest albo. Porównanie z rzeczywistymi danymi jest znacznie silniejszym argumentem. Ten alternatywny argument jest słabszy, ale łatwiejszy do zamontowania.
JimmyJames
20

Pokaż zwrot z inwestycji (ROI)

Pisanie automatycznych testów wymaga czasu. Pewnego razu. Przeprowadzanie testów automatycznych zajmuje zero czasu, ponieważ możesz zrobić coś innego podczas ich działania.

Przykład: Ręczne testowanie funkcji X zajmuje 30 minut. Napisanie zautomatyzowanego testu zajmie 1 godzinę. Nawet jeśli nie mamy żadnych błędów, będziemy musieli przetestować cechę X dziesięć razy w trakcie projektu, gdy jej zależne warstwy i komponenty zostaną zmodyfikowane. Zautomatyzowanie testu funkcji X pozwoli nam zaoszczędzić 4 godziny w trakcie trwania projektu.

W rzeczywistości, kiedy masz błąd, automatyczne testy naprawdę się opłacają - po pierwsze, znajdują błędy wcześnie i tanio, co oszczędza czas i kłopot. Po drugie, jeśli masz trudny błąd i przechodzisz przez wiele cykli tworzenia kodu, aby go rozgryźć, czas zaoszczędzony na ręcznym testowaniu jest wyjątkowo szybki.

Firmy rozumieją, jak oszczędzać czas i pieniądze. Tak to sprzedać.

Steven A. Lowe
źródło
3
Również po wdrożeniu aplikacji i zapytaniu o zmianę, o wiele łatwiej jest sprawdzić, czy coś nie zepsuło się z wprowadzonymi zmianami.
m4tt1mus
4
@mattimus: absolutnie - zautomatyzowany zestaw testów opłaca się jak renta; w rzeczywistości jest to ubezpieczenie
Steven A. Lowe
15

Jeśli już się z nimi spotkałeś i nie są w porządku, ale bez nich nie czujesz się komfortowo pisząc kod ... nie pytaj ponownie. Po prostu je napisz i nie melduj się.

Zarząd nie zamierza liczyć wierszy kodu, ale zobaczy, że wszystkie twoje zgłoszenia mają wyższe wskaźniki przepustowości od kontroli jakości (lub klientów) i ostatecznie zapytają, dlaczego ... to możesz być taki jak "BAM! TDD ! ”

Nie zadzierasz z projektem, procesem lub źródłem ... więc nie widzę negatywnego powodu. Szczerze mówiąc, nie widzę powodu, dla którego jest inaczej niż uruchamianie wszystkich testów ręcznego uruchamiania + wprowadzania + sprawdzania wyników.

Steven Evers
źródło
4
+1: i tak musisz przetestować. Po prostu napisz testy jednostkowe, a nie spieraj się o tym, jak należy je wykonać.
S.Lott,
1
Po prostu ich lokalnie nie działa dobrze w środowisku zespołowym ze wspólną bazą kodu, inne osoby będą przerywać testy z ich zmianami.
Alb
3
@Alb: Jest to cena, którą płacisz, gdy kierownictwo nie wchodzi na pokład - lepiej niż żadne testy.
Steven Evers,
3
Brawo. Każdy test jest lepszy niż brak testu. Jeśli test kończy się z powodu zmiany dokonanej przez inną osobę, warto zapytać, dlaczego interfejs API zmienił się bez powiadomienia.
S.Lott,
„Zarządzanie nie będzie liczyć wierszy kodu”, to bardzo prawda. Dziękuję za odpowiedź!
louisgab,
7

1) Klient nie zapłacił za testy jednostkowe

Klient (myślał, że zapłacił) za działające rozwiązanie. W zależności od umowy naprawianie usterek może być opłacalne dla Twojej firmy. Jeśli jest wystarczająca blokada. Wróćmy do płacenia za działające rozwiązanie. TDD powinno pomóc w osiągnięciu tego celu.

2) Projekt nie przewiduje czasu na TDD

TDD nie trwa dłużej. Powinno to zmniejszyć ilość zbędnego lub zbędnego kodu i skoncentrować bazę kodu na tym, co sprawia, że ​​testy są udane. Wszystkie zaliczone testy, z zastrzeżeniem jakości i adekwatności testu, oznaczają, że kod został wykonany.

3) Dług techniczny? Jaki dług techniczny?

Mam wrażenie, że możesz argumentować za retrospektywnym dodaniem testów do istniejącego kodu. To najlepsza okazja na koszmar i nie przynosi oczekiwanych korzyści. Jednak dodawanie testów podczas naprawiania błędów powinno być dopuszczalne i pomagać na dłuższą metę.

I tak nie polecam pisać testów, jak sugerował Snorfus. To brzmi nieźle w teorii, ale testy jednostkowe można i zrobić zmiany w czasie. Wraz ze zmianami wymagań pojawiają się nowe funkcje, dlatego testy jednostek wymagają aktualizacji. Jeśli pracujesz w zespole, testy jednostkowe będą przestarzałe, gdy inni dodadzą funkcje / poprawki.

Zajmuję się konkretnymi punktami, o których wspominałeś, a nie podnoszeniem nowych, ponieważ istnieje swoboda, by robić postępy lub zrozumieć, dlaczego jest blokowany.

Ian
źródło
5
„W każdym razie nie polecam pisania testów” - byłem w tej pozycji wcześniej. Trudno jest utrzymać testy samodzielnie. Jeśli to obciążenie stanie się zbyt duże, po prostu porzuć testy. Przynajmniej miałeś je podczas aktywnej pracy w bazie kodu, co powinno pomóc w początkowym projekcie / poprawce, jeśli nie wychwytuje regresji. Znalazłem ogromną wartość w testach jednostkowych do celów projektowych, ale znalazłem dość mało regresji, gdy testy nie są utrzymywane na tym samym poziomie co kod.
Steve Jackson
1
Ktokolwiek dodał funkcje / poprawki i nie zaktualizował testów jednostkowych, nie rozumiał pojęcia testu jednostkowego.
Akira Yamamoto
Rzeczywiście, Akira, jest to jeden z najbardziej kłopotliwych problemów wpływających na rentowność TDD lub powiązanych procesów. Pamiętaj, że najwyraźniej napisałem to 7 lat temu, wiele jest nadal aktualnych. Pisanie (dobrych, obiektywnych, zwięzłych) testów jest trudne. Pisanie testów dla bazy kodu, która jej nie ma, jest bardzo trudna. Sprawienie, by kierownictwo nietechniczne zobaczyło korzyści, jest trudne (chyba że przeczytają artykuł na ten temat, w którym to przypadku zostaniesz „zmierzony” na śmierć. Nawet pojęcie tego, co jest jednostką, jest trudne. Jestem klasykiem, więc mój pomysł na jednostkę nie jest taki sam jak Mockist (jako przykład z 30 postaciami)
Ian
4

Dla każdego klienta mającego problemy produkcyjne,

  1. Napisz test jednostkowy i wyślij wiadomość e-mail do kierownika, informując, że dodałeś test jednostkowy na wypadek scenariusza.

  2. I powiedz mu, że ten problem nie powtórzy się w produkcji, ponieważ nasz test jednostkowy jest przeprowadzany co noc i dowiemy się, zanim kod przejdzie do produkcji, obserwując niepowodzenie testu jednostkowego.

  3. Powiedz mu, że gdybyśmy mieli już test Jednostki, zanim kod trafił do produkcji, ten problem z produkcją nigdy by się nie zdarzył.

Rób to konsekwentnie i wytrwale, a wkrótce on się przekona. Menedżerom nie podoba się klient, który boryka się z problemami produkcyjnymi, i kupi pomysł na testowanie jednostkowe. Powodzenia.

java_mouse
źródło
To dobrze :-)
BVengerov,