Czy powinienem wymagać od programistów testowania jednostkowego? [Zamknięte]

Pracuję w miejscu, w którym kupujemy wiele projektów IT. Obecnie tworzymy standard wymagań systemowych na potrzeby przyszłych projektów. W tym procesie dyskutujemy, czy możemy zażądać zautomatyzowanych testów jednostkowych od naszych dostawców.

Mocno wierzę, że odpowiednie automatyczne testy jednostkowe są jedynym sposobem na udokumentowanie jakości i stabilności kodu. Wszyscy inni uważają, że testowanie jednostkowe jest opcjonalną metodą, która dotyczy wyłącznie dostawcy. Dlatego nie będziemy stawiać żadnych wymagań dotyczących zautomatyzowanych testów jednostkowych, testów ciągłych, raportów pokrycia, inspekcji testów jednostkowych lub jakiegokolwiek innego rodzaju. Uważam tę politykę za bardzo frustrującą.

Czy jestem tu całkowicie poza linią?

Proszę przedstawić mi argumenty za którąkolwiek z opinii.

Mocno wierzę, że odpowiednie automatyczne testy jednostkowe są jedynym sposobem na udokumentowanie jakości i stabilności kodu.

Chodzi o to, że nie uzyskasz (lub przynajmniej bardzo rzadko) odpowiednich automatycznych testów jednostkowych, narzucając je ludziom. To dobry sposób na gówniane testy i podnieść koszty projektów.

Osobiście szukałbym popytu lub umowy SLA, która wiąże się z jakością; niezależnie od tego, jak się to osiąga. 10 lat temu testy jednostkowe w najlepszym wypadku były rzadkie. Nie chcesz zakładać kajdanek swoim dostawcom za 10 lat, kiedy mamy lepsze metody zapewniania jakości, ale twoja przestarzała polityka wymaga od nich dawnego sposobu.

Osobiście uważam, że w twoim przypadku powinieneś pomyśleć w kategoriach testów akceptacyjnych:

• Otrzymałeś czarną skrzynkę i oczekujesz, że zachowa się ona w określony sposób.
• Nie zapłacisz, dopóki tak nie będzie.
• Napisz testy jednostkowe ćwicząc zachowanie, które musisz zobaczyć, a jeśli się nie powiedzie, musisz je naprawić.

Pamiętaj też, że jest to kwestia zaufania. Jeśli nie ufasz swojemu dostawcy, musisz zdobyć kod źródłowy, sprawdzić go i skompilować samodzielnie. Coś mniej niż to oznacza, że ​​przynajmniej niektórym im ufasz .

Mocno wierzę, że odpowiednie automatyczne testy jednostkowe są jedynym sposobem na udokumentowanie jakości i stabilności kodu.

Zaskakuje mnie, jak powszechne jest to myślenie. Zautomatyzowane tak. Testy jednostkowe (same), nr Zautomatyzowane testowanie oprogramowania to coś więcej niż same testy jednostkowe. Co z integracją, systemem, funkcjonalnością, kontrolą jakości? Z niektórych powodów ludzie myślą: „Ok, więc mamy odpowiednie testy jednostkowe. Zrobione z testami, nazwijmy to piątkowym wieczorem!” . Testy jednostkowe to dopiero początek.

W każdym razie wracając do tematu. Zgadzam się z innymi, mówiąc, że narzucanie komukolwiek czegoś prawdopodobnie przyniesie rezultaty odwrotne do pożądanych. Nigdy nie wiadomo, jak działa zespół, może dostali dział testowy warty milion dolarów i nigdy nie napisali testu pojedynczej jednostki.

W mojej pierwszej pracy pracowałem w miejscu, w którym mieliśmy 0 testów jednostkowych (byliśmy grupą juniorów rzucających mniej lub bardziej poważne rzeczy). Wierzcie lub nie, działało. Jasne, nikt się nie dowiedział, dlaczego ten błąd został naprawiony lub co się zepsuło, ale zadziałało. Były chwile, kiedy pojawiał się jakiś absolutnie przypadkowy błąd, alekij baseballowy i ryzyko poparzenia mieszkaniadodatkowe godziny mogą zdziałać cuda. Może twoi dostawcy stosują podobne techniki ?

