23 / 06 / 2017 Developers

Automatyczne testy aplikacji mobilnych cz.2

Wracam dzisiaj po dwutygodniowej przerwie do tematyki testów automatycznych. Po opublikowaniu ostatniego artykułu ze względu na skróty myślowe, które poczyniłem, podniosła się mała dyskusja – szczególnie w gronie naszych testerów. Dlatego chciałbym zacząć od krótkiego uzupełnienia do pierwszej części.

CZY TESTY AUTOMATYCZNE TO FAKTYCZNIE OSZCZĘDNOŚĆ?

W poprzednim artykule stwierdziłem, że jest to oczywiste, ale bez szerszego uzupełnienia jest to trochę nadużycie. Zacznę więc od porównania testów automatycznych i manualnych.

Do podstawowych zalet testów automatycznych nad manualnymi należą:

  1. Krótszy czas wykonania pojedynczego testu.
  2. Są tak samo dokładne przy każdym wykonaniu.
  3. Mogą być uruchamiane 24h/7.
  4. Testy i analiza wyników mogą być wykonywane niezależnie.

Wady testów automatycznych prezentują się następująco:

  1. Test automatyczny trzeba najpierw napisać, żeby się wykonał – co opóźnia rozpoczęcie testowania i znacznie zwiększa koszt przypadający na pierwszy test.
  2. Modernizacja aplikacji może pociągnąć za sobą również potrzebę zmiany testów automatycznych.
  3. Dłuższy czas potrzebny na analizę wyników testów – w przypadku testów manualnych analiza przebiega równolegle z testem.
  4. Sprawdzają one tylko i wyłącznie to co mają zaprogramowane i nie ma szansy, że zobaczą coś “przy okazji”.

Lista pokazuje, że testy automatyczne nie są takie wspaniałe jak je wcześniej opisywałem. Tak naprawdę napisanie go jest droższe, zajmuje czas, a potem jeszcze trzeba dokonać analizy wyników.

Dlatego nadal twierdzę, że testy automatyczne prowadzą do oszczędności? Ponieważ w biznesie nie tworzy się aplikacji czy systemów “na zaliczenie” – jak na studiach, tylko na lata. Nawet jeśli aplikacja się nie rozwija i jedyne prace są związane z jej utrzymaniem, to właśnie testy automatyczne pozwalają na szybkie wychwycenie błędów związanych np. z nieprzewidzianym formatem danych. Mimo, że analiza wyników faktycznie jest dłuższa, to traci to na znaczeniu, ponieważ:

  1. Testów jest dużo więcej niż manualnych,
  2. A wyniki testów interpretuje się jako całość.

KRÓTKA HISTORIA O TESTOWANIU

Właściwa obsługa testów automatycznych od początku wymaga zespołu testerów. Do ich zadań, oprócz tworzenia i wykonywania testów należą również: optymalizacja, utrzymanie testów i narzędzi testowych.

Prawdopodobnie czytacie to na siedząco, więc czas na kolejną historię: Wyobraźmy sobie, że są dwie identyczne firmy, pracujące nad dokładnie tym samym projektem. Jedna z nich (nazwijmy ją M) korzysta wyłącznie z testerów manualnych, a druga (A) oprócz testerów manualnych tworzy również testy automatyczne. Obie firmy rozpoczynają wdrożenie swojego produktu i jednocześnie testują nowe funkcjonalności. Firma M zaczyna z jednym testerem, który przypada na 5 programistów, natomiast firma A od początku musi zatrudniać powiedzmy 4 testerów, z tego jeden manualnie testuje nowe funkcjonalności, a reszta zajmuje się testami automatycznymi.

Wniosek nasuwa się sam – testy automatyczne będą droższe od testów manualnych. I mówimy tutaj wyłącznie o testerach na etacie. Statystyka potwierdza, że jest to prawdą przez pierwsze pół roku. I tu pojawia się ‘ale’, ponieważ wraz z rozbudową każdego systemu rośnie zapotrzebowanie na testerów. A im większy system, tym jeszcze więcej pomysłów na jego rozbudowę. Niestety praktyka pokazuje, że w wielu przypadkach nowa funkcjonalność wiąże się z mniejszą lub większą modyfikacją systemu.

Kiedyś słyszałem rozmowę dwóch programistów, podczas której jeden stwierdził, że naprawa błędów jest jak walka z Hydrą, usuniesz jedną głowę (błąd), a na jej miejscu wyrośnie 10 nowych. Testerzy manualni w większości przypadków nie są w stanie sprawdzić wszystkich miejsc, na które wpływ mogła mieć “drobna” modyfikacja. Nawet programiści, którzy tworzą ten system nie muszą wiedzieć o wszystkich miejsca, na które ich drobna zmiana może mieć wpływ. Testy automatyczne nie narzekają i nie wybierają, tylko testują wszystko “jak leci”.

TO JESZCZE RAZ, GDZIE TA OSZCZĘDNOŚĆ?

Chwilę wcześniej stwierdziłem, że wraz ze wzrostem rozmiarów systemu rośnie zapotrzebowanie na testerów i to dotyczy obu rodzajów testów. Różnica bierze się z tempa wzrostu tej liczby. Dokładnych wykresów niestety nikt nie jest w stanie przedstawić, ponieważ systemy szczególnie na początku dość mocno się zmieniają, zdarza się, że cała architektura systemu jest przebudowywana. Z tego powodu, pokrywanie wszystkiego od początku testami automatycznymi zamienia się w walkę z wiatrakami. Z kolei w przypadku testów manualnych kładzie się większy nacisk na przetestowanie dokładne nowych funkcjonalności, pozostałe w zasadzie przeklikując.

Możemy za to porównać idealne przypadki. W takiej abstrakcyjnej sytuacji, testerzy manualni i automatyczni chcą wykonywać dokładnie tą samą pracę. Podczas gdy zapotrzebowanie na testerów manualnych rośnie liniowo, to tendencja wzrostu liczby testerów automatycznych będzie bliższa logarytmicznej. Poniższy wykres jest tylko ideologiczny. W praktyce próbuje się znaleźć złoty środek pomiędzy pokryciem systemu testami automatycznymi, a testami manualnymi.

Biorąc pod uwagę niektóre metodyki pracy programistycznej takie jak TDD (ang. Test Driven Development), część testów automatycznych, w tym przypadku uruchamianie testów jednostkowych, otrzymuje się w zasadzie za darmo. Pozostaje kwestia dostosowania narzędzia do uruchomienia testów.

Podsumowując moje “krótkie” uzupełnienie: zdrowe i przemyślane podejście do testów automatycznych skutkuje ograniczeniem kosztów w dłuższej perspektywie, zwiększeniem jakości kodu i krótszym czasem reakcji w przypadku pojawienia się błędów.

UZUPEŁNIENIE JUŻ ZA NAMI, A GDZIE GŁÓWNE DANIE?

Rozwinięcie mojego toku rozumowania, zajęło mi zdecydowanie więcej niż się spodziewałem. Pozwól, że na tym dzisiaj zakończę i nie będę Was dłużej męczyć. Obiecuję, że w następnym artykule przejdę w końcu do technicznych aspektów.

Mam jednak nadzieję, że ponownie lub chociaż po raz pierwszy udało mi się Was zaciekawić i razem ze mną, z niecierpliwością będziecie czekali na kolejną część.

W komentarzach zachęcam do uwag i propozycji, jakie artykuły by Was interesowały, np. kwestia pracy w TDD.

FacebookTwitterGoogle+LinkedIn