Junior QA w erze AI

AI napisze Ci scenariusz testowy w kilkanaście sekund. Uzupełni przypadki brzegowe, wygeneruje dane testowe czy podpowie asercje. I tu pojawia się pytanie, które coraz częściej słyszę od Juniorów wchodzących na rynek: skoro to wszystko generuje model, to co właściwie ja buduję przez te pierwsze lata pracy?

To nie jest pytanie o lenistwo, ale pytanie o to, czy za rok i dwa lata będziesz miał(-a) coś, co da się zbudować tylko przez doświadczenie - zdolność oceny, czy to, co widzisz na ekranie, jest naprawdę dobre. Tę zdolność możesz zbudować równolegle z używaniem AI. Albo możesz jej nie zbudować wcale i dopiero po czasie odkryć, że czegoś brakuje.

Pętla feedbackowa, która zniknęła

Kiedyś nauka w testowaniu wyglądała tak: coś zrobiłeś(-aś), coś się wysypało, rozgryzałeś(-aś) dlaczego. Spędziłeś(-aś) nad tym godziny, wracałeś(-aś) do logów, rozmawiałeś(-aś) z developerem, w końcu rozumiałeś(-aś) co poszło nie tak. I tego już nie zapomniałeś(-aś). Każda wtopa była lekcją, która zostawała w głowie długo po zamknięciu taska.

AI skrócił tę pętlę. Często do zera. Dostajesz gotowy output, który wygląda poprawnie, działa na środowisku testowym i przechodzi review. Możesz nigdy nie wejść w głąb problemu, bo nie ma powodu - wszystko jest zielone. Technicznie rzecz biorąc, zadanie jest wykonane. Ale coś, co kiedyś byłoby lekcją, teraz po prostu nie nastąpiło.

Problem nie leży w samym AI. Problem leży w tym, że ta pętla była silnikiem budowania czegoś, co w branży nazywa się potocznie "taste" - instynktem, który mówi ci, że coś jest nie tak, zanim potrafisz to dokładnie nazwać. Testy, które wyglądają poprawnie, ale nie pokrywają żadnego realnego ryzyka. Automatyzacja, która świeci się na zielono, ale niczego nie gwarantuje. Architektura, która działa w demo, a sypie się w produkcji. To właśnie ten instynkt pozwala to wychwycić - i buduje się go latami, przez setki małych błędów i napraw, nie przez generowanie prompta za promptem.

Pytaj AI jak mentora, nie jak automat do outputu

Większość juniorów używa AI transakcyjnie: podajesz co chcesz dostać, bierzesz wynik, zamykasz czat. Rozumiem to, bo praca ma terminy, sprint ma koniec i nie ma czasu na filozofię. Ale ten sam model, który wygenerował test, może ci wyjaśnić dlaczego wybrał takie podejście, na jakie założenia się oparł i gdzie mogą pojawić się problemy.

Wystarczy jedno dodatkowe pytanie po otrzymaniu outputu: "Jakie są wady tego podejścia?" albo "Jak inaczej można by to zaimplementować?". Brzmi banalnie, ale zmienia rozmowę z jednorazowej transakcji w coś, co zaczyna przypominać naukę. Zamiast dostać gotową odpowiedź, rozumiesz też dlaczego jest taka a nie inna, co z niej wynika i kiedy przestaje działać.

Możesz też pytać o tradeoffs - kiedy warto testować coś na poziomie UI w Playwright, a kiedy lepiej zejść do API. Kiedy scenariusz eksploracyjny jest wartościowy, a kiedy wystarczy prosty smoke test (szybka weryfikacja, czy kluczowe funkcje aplikacji w ogóle działają). AI odpowie na te pytania zaskakująco dobrze, jeśli dobrze zapytasz. Różnica między juniorem, który to robi, a takim, który nie robi, to po roku bardzo wyraźna różnica w rozumieniu tematu.

Kontekst biznesowy jest tylko u ciebie

LLM (Large Language Model, czyli model językowy stojący za narzędziami AI) przewiduje kolejny token na podstawie wzorców ze danych treningowych. Nie zna twojego projektu, nie wie co jest krytyczne dla Twoich użytkowników i nie rozumie jakie zachowanie systemu jest dopuszczalne a jakie nie. Tego kontekstu nie ma w żadnym modelu, bo jest tylko w twojej głowie i w głowach osób, z którymi pracujesz.

Dlatego zanim napiszesz prompt, zatrzymaj się na chwilę i zastanów się, co właściwie chcesz sprawdzić i dlaczego. Które ścieżki są naprawdę krytyczne biznesowo? Co może wysypać się w tym konkretnym miejscu systemu, biorąc pod uwagę jak jest zbudowany? Gdzie dane testowe mogą się rozejść z danymi produkcyjnymi? To są pytania, na które AI nie odpowie sam z siebie, bo nie ma dostępu do odpowiedzi. Ale Ty masz.

Ta chwila refleksji przed promptem nie tylko poprawia jakość tego, co dostajesz od AI. Ona też ćwiczy myślenie, które jest rdzeniem pracy dobrego testera - myślenie przez ryzyko i konsekwencje, a nie przez listę kroków do odhaczenia. To jest dokładnie ta mięsień, której AI nie ćwiczy za ciebie.