Wątpię bardzo, czy kierownictwo będzie skłonne zapłacić za odpowiednie testy jednostkowe w umowie. Właściwy test jednostkowy kosztuje tyle samo, co testowany kod, ale daje mało postrzeganą wartość użytkownikowi końcowemu, więc nie będą postrzegani jako równie wartościowe. Żadna firma zajmująca się opracowywaniem jakości nie będzie skłonna poświęcić wysiłku rozwojowego na testy jednostkowe za mniejszy koszt niż inne części, ponieważ nie szkodzą pracy, mogą znaleźć więcej umów na 2 zamówienia, które zajmują tyle samo czasu bez wymagania dotyczące testu jednostkowego.

Wymagające testy jednostkowe prawdopodobnie podniosą otrzymane oferty do nieuzasadnionego poziomu i prawdopodobnie będzie to pierwsza koncesja uzyskana w celu uzyskania niższej ceny.

Koszt braku testów jednostkowych zależy od tego, ile sam będziesz przedłużał / wspierał kod. Ważne byłoby również sprawdzenie części kodu, aby uzyskać pojęcie o jakości.

Jeśli tylko kupujesz projekty, abyś mógł ich używać jak biblioteki innej firmy i nie wierzysz, że je zmodyfikujesz, ryzyko kodu o niższej jakości jest mniejsze, o ile faktycznie działa.

Są to ostatecznie decyzje biznesowe, chociaż musisz upewnić się, że ktokolwiek podejmuje decyzję, jest również świadomy wyceny technicznej. Jeśli musisz wyjaśnić to kierownictwu, wyjaśnij, że to jak kupno używanego samochodu. Ostatecznie to kupujący decyduje, czy warto, ale zabranie go do mechanika jest dobrym pomysłem, abyś wiedział, że nie dostajesz cytryny.

Płacisz, możesz żądać, co chcesz, w tym kopii / raportów z wszystkich ich testów jednostkowych.

Możesz nawet napisać testy, a przynajmniej specyfikację testu.

Zgadzam się z twoim poglądem, ponieważ jest to bardzo dobra miara jakości kodu. Jeśli dostawca odrzuci to żądanie, zadzwoni dzwonkiem alarmowym, dlaczego nie miałby tego zrobić - mają niskie standardy jakości i skracają?

Masz całkowitą rację, że Twój projekt wymaga zautomatyzowanych testów jednostkowych, ciągłych testów, raportów pokrycia i inspekcji testów jednostkowych.

Jednak wymagające rzeczy nie przyniosą pożądanych rezultatów, jak inni to opisali.

Twoim wyzwaniem jest wyjaśnianie i przekonywanie ludzi - o wiele trudniejsze umiejętności!

Zacząłem od zarządzania, wyjaśniając wady i zalety testowania i wypłaty w dół drogi. Zachowaj ostrożność, aby nie przekazać emocji zawartych w stwierdzeniach typu „Piszę WŁAŚCIWE testy jednostkowe” (twoje wielkie litery). Nie chcesz „wykrzykiwać” słów (jak sugeruje WSZYSTKIE CZAPKI), będziesz przekonywał i przekonywał ludzi, aby sami mogli wybrać właściwe rozwiązanie.

Ostatecznie, jeśli nie możesz wprowadzić tych metodologii i sprawić, by zostały one przyjęte tam, gdzie jesteś, a także, jeśli jesteś nimi tak pasjonujący, jak twierdzisz (co jest dobre!), Poleciłbym inną firmę, ponieważ jest wielu, którzy cenią te rzeczy i witam na pokładzie. Po prostu upewnij się, że rozmawiasz o nich w wywiadach, aby wiedzieli, gdzie leżą twoje pasje i czy będziesz w dobrej formie.

Narzucenie komuś zautomatyzowanego testowania nie przyniesie pożądanych rezultatów, jak zauważyli w swoich komentarzach @Joachim Sauer i @Telastyn. Dla wielu osób zautomatyzowane testowanie jednostek jest ogromną zmianą w ich myśleniu. Ponieważ wiele osób pisze kod, który działa, ale nie jest bardzo testowalny. Mógłbym napisać stronę ASP.NET, gdzie cała logika, zapytania do bazy danych, reguły biznesowe, obiekty itp. Są w kodzie. Czy strona będzie działać? Tak. Czy można to przetestować za pomocą automatycznego testowania jednostkowego? Absolutnie nie. Jeśli dostawca nie ma zautomatyzowanych testów jednostkowych, nauczy się, jak poprawnie pisać testy jednostkowe, a w wyniku uczenia się tego przepisuje lub ponownie rozkłada kod, aby ułatwić testowanie. Możliwe, że przekażą ci ten koszt.

Faktem jest, że dostawca daje ci produkt, niezależnie od tego, czy jest to dll, czy aplikacja Windows, i oczekujesz, że będzie on działał przez 99% czasu. Oczywiście są tu i ówdzie błędy, ale w przeważającej części powinno to działać. Jest to uzasadnione oczekiwanie, szczególnie jeśli dostawca chce utrzymać swój biznes. Jeśli jest to czarna skrzynka, to tak naprawdę nie ma znaczenia, jak ją uruchomić, mogliby skorzystać z ludzkiej fali testerów lub pokoju pełnego małp losowo uderzających w klawisze. Tak długo, jak to działa. Ale będą musieli dostarczyć ci jakąś inną dokumentację, jak z niego korzystać.

Gdyby jednak dali ci kod źródłowy, abyś mógł go zmodyfikować, oczekiwałbym testów jednostkowych. Nie współpracowałbym z firmą, która nie dostarcza testów jednostkowych. Skąd miałbyś wiedzieć, że dokonana modyfikacja nie doprowadzi do końca?

Testy jednostkowe wskazują, jak ten dostawca radzi sobie z ryzykiem w cyklu rozwojowym. Ci, którzy korzystają z testów jednostkowych, zmniejszają ryzyko, a jakość tych testów wskazuje, jak dużym ryzykiem zarządzano.

Mając to na uwadze, testy jednostkowe nie określają poziomu ryzyka, który projekt próbuje rozwiązać. Nie odgrywa też żadnej roli w ograniczaniu ryzyka wprowadzanego przez złe praktyki programowania.

Dlatego możesz mieć jednego dostawcę, który ma solidne praktyki testowania, ale nadal pisze bardzo ryzykowny kod, podczas gdy inny dostawca, który nie przeprowadza testów, ale pisze kod niskiego ryzyka. Jeśli dwóch dostawców oferuje ten sam produkt, najlepiej wybrać dostawcę niskiego ryzyka.

Można to zmierzyć jedynie poprzez wywiad, mentoring i poznanie osobowości i umiejętności osób związanych z tym dostawcą.

Uważam, że ten artykuł na temat kupowania niestandardowego oprogramowania jest bardzo przydatny: http://blog.8thlight.com/paul-pagel/2012/06/20/entrepreneurs-guide-to-buying-software.html

Pytanie, które najczęściej zadają, to pytanie, czy dostawca pisze testy.

Zgadzanie się z innymi, że wymagają testów jednostkowych, prowadziłoby do testowania dla samego testowania; coś, co jest bardzo sprzeczne z tym, czego chcesz.

W trakcie sprawdzania dostawców; zapytaj ich, jaki jest ich proces rozwoju , ponieważ testowanie jest tylko częścią tego procesu.

Czy mają zautomatyzowany proces kompilacji? Czy przestrzegają jakiegoś paradygmatu zarządzania? Czy mają odpowiednio przeszkolonych testerów i niezależny zespół zapewniania jakości ? Co powiesz na standardy dokumentacji?

Pomogą ci ocenić ogólną jakość procesu, a tym samym jakość tego, co produkują.

Wydaje mi się, że włączenie tego wymogu nie przyniosłoby praktycznych korzyści, ponieważ jego egzekwowanie byłoby niemożliwe.

Możesz zażądać kodu dla rzeczywistych testów lub raportu o tym, jakie rzeczywiste testy zostały uruchomione i zaliczone. Jeśli jest to projekt prawnie zastrzeżony, sprzedawca prawdopodobnie nie chciałby go dostarczyć, ponieważ prawdopodobnie byłby wysoce sugestywny co do szczegółów kodu, i może narzekać na to, że podaje szczegóły implementacji niskiego poziomu i powiedział, jak zrobić Oferty pracy. W pewnym momencie musi być pewne zaufanie.

Jeśli tego nie zrobisz, mogą cię też zdmuchnąć, ale po prostu zaznaczając pole „uruchamia zestaw testów jednostkowych”, aby spełnić wymóg, pisząc pojedynczy test, który przejdzie, jeśli jego narzędzie się skompiluje i uruchomi, lub podobny test wysiłek.

Tak więc chociaż zautomatyzowane testy jednostkowe są godną pochwały praktyką, nie sądzę, aby naleganie na nie ze strony zewnętrznych dostawców było praktyczne.

