AI a testerzy manualni

Czy już robić uprawnienia SEP?

No dobra, to co z tym AI? Testerzy manualni powinni już rezerwować kurs na uprawnienia SEP, ćwiczyć układanie płytek i nerwowo sprawdzać czy hydraulik przyjmuje juniorów? Czy może jeszcze przez chwilę da się żyć z testowania oprogramowania?

Nareszcie mogę udzielić najbardziej QA-owej odpowiedzi świata: to zależy. I zależy całkiem mocno.

Jeżeli przez “testera manualnego” rozumiemy człowieka, który dostaje gotowy przypadek testowy, wykonuje krok 1, 2, 3, porównuje rezultat z rubryką “Expected result” i zmienia status na Pass albo Fail, to mam złą wiadomość. Taka część pracy rzeczywiście jest bardzo podatna na automatyzację. Tyle ten że problem nie zaczął się wraz z chatem GPT. Powtarzalne wykonywanie dokładnie opisanych czynności było kandydatem do automatyzacji długo przed obecnym boomem na generatywną AI (albo idealnym miejscem na zatrudnienie tańszego studenta żeby złapał pierwsze doświadczenie). Jeżeli natomiast jako tester analizujemy wymagania, uwzględniamy kontekst biznesowy, potrafimy ocenić ryzyko, eksplorujemy system i pytamy “a co się stanie, jeśli…?”, sytuacja robi się znacznie ciekawsza. I nie, nie oznacza to, że można zignorować AI i spokojnie przeczekać tę modę.

Najpierw ustalmy, o jakim AI mówimy

W tym tekście przez “AI” będę najczęściej rozumiał generatywną AI, przede wszystkim modele generujące tekst i kod oraz zbudowane na nich chatboty i agentów. Nie każde AI jest LLM-em, nie każdy system oparty na uczeniu maszynowym jest chatbotem i wrzucanie wszystkiego do jednego worka tylko utrudnia rozmowę.

Czy GenAI jest “tylko narzędziem”? Tak, w tym sensie, że nadal jest technologią używaną przez ludzi do wykonania określonej pracy, a nie magicznym współpracownikiem posiadającym intuicję, intencje i tajemniczą wiedzę o naszym projekcie. Ale porównanie go jeden do jednego z Postmanem też trochę kuleje. Postman raczej nie wygeneruje ci z pełnym przekonaniem endpointu, którego nigdy nie było, a następnie nie dopisze eleganckiego wyjaśnienia, dlaczego na pewno działa. Generatywna AI, o zgrozo, może. Czyli tak: AI potrafi nas “okłamać i nawet się nie zająknąć” jeśli pozwolimy sobie na mały skrót językowy. Technicznie rzecz biorąc, nie kłamie. Praktycznie rzecz biorąc, musisz sprawdzać wynik. Dla testera brzmi znajomo, prawda?

AI już naprawdę potrafi pisać testy

Nie ma sensu pocieszać się argumentem, że “AI tylko podpowiada tekst”. Ten etap mamy za sobą. A więc tak: scenariusz “AI napisze test, uruchomi go i poprawi kod” nie jest już prezentacją przyszłości przygotowaną przez dział sprzedaży. Takie możliwości są dostępne w realnych narzędziach (lepiej lub gorzej ale jednak). Jednocześnie sama dokumentacja np. GitHuba ostrzega, że wygenerowane testy mogą nie pokrywać wszystkich scenariuszy i powinny zostać przejrzane oraz uzupełnione. I właśnie w tej różnicy — pomiędzy wykonaniem testu a ustaleniem, co właściwie należało przetestować — zaczyna się najciekawsza część tej historii.

Tester manualny nie powinien być definiowany przez myszkę

Określenie “tester manualny” od dawna jest trochę niefortunne, bo opisuje narzędzie wykonania pracy zamiast samej pracy. Tester nie jest przecież specjalistą od ręcznego przesuwania kursora (tzn. powinien być, ale o tym kolejnym razem). Nawet aktualny, znienawidzony syllabus ISTQB opisuje rolę testera jako skupioną na analizie testów, projektowaniu, implementacji i wykonaniu. Wymieniając i podkreślając myślenie analityczne i krytyczne, wiedzę techniczną oraz wiedzę domenową potrzebną do rozumienia użytkowników i biznesu. To dość daleko od:

kliknij przycisk “Zapisz” i sprawdź, czy pojawił się komunikat.

W prawdziwym projekcie trzeba najpierw zdecydować, czy przycisk “Zapisz” jest w ogóle interesującym miejscem do testowania. Może problem występuje dopiero wtedy, gdy dwóch użytkowników edytuje ten sam rekord. Może dane zapisują się poprawnie, ale system wysyła błędną informację do innej usługi. Może po trzech dniach ktoś uruchamia proces wsadowy i dopiero wtedy wszystko wybucha. Test case opisujący happy path może być perfekcyjny i jednocześnie całkowicie bezużyteczny. AI jest w stanie napisać takie scenariusze, ale najpierw musi dostęp do kontekstu, źródeł, wiedzy tajemnej i ‘ustaleń na ostatnim callu’. A z tym zaczynają się schody.

I tu wchodzi Staszek, cały na biało

Każdy odpowiednio stary system ma gdzieś swojego Staszka. Staszek pracuje przy nim od trzydziestu lat i wie, że dokumentacja wprawdzie mówi jedno, diagram architektury drugie, a confluence został nawet zaktualizowany w zeszłym kwartale, ale klient z Belgii od 2011 roku korzysta z pewnej funkcji zupełnie inaczej, niż przewidywał jej autor i bug istnieje na tej linii jako ficzer. Staszek wie też, że jeśli zmienisz jedno pole w module A, koniecznie trzeba sprawdzić raport w module D, chociaż na diagramie pomiędzy nimi są trzy usługi i pozornie nie mają ze sobą nic wspólnego.

Model językowy nie wywnioskuje tego telepatycznie. Może przeszukać repozytorium. Agent może analizować kod i historię zmian. Możemy podłączyć dokumentację, system zgłoszeń, logi czy inne źródła. Ale informacja, której “nigdzie nie ma, zapytaj Staszka”, nadal pozostaje problemem.

Zresztą Staszek jako jedyny żywy nośnik wiedzy domenowej też jest problemem. Jeśli proces działa tylko dlatego, że jedna osoba pamięta zależności sprzed piętnastu lat, nie jest to argument za utrzymywaniem wiedzy plemiennej. To alarm dotyczący jakości procesu. AI tego problemu nie usuwa. Może za to sprawić, że wreszcie zaczniemy go widzieć.

Co więc jest naprawdę zagrożone?

Najbardziej zagrożona nie jest “manualność”. Najbardziej zagrożona jest powtarzalność. Im bardziej twoją pracę można opisać jako:

“weź jednoznaczne wejście → wykonaj dobrze zdefiniowaną serię kroków → sprawdź łatwo mierzalny wynik”,

tym łatwiej będzie coraz większą część tej pracy przekazać automatyzacji wspomaganej przez AI. Nie oznacza to, że człowiek przestaje być potrzebny. Oznacza, że płacenie człowiekowi głównie za wykonanie powtarzalnej procedury będzie coraz trudniejsze do uzasadnienia.

Granica między manualem a automatyzacją będzie się zacierać

Tu akurat trudno mi znaleźć powód do nostalgii. Jeżeli wygenerowanie pierwszej wersji testu w Playwright wymaga kilku zdań opisujących zachowanie, a nie napisania wszystkiego od zera, próg wejścia w automatyzację spada. To nie oznacza, że każdy tester manualny za pół roku zostanie programistą. Wygenerowanie kodu i odpowiedzialne utrzymywanie automatyzacji to nadal dwie różne rzeczy. Ale tester, który dotąd omijał kod szerokim łukiem, może coraz częściej być w stanie:

• wygenerować prosty test i zrozumieć, co on sprawdza;
• uruchomić go i przeanalizować błąd;
• poprawić selektor albo asercję;
• użyć API zamiast przeklikiwać GUI;
• poprosić AI o pomoc w zapytaniu SQL, a potem zweryfikować rezultat;
• przygotować małe narzędzie rozwiązujące konkretny problem w testach.

I tutaj rzeczywiście podział na “manuala” i “automata” zaczyna wyglądać trochę sztucznie. Nie dlatego, że wszyscy będą doskonałymi programistami. Dlatego, że koszt technicznego wejścia w automatyzację maleje. Jednocześnie rośnie znaczenie umiejętności oceny tego, co zostało wygenerowane. Kod, którego nie rozumiesz, nie staje się bezpieczny tylko dlatego, że napisał go model.

Czyli jednak przeżyjemy?

Prawdopodobnie tak. Ale nie wszyscy będziemy robić dokładnie to samo, co pięć lat temu. AI może napisać przypadki testowe. Może wygenerować kod. Może uruchomić automatyczne testy, przeanalizować repozytorium i poprawiać błędy. Udawanie, że nic się nie zmienia, byłoby równie rozsądne jak zapewnianie w 2005 roku, że automatyzacja nigdy nie wpłynie na testy manualne a w ogóle to jest zbędna. Z drugiej strony skok od “AI potrafi wygenerować test” do “tester jest niepotrzebny” jest ogromny.

Jeżeli twoją główną wartością było wykonywanie instrukcji krok po kroku, AI powinno być dla ciebie sygnałem ostrzegawczym. Jeżeli natomiast potrafisz spojrzeć na system szerzej, rozumiesz ludzi, biznes, architekturę i ryzyko, umiesz eksplorować nieznane oraz wykorzystujesz narzędzia zamiast budować swoją tożsamość wokół jednego sposobu wykonywania testów, to nie widzę powodu, żeby już kupować poziomicę.

Chociaż umiejętność położenia prosto płytek też podobno zawsze się przydaje, ta jedna krzywa płytka w łazience kłuła mnie w oczy przez dobrych kilka lat mimo, że nikt poza mną jej nie widział…