Pisz testy ręcznie - regularnie, nie od święta

To rada, która brzmi przekornie w erze narzędzi generujących kod w sekundy. Ale jest ku temu konkretny powód. Jeśli przez dłuższy czas nie piszesz testów samodzielnie, stopniowo tracisz punkt odniesienia. Przestajesz wiedzieć, co jest proste, a co skomplikowane. Zacierają się granice między tym, co eleganckie, a tym, co działa przypadkowo. Każdy output AI zaczyna wyglądać tak samo: wystarczająco dobrze.

Nie musisz rezygnować z AI przy codziennych zadaniach. Chodzi o to, żeby raz w tygodniu wziąć jakiś mały, konkretny przypadek i przejść przez niego samodzielnie - bez podpowiedzi. Może to być scenariusz logowania, walidacja formularza, weryfikacja odpowiedzi API. Cokolwiek, co wymaga, żebyś sam(-a) zdecydował(-a) co i jak sprawdzić. To właśnie w tych momentach budujesz sędziowski instynkt, który potem pozwala ci ocenić czy test wygenerowany przez AI jest wart czegokolwiek, czy jest tylko kodem, który przechodzi.

Jest jeszcze jeden efekt uboczny pisania testów ręcznie, o którym rzadko się mówi. Jeśli masz trudność z napisaniem testu dla danej funkcjonalności, to często sygnał, że funkcjonalność jest niedobrze zaprojektowana lub specyfikacja jest niepełna. To ważna informacja, którą warto zanieść na spotkanie z zespołem. AI tego nie wyłapie, bo nie ma oporów przed pisaniem testów dla czegokolwiek.

Czytaj cudzy kod - ale wybieraj źródła

Najlepsi testerzy i developerzy, jakich znam, spędzają dużo czasu na czytaniu kodu, który napisali inni. Pull requesty seniorów, repozytoria projektów open source czy implementacje, które ktoś uznał za warte pokazania światu. W tym jest ogromna edukacja - sposób strukturowania kodu, wybory nazewnictwa, obsługa edge case'ów (przypadków brzegowych) czy podejście do błędów i logowania.

Jest jednak jedno ważne zastrzeżenie: kod generowany przez AI często wygląda poprawnie na powierzchni, ale nie był przemyślany. Może zawierać struktury, które działają, ale nie mają za sobą żadnego uzasadnienia poza tym, że statystycznie taka kombinacja pojawiała się w danych treningowych. Jeśli uczysz się przez czytanie cudzego kodu, upewnij się, że jest to kod pisany przez kogoś, kto faktycznie podejmował świadome decyzje projektowe. Szukaj repozytoriów starszych, aktywnie utrzymywanych, z widoczną historią przemyślanych commitów i code review. Absorbujesz wzorce - zadbaj, żeby to były dobre wzorce.

Kto sprawdza pracę, jeśli wszyscy używają AI?

Jest pytanie, które rzadko pada wprost, ale w praktyce jest coraz bardziej aktualne: jeśli Junior generuje test z AI i Senior robi review też z AI, to kto właściwie sprawdza, czy ta praca ma sens? Kto zadaje pytania o ryzyko, o krytyczne ścieżki, o to co może pójść nie tak na produkcji?

To nie jest pytanie retoryczne. To opis sytuacji, w której techniczny dług - czyli skumulowane zaległości i skróty w architekturze, testach i procesach - buduje się niepostrzeżenie, bo każdy element z osobna wygląda wystarczająco dobrze. Testy są, pipeline w CI/CD (czyli potoku integracji i wdrożeń) świeci się na zielono, sprint jest zamknięty. Ale ile z tego to prawdziwe pokrycie ryzyka, a ile to złudzenie, że jest przetestowane?

Dobry Junior QA nie jest tym, który najszybciej generuje outputy. Jest tym, który potrafi zadać to jedno pytanie, które spowalnia rozmowę na chwilę i zmienia jej kierunek: czy ten test naprawdę sprawdza to, co ważne?

Co z tego wynika dla ciebie

Jeśli jesteś na początku kariery i codziennie używasz AI, masz dwa wyjścia. Pierwsze: traktować narzędzia jak skrót do outputu i z każdym miesiącem coraz bardziej tracić zdolność do oceny tego, co generujesz. Drugie: używać tych samych narzędzi jako rozszerzenia własnego myślenia, zadawać pytania, zatrzymywać się przed promptem i regularnie sprawdzać, czy twój punkt odniesienia wciąż jest ostry.

Różnicy między tymi dwiema ścieżkami nie widać na początku. Widać ją po roku lub dwóch, kiedy jedni rozumieją co i dlaczego robią, a inni umieją tylko opisać co AI za nich wygenerował. Pierwsi będą inżynierami jakości, którzy potrafią oceniać, decydować i mówić głośno co ryzykuje projekt. Drudzy - operatorami narzędzi. Wybór jest naprawdę Twój i naprawdę dzieje się teraz, w każdym tygodniu pracy.

Polecane wpisy:

Sprawdź też moje social media: