Testy eksploracyjne + testy automatyczne

Testy eksploracyjne + testy automatyczne
Testowanie eksploracyjne to najsilniejsza metoda wykrywania defektów i szybkiej oceny oprogramowania. Automatyzacja testów to skuteczne narzędzie kontroli regresji. Choć ich połączenie daje silną funkcjonalną weryfikację jakości oprogramowania, to wiąże się jednak z kosztami.

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.

Optymalna metoda testowania w moim projekcie to:
Optymalna metoda testowania w moim projekcie to:
0 %
Testowanie eksploracyjne
0 %
Testowanie automatyczne
0 %
Testowanie eksploracyjne + testowanie automatyczne
0 %
Inne, np. testowanie formalne z przypadkami testowymi
0 %
Testowanie? A komu to potrzebne?
Łącznie głosów: 0

To powinno Cię zainteresować