Jak działa automatyzacja testów?
Zanim napiszę szerzej o mitach dotyczących procesu automatyzacji testowania oprogramowania, przyjrzyjmy się bliżej, jak tworzymy testy automatyczne. Na początek określamy obszary, które potrzebujemy przetestować automatycznie, i zastanawiamy się, jaką wartość biznesową chcemy z ich pomocą uzyskać oraz definiujemy przypadki testowe. Czy ma to być sprawdzenie wydajności systemu? A może potrzebujemy szybkiej informacji o jakości tworzonego produktu? Gdy już ustalimy cel testów automatycznych, zajmujemy się aspektem technicznym, to znaczy dokonujemy wyboru narzędzia do testowania aplikacji, tworzymy środowisko testowe oraz skrypty niezbędne do wykonania testów. Po uruchomieniu testów jesteśmy w stanie dokonać analizy rezultatów i zweryfikować, czy udało się uzyskać założoną na początku testów wartość biznesową.
Co do samej zasady działania deterministycznych testów zautomatyzowanych, jest ona stosunkowo prosta. Najpierw aplikację wprowadzamy w pewien stan początkowy umożliwiający wykonanie akcji, którą chcemy przetestować, na przykład sprawdzamy, jak dana funkcjonalność będzie się zachowywać, gdy jednocześnie będzie z niej korzystać 1000 użytkowników. Weryfikacja opiera się na porównaniu oczekiwanych założeń z aktualnym stanem aplikacji.
Przeczytaj również: Test-Driven Development na co dzień
Automatyzacja testowania – mity
1. Testy automatyczne pozwalają przeprowadzić dowolny test
Jednym z najbardziej powszechnych mitów dotyczących automatyzacji testów jest przekonanie, że można zautomatyzować każdy test. Zastanówmy się jednak: czy w praktyce jest to możliwe? Jak zaznacza ISTQB (International Software Testing Qualifications Board), organizacja certyfikacyjna w dziedzinie testowania jakości oprogramowania, testowanie to proces nieskończony, a zatem nie jesteśmy w stanie przewidzieć i przetestować wszystkiego.
Automatyzacja testów pozostaje niezastąpiona przy wykonywaniu testów wydajności, obciążenia i testów przeciążających. Są jednak aspekty, które trudno poddać automatyzacji. Część testów niefunkcjonalnych, czyli związanych z estetyką, przejrzystością interfejsu użytkownika czy czytelnością, oparta jest na osobistych odczuciach. Nie jesteśmy w stanie ustalić dla nich warunków wyjściowych i oczekiwanego rezultatu. Kwestia wyglądu czy przejrzystości może więc podlegać jedynie ocenie ludzkiego oka. Podobnie nie można zautomatyzować testów dostępności, które polegają na ocenie oprogramowania pod kątem przystosowania dla osób niepełnosprawnych.
Podsumowując, skoro są testy, których nie jesteśmy w stanie zrealizować automatyzacją testów, nie możemy zastąpić testów manualnych testami automatycznymi, jak głosi kolejny powszechny mit. Będą obszary, które wymagają manualnego sprawdzenia, o czym piszę niżej.
Przeczytaj również: Testy BDD – na czym polegają i czy na prawdę są potrzebne?
2. Dzięki automatyzacji testów można zrezygnować z testowania manualnego
Stwierdzenie to jest podobne do powszechnego kiedyś przekonania, że telewizja całkowicie zastąpi radio. Dziś widzimy, że media takie jak radio, telewizja i Internet współistnieją i uzupełniają się. Podobnie jest z testami automatycznymi i manualnymi. Ogromną zaletą automatyzacji jest jej powtarzalność – zakładając poprawną implementację testów, możemy mieć pewność, że testy automatyczne będą wykonane zawsze w ten sam, odtwarzalny sposób. Dodatkowo, w przeciwieństwie do człowieka, są w stanie pracować nieustannie – bez przerwy na kawę, sen czy weekendowy odpoczynek. Brakuje im jednak pewnego pierwiastka, który pozwala na efektywne przetestowanie aplikacji: inteligencji, intuicji oraz wyobraźni.
W sposób manualny jesteśmy w stanie wykonać znaczną część testów, które ocenią, w jakim stopniu aplikacja spełnia zarówno wymagania funkcjonalne, jak i niefunkcjonalne. Testy manualne będą więc potrzebne, bo zawsze będą obszary wymagające wiedzy i bezpośredniego zaangażowania testera oprogramowania. Będą to takie obszary testów jak testy użyteczności, dostępności i bezpieczeństwa. Automatyzacja stanowi uzupełnienie testów manualnych, ale nie jest w stanie zastąpić np. testów eksploracyjnych oraz techniki opartej na zgadywaniu błędów, bazującej na doświadczeniu testera zarówno w kontekście testowanego produktu, jak i narzędzi, które zostały wykorzystane do jego stworzenia.
Przeczytaj również: minimalistyczny przypadek testowy
3. Rola testów automatycznych to znajdowanie wielu defektów
Wbrew powszechnej opinii testy automatyczne nie wykazują wielu błędów. Ktoś może zapytać: „Ale jak to? Czy nie to właśnie chcemy uzyskać poprzez automatyzację testów?” Oczywiście jest to jeden z aspektów, do których dążymy. W przypadku testów automatycznych ważniejsza jest jednak nie ilość, lecz jakość. Przytaczając konkretny przykład, testy automatyczne przyniosą nam informację o defektach, które pojawiły się w istniejących funkcjonalnościach po zmianie kodu. Są to tak zwane testy regresji, których zadaniem jest sprawdzenie tego, czy najnowsze zmiany oprogramowania, środowiska i konfiguracji nie wpłynęły negatywnie na rozwijany produkt. Zautomatyzowane testy regresji pozwalają zastąpić manualną pracę zespołów developerskich, która w zależności od złożoności oprogramowania zajęłaby wiele godzin, dni, a nawet tygodni. Wraz z każdym testem automatycznym zwiększa się zaufanie do tworzonego oprogramowania i chociaż nie wykażą one wielu błędów, pozwolą oszczędzić czas i pracować nad jakością produktu – a przecież to ona jest w ogólnym rozrachunku najważniejsza.
4. Każdy przypadek testowy należy zautomatyzować, jeśli to możliwe
Jesteśmy już świadomi, że nie wszystko można zautomatyzować i że testy automatyczne w pewnych obszarach nie zastąpią testów manualnych. Skoro jednak identyfikujemy wiele przypadków testowych, które można zautomatyzować, to czy w każdym przypadku warto?
Są sytuacje, gdy trzeba działać szybko i przetestować daną funkcjonalność bez angażowania dodatkowych środków czy narzędzi – z czym wiąże się niejednokrotnie wdrażanie testów automatycznych. Aby odpowiedzieć na pytanie o zasadność stosowania testów automatycznych dla wszystkich przypadków testowych, posłużę się cytatem Rogera Needhama, dyrektora Centrum Badań Microsoft:
„Automatyzacja to zastępowanie tego, co działa, czymś, co prawie działa, ale jest szybsze i tańsze”.
To zdanie przypomina o dwóch podstawowych warunkach, które wskazują na zasadność automatyzacji testów:
- wykonanie automatycznych testów powinno być szybsze niż manualna weryfikacja zachowania systemu
- koszt zaprogramowania testu nie powinien przekraczać zysku, jaki uzyskamy z jego automatyzacji
Przed podjęciem decyzji o automatyzacji testów warto więc wziąć pod uwagę liczne aspekty, takie jak koszt narzędzi i czas ich implementacji oraz to, ile czasu potrzebowalibyśmy na testy manualne. To powinno dać odpowiedź na pytanie o zasadność wprowadzenia testów automatycznych pod kątem biznesowym.
Podsumowanie
Pomimo wielu krążących mitów automatyzacja testów stopniowo zyskuje na popularności, a cel jej stosowania jest coraz lepiej rozumiany. Wciąż jednak konieczne jest rozwiewanie wielu wątpliwości z nią związanych, a powracający temat mitów dotyczących testów automatycznych jest dowodem na to, jak wiele jeszcze jest do zrobienia w kwestii odczarowania powszechnych, błędnych przekonań. Mam nadzieję, że udało mi się rozwiać kilka z nich, a artykuł ten przyczyni się do dyskusji na temat testów automatycznych, które – jakkolwiek by na to nie spojrzeć – stanowią przecież znaczną pomoc dla testerów oprogramowania w dostarczaniu wysokiej jakości produktu.
