Jak zwiększyć popularność automatycznych testów? [Zamknięte]

13

Nasza baza kodów rośnie od 20 lat. Mamy około 10 deweloperów + sqa pracujących z 500kloc. Jakiś czas temu mały zespół z nas (2 deweloperów, jeden z sqa) rozpoczął pracę nad automatycznym programem testowym. Obecnie jedno uruchomienie zajmuje 11 godzin i jest niejako testem integracyjnym. Pracujemy nad tym, aby zmniejszyć ten poziom i zmniejszyć liczbę fałszywych trafień, i robimy w tym zakresie znaczne postępy. Ale szczegóły nie powinny mieć znaczenia.

Działa dobrze i wciąż go ulepszamy. My (mały zespół) bardzo to lubimy. Jeśli coś zepsujemy, zauważymy dzień później, a nie 2 miesiące później, kiedy przyjrzy się sqa. Również naszym menedżerom (dev + sqa) podoba się ten pomysł. Ale inni ludzie w zespole po prostu ignorują wyniki testu. Ich zdaniem, jeśli testy nie kończą się powodzeniem, to jest to problem testu, a nie zmiany kodu i to tylko nasz projekt zabawki. Kilka razy rozmawialiśmy, czy nieudany test jest prawdziwym błędem. Najczęściej tak jest.

Nie możemy i nie chcemy czegoś wymuszać. Jak możemy pokazać, że zautomatyzowane testowanie jest rzeczą?

testing integration-tests Peter Schneider
źródło
11
To nie jest problem inżynierii oprogramowania; to jest problem ludzi.
Robert Harvey
@RobertHarvey Mam negatywne opinie na temat SO, ponieważ „oparte na opiniach” i komentarz, że ta strona będzie idealnie pasować (i opinie na temat tego komentarza). Więc: gdzie mam zapytać? Naucz mnie.
Peter Schneider,
2
Jestem z @RobertHarvey o tym, że jest to problem ludzi. Ale jeśli chodzi o miejsce pracy, twoje pytanie prawdopodobnie zostanie uznane za duplikat. Na przykład zobacz to pytanie, które jest zasadniczo tym, o co pytasz workplace.stackexchange.com/questions/44964/...
Peter M
1
Nie zniechęcaj tych downvoters (ani nawet głosów z bliska)! Niektóre osoby mogą zrozumieć, że takie pytania są ważne i być może mogą udzielić pomocy. Nawiasem mówiąc, również moi koledzy nie widzą przydatności zautomatyzowanych testów, mimo że poprzednia wersja (bez żadnych zautomatyzowanych testów) jest skrzynką błędów. Po prostu zmień jedną rzecz i połam kilka innych, pozornie niezwiązanych rzeczy. Niektóre osoby po prostu nie chcą się uczyć (istnieje otwarty opór przed uczeniem się nowych rzeczy).
Bernhard Hiller
1
Szkoda, że ​​to pytanie zostało zamknięte. Jeśli inżynieria oprogramowania coś znaczy, oznacza to problemy w pracy z rzeczywistymi ludźmi, a odpowiedzi na takie problemy będą wymagały opinii. To powiedziawszy, kilka szybkich pomysłów: (1) jeśli testy dadzą fałszywe negatywy, to zdecydowanie zwiększy odpychanie, ponieważ wyniki będą wydawać się stratą czasu; (2) obniż czas działania, jeśli to w ogóle możliwe. 11 godzin nie wydaje się natychmiastowych, nawet jeśli jest to znacznie lepsze niż dwa miesiące; (3) sqa zastosuje te testy jako wskaźniki, które oglądają. są już rozpoznane przez twoją organizację w tym obszarze.
Dale Hagglund

Odpowiedzi:

4

Zrzeczenie się

Chociaż mogę brzmieć jak menedżer, napisałem to jako programista, który również musiał zostać przekonany, że testy automatyczne są dobre.

