Testy automatyczne - ile wystarczy?

Wprowadzenie

W świecie tworzenia oprogramowania testowanie jest często postrzegane jako czasochłonny i pochłaniający zasoby proces, który spowalnia cykl rozwoju. Niektórzy programiści i prawdopodobnie większość product ownerów tego nie cierpi. Prawda jest jednak taka, że testowanie jest kluczowym elementem programowania, jako że zapewnia, że oprogramowanie działa zgodnie z jego przeznaczeniem. W tym artykule sprawdzimy, dlaczego programiści i product ownerzy testują i jak określić odpowiednią ilość testów automatycznych dla swoich potrzeb.

Artykuł rozpoczyna się od wad i zalet testów automatycznych, a następnie koncentruje się na odpowiedniej ilości testów. Dzięki temu lepiej zrozumiesz, jakie kryteria należy wziąć pod uwagę przy podejmowaniu decyzji o ilości testów, które chcesz przeprowadzić w swoim prywatnym lub zawodowym projekcie.

Wady testowania automatycznego

Czas (czas = $)

Jedną z głównych wad testowania automatycznego jest to, że konfiguracja i utrzymanie zajmuje z góry więcej czasu. Zautomatyzowane testy wymagają planowania, projektowania, wdrażania i utrzymywania, co może (w krótkim czasie) trwać dłużej niż zwykłe wykonywanie testów manualnych. Testowanie automatyczne może się również wiązać z koniecznością posiadania specjalistycznych umiejętności lub wiedzy, które w zespole programistów mogą być niekiedy mocno ograniczone.

Koszty infrastruktury

Jeśli uruchamiasz testy automatyczne na własnym komputerze, to zwykle nic za to nie płacisz (poza komputerem). Aby włączyć testy automatyczne do deploymentu, co jest całkiem rozsądne, trzeba zapłacić, jeśli przekroczy się określony limit. Takie koszty infrastruktury mogą stanowić przeszkodę dla niektórych organizacji, zwłaszcza tych o ograniczonych zasobach.

Zalety testowania automatycznego

Mniej błędów

Jedną z największych zalet testowania automatycznego jest to, że może ono pomóc w wychwytywaniu błędów na wcześniejszym etapie cyklu rozwoju produktu. Testowanie automatyczne może szybko i łatwo przeprowadzić setki lub tysiące testów, które wykrywają błędy, które podczas testowania manualnego mogą pozostać niezauważone. Zdarza się tak często, kiedy nowa funkcja przypadkowo zmienia inną część aplikacji, która nie została ponownie sprawdzona podczas testów manualnych. Wyłapując i naprawiając te błędy na wczesnym etapie, programiści są w stanie uniknąć kosztownego i czasochłonnego naprawiania błędów w późniejszym etapie cyklu rozwoju.

Warto tutaj dodać, że opłaca się to tylko wtedy, gdy planowane są kolejne nowe funkcje i zmiany w oprogramowaniu. Jeśli już zaprogramowałeś idealną aplikację, która nigdy więcej nie zostanie zmieniona, nie musisz dodawać żadnych testów. Zapobiegasz błędom tylko wtedy, gdy zmieniasz części oprogramowania, co zwykle ma miejsce.

Lepszy kod

Testowanie automatyczne mobilizuje programistów do pisania lepszego kodu. Ponieważ testy automatyczne wymagają testowalności kodu, programiści są zmotywowani do pisania bardziej modułowego, rozłącznego i łatwego w utrzymaniu kodu. Ułatwia to aktualizację bazy i zmniejsza prawdopodobieństwo wprowadzenia błędów lub pojawienia się błędów podczas wprowadzania zmian. Jakość kodu nie opłaca się od razu, ale w perspektywie średnio- i długoterminowej w formie przyspieszenia rozwoju (i piękna). Dave Thomas opowiada w swojej dość znanej książce „Pragmatyczny programista" (link partnerski Amazon, 2020), że nie pisze już testów. Koduje on od ponad 45 lat i robił testy automatyczne przez 30, ale kiedy przestał to robić, nie obniżyło to znacząco jakości kodu. Według niego główną zaletą testowania jest myślenie o możliwych testach i ich wpływie na kod. Dlatego też mniej doświadczeni programiści powinni pisać testy automatyczne, a ci bardziej doświadczeni mogą spróbować je pominąć. Obecnie Dave thomas pisze testy, ale jest to sposób na komunikację z innymi programistami.

Komunikacja z innymi programistami

Testowanie automatyczne może znacząco ułatwić komunikację między programistami, ponieważ umożliwia wspólne zrozumienie bazy kodu. Może pomóc zrozumieć, w jaki sposób różne części kodu działają na sibie i jak zmiany w jednej części bazy kodu mogą wpływać na inne. Ogólnie mówiąc, taki proces może przyczynić się do bardziej efektywnych i opartych na współpracy procesów rozwoju.

