Czemu manualne testowanie wcale nie jest „mniej wartościowe”?

W ogłoszeniach o pracę widać to od lat. Tester automatyzujący dostaje wyższe widełki, ma jaśniejszą ścieżkę awansu i częściej trafia na listę stanowisk, których firma broni przy cięciach. Tester manualny bywa opisywany jako etap przejściowy, coś, z czego się wyrasta. W rozmowach branżowych pojawia się nawet określenie „klikacz”, używane bez złych intencji, ale robiące swoje.

Tyle że rynek nie płaci za sposób wykonania testu, tylko za informację, którą test przynosi. A część najcenniejszych informacji o produkcie nie da się zdobyć skryptem, bo skrypt sprawdza wyłącznie to, co ktoś wcześniej umiał przewidzieć. Ten tekst porządkuje, gdzie testowanie manualne realnie wygrywa, gdzie jest marnowaniem pieniędzy i jak rozpoznać, po której stronie stoicie.

Skąd wzięła się hierarchia, której nikt nie ustalił

Mit o niższej wartości testów manualnych ma dwa źródła i oba są zrozumiałe. Pierwsze to koszt. Test automatyczny raz napisany wykonuje się setki razy prawie za darmo, a każdy przebieg manualny kosztuje tyle samo co poprzedni. Przy regresji liczonej w tysiącach kroków ta arytmetyka jest bezlitosna i nie ma sensu z nią dyskutować.

Drugie źródło jest mniej wygodne. W wielu organizacjach testowanie manualne było przez lata prowadzone źle: jako odtwarzanie długich list kroków spisanych rok wcześniej, bez zrozumienia produktu i bez prawa do zadawania pytań. Taka praca faktycznie jest mało wartościowa, ale nie dlatego, że jest manualna. Jest mało wartościowa, bo została pozbawiona myślenia. Automatyzacja tego samego procesu daje ten sam efekt szybciej, czyli szybciej dowozi bezużyteczną informację.

Z tego pomieszania wziął się skrót, w którym „manualne” zaczęło znaczyć „proste”, a „zautomatyzowane” zaczęło znaczyć „dojrzałe”. W praktyce dojrzałość organizacji poznaje się po czymś innym: po tym, czy potrafi świadomie zdecydować, co automatyzować, a czego nie.

Fałszywa wojna, w której obie strony przegrywają

Stawianie testów manualnych naprzeciw automatyzacji ma tyle sensu, co porównywanie młotka z wiertarką. To narzędzia do innych zadań, a nie konkurencyjne szkoły. Automatyzacja odpowiada na pytanie, czy to, co działało wczoraj, działa nadal. Testowanie manualne odpowiada na pytanie, czy to, co zbudowaliśmy, w ogóle ma sens dla człowieka po drugiej stronie ekranu.

Widać to najlepiej po kosztach pomyłki. Brak automatyzacji regresji kosztuje czas i opóźnia wydania. Brak testowania manualnego kosztuje inaczej: produkt przechodzi wszystkie testy, a i tak generuje zgłoszenia od użytkowników, bo formularz jest logicznie poprawny i praktycznie nie do przejścia. Żaden skrypt nie zgłosi, że proces zakupu jest męczący, bo skrypt nie ma cierpliwości do stracenia.

Trzy obszary, w których człowiek wygrywa i długo będzie wygrywał

Testowanie eksploracyjne. To praca, w której tester jednocześnie projektuje test, wykonuje go i uczy się produktu, a każdy kolejny krok wynika z tego, co zobaczył przed chwilą. Skrypt tego nie odtworzy, bo skrypt nie ma hipotez. Nie jest przypadkiem, że najbardziej kosztowne błędy w projektach, które prowadzimy, wychodzą właśnie wtedy, gdy ktoś zapyta „a co, jeśli użytkownik zrobi to w innej kolejności”.

Ocena tarcia i użyteczności. Automat potwierdzi, że przycisk istnieje, jest widoczny i reaguje na kliknięcie. Nie powie, że etykieta jest myląca, że komunikat błędu nie mówi, co zrobić, ani że w kroku płatności użytkownik traci pewność, czy transakcja przeszła. Te rzeczy widać tylko z perspektywy kogoś, kto ma cel, a nie listę asercji.

Sprawdzanie zgodności z intencją biznesu. Wymaganie może być zaimplementowane dokładnie tak, jak je zapisano, i jednocześnie rozminąć się z tym, o co chodziło zamawiającemu. Wyłapanie tej różnicy wymaga rozmowy, kontekstu i wątpliwości, czyli rzeczy nieobecnych w definicji przypadku testowego.

Model, który działa w większości firm

Podział, który sprawdza się niezależnie od branży, opiera się na jednym pytaniu: czy scenariusz jest już stabilny. Jeśli tak, należy do automatu i powinien tam trafić najszybciej, jak się da. Jeśli nie, jest za wcześnie na skrypt i pieniądze wydane na automatyzację będą pieniędzmi wydanymi na przepisywanie go za dwa tygodnie.

