Automatyzacja testów jest dziś standardem w wielu projektach IT, zwłaszcza tam, gdzie liczy się szybkość dostarczania zmian i jakość oprogramowania. Frameworki takie jak Selenium, Playwright czy Cypress umożliwiają testerom i programistom tworzenie testów automatycznych, które przyspieszają wykrywanie błędów i redukują czas potrzebny na manualne testowanie.
Zespoły coraz częściej starają się automatyzować testy, lecz mimo że zwykle przynosi to wiele korzyści, nie zawsze jest opłacalnym rozwiązaniem. Są sytuacje w których koszty stworzenia, utrzymania i aktualizacji testów automatycznych mogą przewyższać korzyści z ich wdrożenia.
W tym artykule przyjrzymy się, w jakich sytuacjach automatyzacja testów może nie być najlepszym pomysłem i dlaczego czasami lepiej postawić na tradycyjne podejście do testowania.
Czyli – kiedy nie automatyzować testów?
1. Krótkotrwałe projekty
Wyobraźmy sobie, że testujemy stronę WWW pod kampanię promocyjną, która będzie działała jedynie miesiąc. Czy warto automatyzować testy w takim projekcie? Prawdopodobnie nie.
Automatyzacja wymaga czasu na przygotowanie frameworku i napisanie skryptów. W krótkich projektach koszt wdrożenia takich testów może być wyższy, niż korzyści płynące z ich uruchomienia i utrzymania. Takie testy po prostu się „nie zwrócą”.
W takich przypadkach manualne testy mogą być bardziej efektywnym rozwiązaniem, pozwalając na szybsze pokrycie kluczowych obszarów aplikacji.
2. Aplikacja w fazie dynamicznego rozwoju
Czyli innymi słowy – aplikacja, gdzie często zmieniające się wymagania. Może to być np. mała apka MVP, gdzie opisy kluczowych funkcjonalności zmieniają się co sprint. W takich przypadkach testy automatyczne mogą wymagać częstych aktualizacji i ich koszt utrzymania może być zbyt wysoki, by była to opłacalna inwestycja.
Jak w powyższym przykładzie, tutaj powinny wystarczyć testy manualne.
3. Brak stabilnego środowiska
Niestety, zdarza się. Testy wymagają środowiska, na którym wyniki testów mogą być powtarzalne i przewidywalne. Jeśli środowisko testowe jest niestabilne lub często zmienia się jego konfiguracja (lub po prostu nie działa), to wdrażanie automatyzacji mija się z celem.
Oczywiście można spróbować poradzić sobie w tej sytuacji, np. można używać mocków, które emulują działanie zewnętrznych systemów lub API. Można też po prostu poczekać z testami do momentu, aż środowisko osiągnie większą stabilność.
4. Złożone testy wizualne
Testy wizualne to niezbyt częsty rodzaj testów, ale potrafią one być wymagające
Testy wizualne, takie jak ocena estetyki interfejsu czy UX, są trudne do pełnej automatyzacji. Narzędzia do testowania wizualnego mogą pomóc, ale ich konfiguracja bywa skomplikowana.
