Zaktualizowana ścieżka Automation QA: architektura testów zanim pojawi się Agent AI
Nowa wersja ścieżki rozwoju Automation QA z Playwrightem: fundamenty, architektura testów, CI i quality gates, a dopiero potem AI-assisted workflow.
Agent potrafi dziś wygenerować dwadzieścia testów w minutę. Brzmi jak dobra wiadomość, dopóki nie zapytasz, ile z tych dwudziestu testów faktycznie chroni coś ważnego. Jeśli tester, który je odbiera, sam nie potrafi odpowiedzieć na to pytanie, agent nie przyspiesza pracy zespołu - przyspiesza tylko tempo, w jakim rośnie dług testowy.
Od jakiegoś czasu wracam do tej samej myśli, patrząc na klasyczną ścieżkę rozwoju Automation QA opartą na stacku Playwrightowym. Coś w tej ścieżce przestało się zgadzać, i nie chodzi o to, czego ona uczy, tylko w jakiej kolejności. Jedna zmiana miejsca jednego elementu zmienia sens całej reszty.
Stara ścieżka rozwoju Automation QA i dlaczego przestała wystarczać
Klasyczny plan nauki wyglądał mniej więcej tak: TypeScript, potem Playwright, potem POM (Page Object Model - wzorzec organizacji kodu testowego, w którym elementy strony i akcje na nich grupujesz w osobnych klasach), potem testy API, na końcu spięcie tego wszystkiego w CI (Continuous Integration - proces automatycznego uruchamiania testów przy każdej zmianie w kodzie). Ta ścieżka uczyła pisania testów krok po kroku i przez lata sprawdzała się bez zarzutu.
Problem w tym, że ona nigdy nie uczyła myślenia o tym, co i dlaczego w ogóle testować. Nie musiała, bo każdy test i tak przechodził przez ręce testera, który po drodze podejmował dziesiątki małych decyzji - często nieświadomie. Dopóki człowiek pisał każdy przypadek testowy sam, brak jawnego fundamentu decyzyjnego nie był widoczny na zewnątrz, bo tempo pracy naturalnie wymuszało priorytetyzację.
Ten brak fundamentu robi się widoczny natychmiast, gdy w grę wchodzi agent generujący testy w tempie niedostępnym dla człowieka. Agent nie ma problemu z szybkością - ma problem z tym, że nikt mu nie powiedział, co dla Twojego produktu jest ryzykiem, a co szumem. Wypełnia tę lukę własnymi założeniami, a te założenia rzadko pokrywają się z rzeczywistym ryzykiem biznesowym.
Dlaczego kolejność, a nie sama obecność architektury, robi różnicę
Można by pomyśleć, że wystarczy w którymś momencie ścieżki dorzucić dział o architekturze testów, niezależnie od tego, gdzie go umieścimy. W praktyce kolejność decyduje o tym, czy AI w ogóle ma się czego "podłapać". Test architecture (architektura testów - świadome decydowanie, na jakim poziomie piramidy testów i w jakiej formie sprawdzić dane ryzyko) postawiona po nauce korzystania z agenta trafia na grunt, na którym tester już przyzwyczaił się, że narzędzie samo podejmuje te decyzje za niego.
Odwrócenie kolejności - architektura przed AI - sprawia, że tester wchodzi w pracę z agentem z gotowym zestawem kryteriów. Wie, jakich pytań ma szukać w odpowiedzi agenta, zanim jeszcze przeczyta wygenerowany kod. To różnica między klientem, który akceptuje wszystko, co dostanie, a klientem, który potrafi powiedzieć "ten test nic nie sprawdza, bo brakuje w nim asercji na stan końcowy".
W moich projektach ta różnica widać najszybciej przy code review wygenerowanych testów. Test bez jasno określonego celu przechodzi review z automatu, bo wygląda poprawnie składniowo - a to, czy faktycznie wykryłby regresję, wychodzi dopiero wtedy, gdy ktoś celowo spróbuje go "zepsuć" i sprawdzić, czy w ogóle zareaguje.
Krok 1: TypeScript i fundamenty Playwrighta - to się nie zmienia
Fundament techniczny w mojej zaktualizowanej ścieżce zostaje dokładnie tam, gdzie był. Bez solidnej znajomości TypeScriptu i podstaw Playwrighta (selektory, mechanizmy oczekiwania, obsługa asynchroniczności) nie ma czego budować dalej, i nie ma też co przekazywać agentowi do dalszej pracy.
To ważne zastrzeżenie, bo część osób odczytuje temat "AI w testowaniu" jako zaproszenie do pominięcia podstaw. Dzieje się odwrotnie - im lepiej rozumiesz mechanikę frameworka, tym łatwiej ocenisz, czy kod wygenerowany przez agenta jest poprawny, czy tylko wygląda poprawnie. Bez tej warstwy tester staje się operatorem czatu, a nie inżynierem, który go nadzoruje.
Krok 2: Architektura testów, zanim pojawi się AI
To jest najważniejsza zmiana w całej ścieżce i miejsce, w którym najczęściej widzę największą lukę u testerów wchodzących w automatyzację. Zanim ktokolwiek dotknie agenta generującego testy, powinien umieć samodzielnie i szybko odpowiedzieć na kilka pytań o dowolny fragment aplikacji.
Pytania, które stawiam sobie wyglądają tak:
Dlaczego ten test powinien być e2e (przechodzący całą ścieżkę użytkownika przez system), a nie czymś niższym w piramidzie testów?
Co powinno być component testem, czyli sprawdzeniem pojedynczego komponentu UI w izolacji, bez odpalania całej aplikacji?
Gdzie wystarczy test API, bez w ogóle dotykania interfejsu?
Jaki jest oracle tego testu - czyli źródło, które mówi nam, jaki wynik jest poprawny, a jaki nie?
Co ten test naprawdę chroni w produkcie - jaki scenariusz biznesowy, jaką stratę pieniędzy albo reputacji zapobiega?
Co się stanie, jeśli usuniemy z niego asercję - czy test dalej ma sens, czy staje się pustym przebiegiem?
Czy ten test faktycznie wykryłby regresję, gdyby ktoś celowo wprowadził błąd w logice, którą sprawdza?
Bez odpowiedzi na te pytania agent generujący testy nie ma czego "podłapać". Wypełnia lukę własnymi domyślnymi wzorcami - najczęściej dużą liczbą testów e2e klikających przez UI, bo to najbardziej oczywisty sposób sprawdzenia, że "coś działa". Tester, który wcześniej przećwiczył te pytania na własną rękę, potrafi natychmiast rozpoznać taki wzorzec i skierować agenta w stronę tańszego i szybszego testu na niższym poziomie.
Nowa ścieżka nauki testera automatyzującego.
Krok 3: API, component, e2e i bramki jakości w CI
Dopiero mając w głowie kryteria z poprzedniego kroku, warto rozbudowywać pokrycie testami na różnych poziomach i spinać je bramkami jakości (quality gates - zestaw warunków w pipeline CI, które muszą zostać spełnione, zanim zmiana trafi dalej, np. minimalny procent zielonych testów albo brak testów oznaczonych jako krytyczne i failujące). Wcześniej robienie tego samego bez architektury oznacza po prostu więcej testów, nie więcej pewności co do jakości.
Ta kolejność ma znaczenie praktyczne przy budowaniu pipeline'u. Zespół, który najpierw ustalił, co ma być testowane na poziomie API, a co na poziomie e2e, projektuje bramki jakości pod realne ryzyko - na przykład blokuje merge, gdy padnie test płatności, ale nie blokuje go, gdy padnie kosmetyczny test wizualny. Zespół bez tej wcześniejszej pracy zwykle kończy z jedną wspólną bramką dla wszystkiego, co prędzej czy później prowadzi do ignorowania czerwonych buildów.
Krok 4: AI-assisted workflow, dopiero na końcu
Na samym końcu tej ścieżki - nie na początku - pojawia się praca z agentem generującym testy oraz szerzej pojęty AI-assisted workflow (proces pracy, w którym AI wspiera pisanie, przegląd i utrzymanie testów, ale nie zastępuje decyzji testera). Agent pisze szybciej niż jakikolwiek człowiek, ale wciąż nie wie, co dla konkretnego produktu jest krytyczną ścieżką biznesową, a co szumem informacyjnym.
W praktyce ten krok obejmuje też agent review - świadomy przegląd tego, co wygenerował agent, z użyciem dokładnie tych samych pytań, które padły w kroku o architekturze. Tester, który przeszedł tę ścieżkę we właściwej kolejności, czyta wygenerowany test i od razu widzi, czy asercja sprawdza coś istotnego, czy tylko potwierdza, że strona się załadowała. To jest moment, w którym cała wcześniejsza praca zaczyna się zwracać - review trwa krócej, bo tester wie dokładnie, czego szuka.
Na samym szczycie tej zaktualizowanej ścieżki stawiam AI system testing, czyli testowanie systemów, które same w sobie wykorzystują AI - na przykład wtedy, gdy produkt, który testujesz, ma wbudowany chatbot albo mechanizm rekomendacji oparty na modelu językowym. To już osobny temat z własnym zestawem wyzwań (niedeterminizm odpowiedzi, ocena jakości treści generowanej), ale sensownie wchodzić w niego dopiero z pełnym zapleczem z poprzednich kroków.
Co z tego wynika dla pracy QA
Największa pułapka, jaką widzę w zespołach wdrażających AI do automatyzacji, to traktowanie agenta jako zamiennika dla nauki myślenia o testach, a nie jako przyspieszenia dla kogoś, kto już to myślenie ma. Agent świetnie skaluje dobre decyzje testowe - równie chętnie skaluje złe, tylko szybciej i w większej skali.
Jeśli zarządzasz zespołem lub sam wchodzisz w automatyzację z Playwrightem, warto zatrzymać się na chwilę przy pytaniu, w którym miejscu wasza ścieżka nauki wprowadza AI. Jeśli agent pojawia się, zanim ktokolwiek w zespole potrafi świadomie odpowiedzieć na pytanie "co ten test naprawdę chroni", to jest dokładnie ten moment, w którym warto cofnąć się o krok i najpierw poukładać architekturę.
Chcesz przejść przez tę ścieżkę z kimś, kto już ją przeszedł? 🎯
Najwięcej czasu w nauce automatyzacji nie ginie na sam kod, tylko na domyślanie się, w jakiej kolejności uczyć się kolejnych rzeczy - i czy to, co akurat ćwiczysz, w ogóle ma dziś sens w świecie, gdzie agent pisze testy za Ciebie.
Na konsultacji 1:1 układamy razem Twoją indywidualną ścieżkę rozwoju jako testera automatyzującego - od fundamentów, przez architekturę testów, po świadome korzystanie z AI - dopasowaną do tego, gdzie już jesteś i dokąd chcesz dojść.
Kontakt
kontakt@rwasik.pl