Charakterystyka testów automatycznych
Dokładność:
Testy automatyczne w przeciwieństwie do testów manualnych nie radzą sobie z doza niejasności. W przypadku testów automatycznych kod musi być pisany z precyzją i szczegółami.
Utrzymanie: Nie ma sensu wykonywać testów dla kodu, który nie uległ żadnej zmianie, więc należy zawsze oczekiwać, ze prawie przy każdym cyklu testowania aplikacja była modyfikowana. Oznacza to, że przypadki testowe musza być modyfikowane w celu odzwierciedlenia zmian dokonany w aplikacji. Dlatego testy automatyczne wymagają stałego utrzymania.
Wrażliwość na zmiany:
Z jednej strony skrypty musza być dokładne i precyzyjne z drugiej im bardziej szczegółowy skrypt tym trudniejsze staje się utrzymanie naszych testów. System automatyzacji powinien być zbudowany w sposób modułowy, tak że niektóre fragmenty zawierają drobne szczegóły a skrypty są jedynie złożeniem tych fragmentów. Szczegóły należy rozłozīć na klika komponentów (metody, klasy, moduły itp.) które można modyfikować lub zastępować innymi, bez wpływu na pozostałe elementy.
Obsługa niepowodzeń:
Podczas pierwszego wykonania testu automatycznego często napotykamy nieoczekiwane warunki, które wymagają poprawienia skryptu, aż test zakończy się sukcesem. Jednak nawet później mogą wystąpić sytuacje powodujące niepowodzenia testu, w tym:
- Nowy błąd w produkcie (regresja)
- Uzasadniona zmiana w produkcie, której zespół testowy nie był świadomy
- Problem środowiskowy (awaria sieci, brak pamięci itd.)
- Nieprzewidziane zdarzenie w produkcie, np. popup przypominający o kopii zapasowej, które wpływa na przebieg testu — takie sytuacje to w rzeczywistości błędy w samym teście
- Ingerencja innych osób lub testów w środowisko testowe (np. zmiana danych współdzielonych), co prowadzi do problemów izolacji wskazujących na braki w architekturze infrastruktury testowej
Tester manualny może rozpoznać i obsłużyć takie sytuacje (np. obejściem lub ponownym wykonaniem kroków), natomiast test automatyczny w przypadku nieoczekiwanych zdarzeń po prostu kończy się błędem, bo komputer nie potrafi samodzielnie rozpoznać kontekstu.
Automatyzacja może obsłużyć niektóre znane problemy środowiskowe, ale należy to robić ostrożnie — zbyt wiele obejść w skryptach obniża deterministyczność i wiarygodność testów.
Mechanizmy automatycznego powtarzania testów zakończonych niepowodzeniem to zła praktyka: każda porażka jest sygnałem wymagającym analizy i usunięcia przyczyny. Powtarzanie testów bez naprawy problemów prowadzi do nierzetelnej automatyzacji i może ukryć niedeterministyczne błędy w produkcie.
Długoś przypadku testowego:
Testy manualne często są długie i obejmują wiele weryfikacji naraz, bo tester może pominąć drobne niepowodzenia i kontynuować test. Automaty nie potrafią tak działać — gdy napotkają błąd, nie wiedzą czy kontynuować, powtarzać czy przerwać test.
Choć niektóre biblioteki automatyzacji pozwalają na kontynuowanie testu po błędzie, brak „intuicji” automatu sprawia, że próba zautomatyzowanego decydowania o kontynuacji obniża wiarygodność testów. Dlatego bardziej niezawodne jest podejście stosowane w większości bibliotek (np. unit test frameworks), gdzie każde nieoczekiwane zdarzenie kończy natychmiast cały przypadek testowy i przechodzi do kolejnego.
Automatyczne testy powinny być krótkie, proste i weryfikować wyłącznie jedną rzecz, gdyż w przeciwnym wypadku nawet najmniejsze niepowodzenie może zablokować wykonanie dużo istotniejszych fragmentów testu. prawie każda weryfikacja powinna mieć swój własny przypadek testowy.
Zalezności między testami:
W testach manualnych czasem dopuszcza się zależności między przypadkami („wykonaj X po Y”). W automatyzacji jest to niepożądane, ponieważ porażka jednego testu nie powinna wpływać na inne. Każdy test automatyczny powinien zawsze zaczynać się od dobrze znanego, kontrolowanego stanu początkowego. Dlatego projektowanie zależnych testów automatycznych jest odradzane — niezależność testów zapewnia ich niezawodność i umożliwia równoległe uruchamianie.
Rejestrowanie i zbieranie dowodów:
Tester manualny, napotykając nieoczekiwany problem, zwykle od razu analizuje go i zgłasza wraz z kontekstem, krokami i dodatkowymi informacjami. Automatyczne testy działają inaczej — traktują każdy nieoczekiwany warunek jako niepowodzenie, ale nie mają zdolności do oceny natury problemu.
Automaty zwykle uruchamiane są bez nadzoru, a analiza niepowodzeń następuje później, gdy część istotnych dowodów może być już utracona. Dlatego w przypadku błędów trudnych do odtworzenia szczególnie ważne jest gromadzenie pełnych logów oraz dodatkowych dowodów (zrzuty ekranu, nagrania wideo, migawki baz danych, HTML stron itp.), które umożliwią późniejsze badanie problemu.
Automatyczne powiązanie systemu testów z systemem raportowania błędów (tak aby każde niepowodzenie automatycznie zgłaszało defekt) nie jest zalecane — nie wszystkie niepowodzenia są rzeczywistymi błędami, a automatyczne raportowanie może prowadzić do zalewu fałszywych zgłoszeń i dodatkowego obciążenia przy ich analizie i zarządzaniu.
References
- Arnon Axelrod, Automatyzacja testów. Kompletny przewodnik dla testerów oprogramowania, PWN 2020, s. 16-25.