Jak zauważyło wiele osób, zmuszanie sprzedawców do napisania testów jednostkowych (lub lepiej kombinacji automatycznych testów jednostkowych i integracyjnych) do wykonania umowy prawdopodobnie nie przyniesie wyników wysokiej jakości. Z drugiej strony zgadzam się, że automatyczne testowanie jest zdecydowanie najlepszą obecnie stosowaną metodą zapewniania jakości kodu.

Myślę, że kod napisany za pomocą testów jednostkowych jest o wiele łatwiejszy w utrzymaniu niż kod napisany jako pierwszy, a testy jednostkowe zostały dodane później. Wymusza modułowość i minimalne zależności. Testy integracyjne są również niezbędne do weryfikacji poprawności kodu, ale nie mają one takiego samego wpływu na jakość kodu, jak jest napisany. Zasadniczo zautomatyzowane testy integracji można dodać po fakcie, ale testy jednostkowe mają największy wpływ, gdy są napisane przy użyciu oryginalnego kodu.

Moja rada dla twojej sytuacji to poszukiwanie dostawców, którzy wolą pisać kod za pomocą testów jednostkowych, i wybieram ich spośród dostawców, którzy zwykle nie piszą kodu za pomocą testów jednoczących. Jeśli kierownictwo zapłaci za to, umieść zautomatyzowane testy w umowie, ale TYLKO JEŻELI DOSTAWCA JEST UŻYTY DO PISANIA KODU Z TESTAMI JEDNOSTKI.

Najpierw ustalmy priorytety ...

W roli klienta najważniejszy jest test jednostkowy

Jeśli korzystasz z dostawców, którzy produkują oprogramowanie dla ciebie, to naprawdę nie powinieneś się martwić, czy stosują taką czy inną metodologię. Stawką jest znalezienie rozwiązania, które pomoże osiągnąć Twoje cele. Jedyne, na co powinieneś zwrócić uwagę, to to, czy rozwiązanie jest akceptowalne. Dlatego przeprowadzamy testy akceptacyjne, ponieważ Twoim obowiązkiem jest upewnienie się, że otrzymujesz to, czego chcesz. W decydującym momencie akceptacji klienta pieniądze będą przekazywane z kieszeni Twojej firmy do kieszeni dostawcy.

Możesz zażądać testów jednostkowych jako wymogu dostarczenia, ale istnieje kilka dziedziczonych problemów, z których najbardziej poważne jest to, że nie ma wcześniej pewnego sposobu na określenie wskaźników:

• Jaka jest dopuszczalna liczba testów jednostkowych?

Czy powinno być 10 testów? Co powiesz na 100 testów? A może około 1000 testów? Właściwie na początku trudno jest określić, ile testów będzie potrzebnych. Rzeczywista liczba jest nieokreślona, ​​naprawdę ... jak problem zatrzymania ... ale nie rozwiązujemy tego problemu.

Potrzebujesz tylko oprogramowania, które ma testy jednostkowe, abyś mógł kontynuować rozwój. Testy jednostkowe nie informują o tym, co jeszcze złamałeś, ale są one bardzo odpowiednie, aby poinformować Cię, kiedy kod zawiera błąd regresji.

• Jaki jest dopuszczalny poziom pokrycia kodu?

„100%, oczywiście!” pomyślałbyś. Niestety ta metryka wprowadza w błąd; nawet jeśli masz 100% pokrycia kodu, czy naprawdę jesteś pewien, że wszystko działa zgodnie z oczekiwaniami? Możliwe jest posiadanie 100% zasięgu, ale nie można tego zrobić.

To, co naprawdę musisz zrobić, to testy eksploracyjne, tj. Znajdź kogoś, kto jest naprawdę dobry w łamaniu rzeczy i pozwól mu to zrobić. Aby znaleźć błędy, o których nawet deweloper nawet nie pomyślał.

Również 100% jest czasami nieosiągalne przy czystych testach jednostkowych, jeśli masz kilka niezbędnych poprawek wydajności i używasz trudnych do przetestowania wzorców projektowych (wyszukaj „singleton” i „tdd” w swojej ulubionej wyszukiwarce, a znajdziesz kilka przykładów).

Chcesz, aby dostarczone oprogramowanie działało, a dokumentacja specyfikacji jest twoją jedyną gwarancją, że będzie.

Będziesz potrzebował wyższego poziomu testowania