Praktycznie oznacza to trzy warstwy. Automat pilnuje regresji i krytycznych ścieżek, tych samych co miesiąc, bez dyskusji. Człowiek pracuje eksploracyjnie na tym, co nowe, zmienione albo ryzykowne. Trzecia warstwa to sprzężenie: każdy błąd znaleziony ręcznie, który mógłby się powtórzyć, zamienia się w test automatyczny. Ta trzecia warstwa decyduje o tym, czy zespół rośnie w kompetencji, czy tylko robi więcej tego samego.

Ten model pokazuje też, jak wygląda dobra ścieżka rozwoju testera manualnego. Nie polega ona na tym, żeby przestać testować ręcznie i zacząć pisać kod. Polega na tym, żeby coraz lepiej rozpoznawać ryzyko i coraz szybciej decydować, co zasługuje na uwagę człowieka, a co na skrypt. Umiejętność pisania kodu jest do tego przydatna, ale nie jest tym, co czyni testera wartościowym.

Jak to wygląda w liczbach

Automatyzacja bez porządku w procesie nie daje efektu, a z porządkiem daje efekt widoczny w wynikach biznesowych. W projekcie dla Argos połączenie automatyzacji z uporządkowaniem procesów QA skróciło regresję przed wydaniem z pięciu dni do dziesięciu godzin i zmniejszyło liczbę błędów krytycznych na produkcji o 46%. Warto zwrócić uwagę na kolejność: najpierw decyzja, co w ogóle warto powtarzać, potem automatyzacja tego, co przeszło ten filtr.

Osobna sprawa to niestabilność testów automatycznych, o której warto pamiętać, zanim ogłosicie automatyzację lekarstwem na wszystko. Google opisywał, że około 1,5% wszystkich uruchomień testów kończyło się wynikiem niestabilnym, a takie testy stanowiły 16% zbioru testowego. Automat też wymaga utrzymania i też potrafi kłamać, tylko robi to szybciej i w większej skali.

Jak sprawdzić to u siebie w jeden tydzień

Nie potrzebujecie audytu, żeby dowiedzieć się, po której stronie jesteście. Wystarczy przez tydzień notować przy każdym znalezionym błędzie dwie rzeczy: skąd się wziął i czy dałoby się go złapać skryptem. Po pięciu dniach zobaczycie rozkład, który zwykle zaskakuje kierownictwo.

Jeśli większość znalezisk pochodzi z odtwarzania starych list kroków, macie problem z procesem, nie z ludźmi, i automatyzacja ten problem tylko przyspieszy. Jeśli większość pochodzi z pracy eksploracyjnej i pytań o intencję, macie zespół, który przynosi informację niedostępną inaczej, a wtedy cięcie etatów manualnych będzie oszczędnością pozorną, rozliczaną potem w zgłoszeniach od klientów.

Pytanie brzmi nie „manual czy automat”, tylko „co dokładnie chcemy wiedzieć przed wydaniem i jaki jest najtańszy sposób, żeby się tego dowiedzieć”. Odpowiedź na nie prawie nigdy nie wskazuje wyłącznie jednej metody.

Co się dzieje, gdy firma tnie manual do zera

Scenariusz powtarza się na tyle często, że da się go opisać z góry. Organizacja inwestuje w automatyzację, po kilku kwartałach ma solidną regresję i uznaje, że rola testerów manualnych się wyczerpała. Etaty znikają albo zostają przekwalifikowane w całości. Przez pierwsze dwa, trzy miesiące nic złego się nie dzieje i decyzja wygląda na słuszną, bo regresja rzeczywiście przechodzi.

Problemy zaczynają się później i wchodzą bokiem. Rośnie liczba zgłoszeń od użytkowników dotyczących rzeczy, które formalnie działają: mylącego komunikatu, kroku, którego nie da się cofnąć, powiadomienia wysyłanego dwa razy. Żadne z nich nie jest awarią, więc nie trafia do statystyk incydentów, ale wszystkie razem obniżają zaufanie do produktu. Zespół wsparcia zaczyna pracować jako nieformalne QA, tylko bez narzędzi i bez wpływu na priorytety.

Druga konsekwencja dotyczy nowych funkcji. Bez pracy eksploracyjnej jedyną kontrolą przed wydaniem zostaje zestaw testów napisanych na podstawie tego samego dokumentu, na podstawie którego powstała implementacja. Jeśli w wymaganiu był błąd myślowy, nikt go nie wyłapie, bo test i kod odziedziczyły tę samą pomyłkę. To najczęstszy mechanizm, przez który organizacja z wysokim pokryciem testami trafia na produkcję z funkcją, której nikt nie potrzebował w tej postaci.

Nie jest to argument przeciw automatyzacji ani za utrzymywaniem dużych zespołów manualnych na wszelki wypadek. Jest to argument za świadomym rachunkiem. Jeśli redukujecie pracę manualną, warto z góry wiedzieć, jaką informację przestajecie zbierać, i zdecydować, czy jesteście gotowi bez niej wydawać. Czasem tak, zwłaszcza w produktach wewnętrznych o niskim ryzyku. W sklepie internetowym w szczycie sezonu to decyzja o zupełnie innej cenie.