Koncepcja Test Driven Development (TDD) zakłada tworzenie kodu poprzedzone napisaniem testu. Test jest w tym przypadku jednostkowy i w pełni zautomatyzowany pod kątem uruchomienia. W dobie prostego pisania testów automatycznych po GUI, zbliżonych prostotą do tworzenia testów jednostkowych, możemy czerpać z TDD do tworzenia testów regresji na poziomie front-endu.
Proces
Proces jest uproszczony i opisujemy go poniżej. Do zadania testera eksploracyjno-automatyzującego należeć będzie:
- eksploracja aplikacji z wypisaniem najważniejszych funkcji i procesów,
- określenie wagi poszczególnych obszarów,
- weryfikacja poprawnego działania badanych funkcji i procesów,
- napisanie testów automatycznych z naciskiem na scenariusze o najwyższym priorytecie i najważniejszych funkcji,
- uruchamianie testów i określenie czy działają.
W efekcie końcowym otrzymujemy raport z testów eksploracyjnych oraz gotowy zestaw testów regresji. Testy automatyczne oczywiście powinny trafić w proces CI/CD i być wersjonowane tak, aby zapewnić powiązanie kod aplikacji – kod automatyzacji. W kolejnych wydaniach cykl testowy rozpoczyna się od uruchomienia automatycznej regresji, a następnie przechodzi się do analizy wyników oraz testów dla nowych funkcjonalności oraz refaktoryzowanego kodu. Każda zmiana w systemie powinna być od razu analizowana pod kątem opłacalności jej automatyzacji.
Odpowiedzialność
Takie podejście wymaga dużych umiejętności po stronie testera – nie tylko mocnej zdolności eksploracji, ale i umiejętności tworzenia skryptów testowych. Ze względu na prostotę współczesnej automatyzacji nie jest to jednak zestaw kompetencji szczególnie kosztowny. Mid tester + (12k – 15k PLN) powinien być w stanie zrealizować takie zadania samodzielnie.
Jednak nie można zapomnieć, że długofalowo zbudowanie całego procesu w oparciu o jedną osobę jest ryzykowne. Dla większych i dłuższych projektów będzie ona potrzebowała zespołu złożonego z juniorów i midów lub ewentualnie jednej osoby o zbliżonych kompetencjach (mid+) do przeglądu kodu oraz rotacji zadań w celu uniknięcia wypalenia zawodowego.
Nakłady dodatkowe
Pisanie testów automatycznych będących rozwinięciem wcześniej przeprowadzonych testów eksploracyjnych wydłuża czas pracy o około 100% do 200% w stosunku do czasu poświęconego na eksplorację. Niemniej, dzięki wykorzystaniu AI i self-healingu, utrzymanie testów powinno być pomijalnie małe i zawrzeć się w zakresie eksploracji. Oczywiście pod warunkiem, że zachowamy systematyczność przeglądów kodu i wyników oraz wysoką jakość kodu automatyzacji.
Podsumowanie
Eksplorujemy oprogramowanie, by się go uczyć, zrozumieć, czy działa i co warto zautomatyzować. Automatyzujemy zaś po to, by nie tracić czasu na ponowne sprawdzanie elementów, które nie zostały zmienione lub są zadeklarowane jako niezmienione.
Końcowym efektem jest dobra weryfikacja, lekka dokumentacja i skuteczna automatyzacja. To podejście, które doskonale sprawdza się w zwinnych iteracjach, choć z powodzeniem można je wdrożyć w dowolnej metodologii prowadzenia projektów.
Redakcja