Mniej testowania manualnego

Testowanie automatyczne może zredukować liczbę potrzebnych testów manualnych, co z kolei zaoszczędza czas i zasoby. Testy automatyczne uruchamia się szybko i łatwo, dlatego programiści mogą uruchamiać je tak często, jak jest to potrzebne, bez konieczności interwencji manualnej.

Szybsze cykle wydawnicze

Z wymienionych powodów testowanie automatyczne może pomóc przyspieszyć cykl wydawniczy oprogramowania poprzez wychwytywanie błędów na wcześniejszym etapie cyklu rozwoju. Dzięki temu programiści mogą szybko i skutecznie usuwać błędy, unikając konieczności późniejszego czasochłonnego i kosztownego ich naprawiania. Szybsze cykle wydawnicze oznaczają również, że programiści mogą częściej publikować nowe funkcje i aktualizacje, co może prowadzić do większej satysfakcji użytkowników i zwiększonych przychodów.

Ile testów automatycznych powinieneś przeprowadzić?

Nie istnieje jedno, idealne rozwiązanie dla ilości testów automatycznych. „Idealna” ilość zawsze zależy od indywidualnej sytuacji. Myśląc w sposób ekonomiczny, powinieneś przeprowadzać testy wtedy, kiedy korzyści z nich płynące przeważają koszty. Łatwo jest określić ilościowo koszty testów automatycznych, ale trudno jest oszacować korzyści z nich płynące. Poniższy wykres ilustruje czynniki, które należy wziąć pod uwagę, aby określić odpowiednią ilość testów dla własnego przypadku. Na osi y znajduje się korzyść z testowania w €, a na osi x stosunek czasu pisania testów do pisania funkcji. Jeśli przeprowadziłbyś jedną godzinę testów na każde dwie godziny programowania funkcji, uzyskałbyś współczynnik 0,5 (1h/2h).

Zakładam, że korzyści z testowania mają użyteczność asymptotyczną. Oznacza to, że korzyść np. z lepszej jakości kodu jest tym mniejsza, im więcej go mam (malejąca użyteczność krańcowa), ale zawsze dodatnia. Z kolei koszty programisty są liniowe, ponieważ nie zmieniają się wraz ze wzrostem kwoty. Wykres jest tylko przykładem i będzie wyglądał zupełnie inaczej dla każdego indywidualnego przypadku.

Co to więc oznacza dla Twojego projektu? Ważnymi czynnikami przy podejmowaniu decyzji są horyzont czasowy (testowanie automatyczne może być postrzegane jako inwestycja), koszt błędu w oprogramowaniu, pożądana jakość kodu i aktualna wiedza programistów.

Poniżej opisuję trzy różne scenariusze, w których sens mają trzy skrajnie różne strategie testowania.

Warto rozważyć rezygnację z testów automatycznych, jeśli...

• Twój projekt jest mały (<3 miesiące), a kod nie będzie ponownie używany ani zmieniany.
• nie kontynuujesz pracy nad projektem, a zatem przyszła jakość (=szybkość) nie jest ważna.
• koszty błędów w kodzie są bliskie zeru. Programujesz np. prywatną aplikację, której nikt nie używa.
• nie lubisz testów i nie chcesz doskonalić swoich umiejętności w tym zakresie.
• żaden z uczestników projektu nie ma pojęcia o testowaniu automatycznym, a Ty nie masz odpowiedniego budżetu, aby taką wiedzę pozyskać.

Powinieneś myśleć o 100% pokryciu kodu (a nawet więcej), jeśli...

• koszty popełnienia błędu są bardzo wysokie. Może to mieć miejsce, jeśli pracujesz np. dla banku.

Powinieneś zrobić coś pomiędzy, jeśli...

• koszty popełnienia błędu są większe niż zero, ale nie na tyle wysokie, by czytać o tym w gazetach.
• chcesz mieć lepszą jakość kodu (= szybkość).
• projekt ma istnieć dłużej niż miesiąc.
• chciałbyś dodać nowe funkcje w przyszłości.
  
  

Podsumowanie

Ilość testów automatycznych, która przynosi największe korzyści, zawsze zależy od aktualnych okoliczności projektu. W artykule wymieniono kryteria, za pomocą których można podjąć decyzję o właściwej strategii testowania, takie jak horyzont czasowy, koszty błędów, pożądana przyszła jakość kodu (= przyszła szybkość) oraz wiedza programistów o testach automatycznych. Każdy zespół powinien uwzględnić te punkty, aby znaleźć idealną strategię testowania, dzięki której wychwycicie najważniejsze błędy, a jednocześnie przyspieszycie rozwój przy lepszej jakości kodu.

Oryginał tekstu w języku angielskim przeczytasz tutaj.