Twój dokument specyfikacji musi zostać jakoś zweryfikowany. Każdy punkt musi zostać zrealizowany, a dostawcy mają jasne cele i kryteria akceptacji. Dobrze działająca organizacja zapewniania jakości (lub świetny tester, jeśli masz ograniczony budżet i ograniczony zakres) zapewniłby przypadki testowe do sprawdzenia tych kryteriów akceptacji. Potrzebujesz również kogoś, kto zweryfikuje te kryteria akceptacji.

Istnieje kilka sposobów na zweryfikowanie twoich celów, a jeśli ktoś powie mi, że nie możesz wyznaczyć rozsądnych celów w zakresie jakości, wydajności i wydajności, uderzę ich w głowę dużymi i ciężkimi książkami na temat badań eksploracyjnych, wydajności i użyteczności. Może być łatwo przesadzić z celami, ale wiedza i komunikacja pomogą ci ustalić realistyczne cele.

Nie jestem prawnikiem, ale większość umów projektowych (które w zasadzie są matką wszystkich specyfikacji dla projektu), które przeczytałem, zwykle mają kryteria współczynnika defektów, które określają, ile błędów uznaje się za dopuszczalne. Błędy są zwykle określane na podstawie dotkliwości, błędy zatrzymujące pokazy, które zostały wykryte przez QA, mają niską tolerancję, podczas gdy drobne skazy mają wysoką tolerancję. W prawdziwych projektach trudno jest wymagać, aby oprogramowanie miało 0 wad. Terminy zwykle kończą tę praktykę. W takich sytuacjach musisz zacząć negocjować zakres.

Większość dostarczonego oprogramowania, które zazwyczaj widziałem, nie jest dostarczane z testami jednostkowymi. Możesz argumentować, że dostawcy powinni być wystarczająco profesjonalni, aby to dostarczyć, jednak głównym powodem, dla którego chcesz dostarczyć testy jednostkowe, jest upewnienie się, że nie otrzymujesz błędów regresji, a także umożliwienie refaktoryzacji. W prawdziwym życiu z projektami o napiętych terminach zarówno dostawca, jak i klient będą zmniejszać zakres, a testy jednostkowe zwykle wychodzą z okna i są usuwane z listy wymaganych produktów.

Trochę smutne jest to, że głośne oprogramowanie open source dostarczane jest wraz z testami jednostkowymi, ale profesjonalny programista nie może, prawda?

Kiedy więc jako klient zajmę się testowaniem jednostkowym?

Uważam, że tylko czas byś naprawdę dbają o testów jednostkowych jest sytuacja, gdy dostarczane oprogramowanie jest samowystarczalny składnik, który nie jest wykonywany jako samodzielny program, za który testuje zgrubna można zrobić to badanie jednostka . Biblioteki klas byłyby jednym rodzajem produktu, który może być dostarczany wraz z testami jednostkowymi.

Skąd wiadomo, że dostawcy nie piszą testów jednostkowych.

Może zarząd i sprzedawca odbyli spotkanie, a sprzedawca powiedział, że kod kosztuje X USD, a testy jednostkowe kosztują Y USD. Penny szczypanie zarządzania powiedział, że po prostu chcemy kodu.

Sprzedawca postanowił napisać testy jednostkowe (ze względu na jakość) i po prostu nie udostępniać ich Tobie (ze względu na przewagę konkurencyjną).

Teraz musisz wprowadzić kilka istotnych zmian w oprogramowaniu. Ponieważ jesteś właścicielem kodu, możesz zrobić to sam lub wynająć go w sposób konkurencyjny (niekoniecznie u oryginalnego dostawcy). Ponieważ jednak nie kupiłeś testów jednostkowych, pierwotny sprzedawca będzie mógł wykonywać prace o porównywalnej jakości po niższej cenie niż jakikolwiek konkurent.

Istnieje wiele projektów, które odnoszą duże sukcesy, mimo że nie używają testów jednostkowych. Wystarczy spojrzeć na jądro Linuksa, jego gigantyczny projekt o złożoności znacznie przewyższającej to, co można znaleźć w każdym normalnym projekcie, i nadal działa. Więc jeśli wynikiem jest dobre oprogramowanie, nie powinieneś przejmować się, jak to osiągnęli.

Nie, nie musisz koniecznie wymagać kompletnych i zautomatyzowanych jednostek testowych. Ważniejsze jest, aby dostarczyli ci odpowiednie dokumenty strategii testowania. W ten sposób mamy się dobrze.