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.