Musisz zrozumieć podstawową psychologię programistów. Jest to zakorzeniona potrzeba programistów do zatwierdzania kodu. Wszystko, co im to uniemożliwia, jest bardzo, bardzo złą rzeczą. Nieudany test jest zdecydowanie czymś, co im to uniemożliwia, ergo, to zła rzecz. Stąd opór.

Należy zauważyć, że podczas gdy automatyczne testy spowalniają je w krótkim okresie, na dłuższą metę zaoszczędzi im wiele żalu i faktycznie je przyspieszy, ponieważ będą mogli bardziej skoncentrować się na rozwoju nowe rzeczy i stracisz mniej czasu, robiąc inne rzeczy, których programiści nienawidzą: naprawianie błędów.

I tak, musisz to egzekwować. Musisz uzyskać bezwarunkowe wsparcie od kierownictwa i uczynić pisanie testów automatycznych obowiązkowymi i niepodlegającymi negocjacjom. Z czasem programiści przyzwyczają się do nich. Pomoże ci to, jeśli uda ci się opracować pewne wskaźniki, które pokażą, o ile więcej nowych prac zostało dokonanych i o ile liczba błędów została zmniejszona od czasu wprowadzenia automatycznych testów. Słowa są niestabilne. Liczby są stałe. A liczby są czymś, co przeciętny programista rozumie lepiej niż słowa. Jeśli możesz udowodnić, używając liczb stałych, że testy automatyczne są dobre, nie uzyskasz od nich odporności na żadną lub wcale.

Vladimir Stokic
źródło
11

Ich zdaniem, jeśli testy nie kończą się powodzeniem, to jest to problem testu, a nie zmiany kodu i to tylko nasz projekt zabawki. Kilka razy rozmawialiśmy, czy nieudany test jest prawdziwym błędem. Najczęściej tak jest.

To twój problem. Jeśli twoje testy są niestabilne (nawet jeśli są wiarygodne „przez większość czasu”), ludzie będą ignorować wyniki. Twój zespół ds. Automatyzacji powinien skoncentrować się na eliminowaniu fałszywych negatywów. Tylko wtedy reszta zespołu zyska wystarczającą wiarę w wyniki, aby faktycznie im zaufać.

Eternal21
źródło
5
Z drugiej strony może to być coś innego. Jak opór wobec zmian. Jeśli test się nie powiedzie, zawsze jest coś do naprawienia, albo kod, albo test, więc postawa, że ​​ludzie będą ignorować testy, ponieważ testy są niestabilne, jest niewłaściwa.
Robert Harvey
Rozmawialiśmy z nimi, gdy byliśmy pewni, że coś się zepsuło (np. Test nie powiódł się 3 razy z rzędu po jego zameldowaniu, co wpłynęło na funkcjonalność). Ale tak, zwiększenie niezawodności jest obecnie priorytetem.
Peter Schneider,
1
@PeterSchneider test może się nie powieść 100 razy z rzędu, zrobi to zwłaszcza, jeśli test jest zły.
Pieter B
Z drugiej strony test, który nigdy się nie powiedzie, jest najprawdopodobniej całkowicie bezużyteczny
Vladimir Stokic
1
+1 Kruche testy są zdecydowanie problemem. Deweloperzy muszą być przekonani, że pisane testy są przydatne, nie wprowadzają niepotrzebnych komplikacji i nie są pracochłonne .
Andres F.,
6

Nie możemy i nie chcemy czegoś wymuszać.

Zdecydowanie powinieneś go egzekwować! Jeśli ktoś wypchnie nowy kod i testy zakończą się niepowodzeniem, kod należy odrzucić! Jest to jedyny sposób na niezawodne utrzymanie większego projektu oprogramowania.

Banan
źródło
Myślę, że to zależy od systemu, testów, skali i procesu rozwoju. Nie wszystkie błędy można rozwiązać od razu, a wszystkie problemy nie muszą być rozwiązane od razu.
NickL