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żą:

  • krótszy czas wykonania pojedynczego testu,
  • są tak samo dokładne przy każdym wykonaniu,
  • mogą być uruchamiane 24h/7,
  • testy i analiza wyników mogą być wykonywane niezależnie.

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

  • test automatyczny trzeba najpierw napisać, żeby się wykonał – co opóźnia rozpoczęcie testowania i znacznie zwiększa koszt przypadający na pierwszy test,
  • modernizacja aplikacji może pociągnąć za sobą również potrzebę zmiany testów automatycznych,
  • dłuższy czas potrzebny na analizę wyników testów – w przypadku testów manualnych analiza przebiega równolegle z testem,
  • 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ż:

  • testów jest dużo więcej niż manualnych,
  • 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.

Testy automatyczne vs manualne Testy automatyczne vs. manualne

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