Tester wizualny AI to narzędzie, które otwiera strony w przeglądarce Playwright, robi zrzuty w kilku rozdzielczościach i przekazuje je modelowi z obsługą obrazu, a ten zwraca listę problemów: tekst wychodzący z przycisku, rozjechaną stopkę, fragment w złym języku. Zbudowaliśmy takie narzędzie dla wielojęzycznego serwisu na WordPressie, żeby nie przeklikiwać ręcznie każdej wersji językowej po każdej zmianie. Opisujemy, skąd bierze adresy, jak robić zrzuty, które model dobrze zrozumie, jak napisać prompt, żeby AI nie zmyślało błędów, jak sprawdza tłumaczenia względem Lokalise i czego takie narzędzie nie zastąpi.
Czym jest tester wizualny AI i kiedy ma sens?
Klasyczne testy regresji wizualnej porównują piksele ze wzorcem. Działają dobrze, gdy masz zatwierdzony stan strony i chcesz wyłapać zmiany. Gorzej, gdy serwis ma setki podstron w wielu językach, część z nich nikt nigdy nie zatwierdził, a pytanie brzmi „co tu jest zepsute”, a nie „co się zmieniło”.
Tu model z obsługą obrazu sprawdza się lepiej. Dostaje zrzut, metadane strony i instrukcję testera, np. „sprawdź, czy tekst się nie wylewa” albo „zweryfikuj tłumaczenia”, i odpowiada w JSON-ie: status strony, krótkie podsumowanie i lista problemów z nazwą elementu, opisem i miejscem na stronie. Instrukcję wpisuje się zwykłym językiem w polu formularza.
Jak działa tester wizualny krok po kroku?
- Użytkownik wybiera źródło adresów i wpisuje instrukcję testowania.
- Narzędzie pokazuje liczbę stron i szacowany koszt, a test rusza dopiero po potwierdzeniu.
- Pula workerów, domyślnie 5, rozdziela adresy między siebie. Każdy otwiera stronę w osobnym kontekście przeglądarki.
- Dla każdej rozdzielczości powstaje zrzut, który model analizuje fragment po fragmencie.
- Wyniki płyną na żywo do przeglądarki przez Server-Sent Events, więc postęp widać od pierwszej strony.
- Na końcu powstaje raport HTML, a sesja trafia do historii w SQLite.
Backend to Node.js z Expressem, frontend React. Całość działa w Docker Compose, a model wizyjny wybiera się w panelu administracyjnym. Poza Claude narzędzie obsługuje GPT-4o i otwarty model Qwen3-VL.
Skąd tester bierze listę stron do sprawdzenia?
Są cztery źródła, bo każdy zespół ma tę listę gdzie indziej:
- Ręcznie: jeden adres w linii, przydatne do szybkiego sprawdzenia kilku stron po zmianie.
- CSV: narzędzie szuka kolumny o nazwie url, link albo address, a gdy jej nie ma, bierze pierwszą. Puste wiersze i duplikaty odpadają.
- Crawl domeny: przechodzi po linkach w obrębie jednej domeny do głębokości 3, domyślnie do 100 stron.
- WordPress API: własny endpoint w WordPressie zwraca listę stron z adresem, tytułem, szablonem, językiem, typem wpisu i tagami. W interfejsie pojawiają się z tego filtry, więc można przetestować np. tylko strony po niemiecku na jednym szablonie.
Najwięcej daje czwarta opcja. Szablon i język trafiają do raportu przy każdym problemie, więc programista od razu wie, który plik szablonu poprawić.
Jak zrobić zrzut strony, który AI dobrze przeanalizuje?
Większość pracy nad takim narzędziem to nie prompt, tylko przygotowanie zrzutu. Model ocenia to, co dostanie, a strona WordPressa w przeglądarce bez interakcji często wygląda inaczej niż u użytkownika.
Omijanie cache WordPressa
Do każdego adresu dodajemy parametr ?nocache= z bieżącym znacznikiem czasu i wysyłamy nagłówki Cache-Control: no-cache oraz Pragma: no-cache. Bez tego wtyczka cache potrafi pokazać wersję sprzed poprawki i test zgłasza błąd, który już nie istnieje.
Strony za logowaniem
Testerzy wklejają ciasteczka sesji administratora, a narzędzie dodaje je do kontekstu przeglądarki. Dzięki temu można sprawdzić szkice przed publikacją.
Pełne wyrenderowanie
Przed zrzutem narzędzie czeka na koniec ruchu sieciowego i załadowanie fontów, potem powoli przewija całą stronę, żeby uruchomić leniwe ładowanie obrazków, i czeka na ich wczytanie. Bez przewijania dolna połowa strony wychodzi na zrzucie jako szare prostokąty, a model słusznie zgłasza je jako zepsute obrazy.
Banery cookies i elementy przyklejone
Banery zgód, widgety czatu i przyciski „do góry” są ukrywane, a pozostałe elementy z pozycją fixed albo sticky, np. menu, zamieniane na zwykłe. Na zrzucie całej strony przyklejone menu potrafi pojawić się kilka razy albo zasłonić treść w połowie wysokości.
Dzielenie długich stron
Zrzut wysokiej strony zmniejszony do rozmiaru, który model przyjmie, staje się nieczytelny. Dlatego pierwszy fragment to zawsze widok ekranu, a resztę tniemy na kawałki do 2000 pikseli wysokości z zakładką 200 pikseli, żeby element na granicy nie zniknął. Każdy fragment idzie do modelu osobno, z informacją, na jakiej wysokości strony leży.
Narzędzie robi zrzuty w kilku rozdzielczościach, od 375 pikseli szerokości dla telefonu po 2560 dla monitora 4K. Domyślnie sprawdza Full HD i współczesny telefon. Opcjonalnie otwiera menu mobilne i klika jego pozycje albo klika maksymalnie trzy przyciski otwierające okna modalne i robi zrzuty tych stanów.
Jak napisać prompt, żeby AI nie zmyślało błędów?
Model z obsługą obrazu chętnie uzupełnia zrzut wiedzą o podobnych stronach, a baner cookies w dziwnym miejscu potrafi uznać za błąd układu. Dlatego prompt systemowy zaczyna się od zasady, którą kopiujemy do każdego podobnego projektu: opisuj wyłącznie to, co widzisz na tym zrzucie, a jeśli nie jesteś pewny, pomiń. Wprost piszemy też, że fałszywy brak błędu jest lepszy niż fałszywy błąd.
Poza tym prompt:
- wymienia, czego nie zgłaszać: banery cookies, widgety ocen nachodzące na baner, czaty i przyciski przewijania,
- zawęża zakres do listy konkretnych kontroli, m.in. tekst poza kontenerem, kolumny w stopce, podejrzanie duże odstępy, wyrównanie okruszków nawigacji do nagłówka H1, tekst w przyciskach, zepsute obrazki, poziome przewijanie,
- podaje zadeklarowany język strony i każe zgłaszać tylko tekst w innym języku, także na grafikach,
- przypomina, że ta sama strona jest sprawdzana w kilku rozdzielczościach, więc model ma zgłaszać tylko to, co widać w bieżącej.
Strony, których nie da się załadować (błąd HTTP, przekroczony czas), dostają status błędu od razu, bez wysyłania czegokolwiek do modelu. Nie ma sensu płacić za analizę strony 404.
Jak sprawdzić tłumaczenia strony względem Lokalise?
Model z obsługą obrazu zauważy angielskie zdanie na polskiej stronie, ale nie powie, czy tekst pochodzi z systemu tłumaczeń, czy ktoś wpisał go na sztywno w szablonie. Do tego służy osobna, deterministyczna kontrola.
Narzędzie pobiera z Lokalise wszystkie klucze z tłumaczeniami i trzyma je w lokalnym cache odświeżanym co 10 minut. Na stronie zbiera widoczne fragmenty tekstu i atrybuty, pomijając nagłówek, stopkę, nawigację, treść z edytora WordPressa i widgety zewnętrzne. Każdy fragment jest normalizowany: bez encji HTML, znaczników i placeholderów w nawiasach klamrowych, małymi literami.
Potem szuka go w tłumaczeniach dla języka strony. Najpierw dokładnie, potem jako fragmentu dłuższego tłumaczenia, bo tekst w szablonie bywa pocięty znacznikami. Gdy nie znajdzie, zgłasza ostrzeżenie z selektorem CSS elementu i najbliższym tłumaczeniem z Lokalise wybranym po wspólnych słowach. Liczby, adresy, e-maile, telefony i numery kont pomija automatycznie, a resztę wyjątków można dopisać w panelu. Kontrolę da się zawęzić do kluczy z jednym tagiem Lokalise, co przy dużym projekcie mocno ogranicza fałszywe trafienia.
Przy audytach tłumaczeń w tym samym serwisie trafiliśmy na pułapkę: projekt w Lokalise miał dwie wersje tego samego języka, ogólną i regionalną, a teksty były wpisane raz w jedną, raz w drugą. Kontrola, która sprawdza tylko jedną z nich, zgłasza braki tam, gdzie tłumaczenie istnieje.
Jak wygląda raport i historia testów?
Raport to jeden plik HTML ze wszystkim w środku, także zrzutami zapisanymi w base64, więc da się go wysłać mailem i otworzyć bez internetu. Na górze są liczby stron OK, z błędami i z ostrzeżeniami oraz tabela tylko tych stron, które mają problemy. Każda strona ma zakładki dla rozdzielczości, zrzuty, które powiększają się po kliknięciu, i tabelę problemów z polami na zaznaczenie, co już sprawdzono.
Historia sesji siedzi w SQLite. Widać w niej datę, źródło adresów, instrukcję, liczbę stron, błędów i ostrzeżeń oraz status. Trwający test można zatrzymać, a raport częściowy i tak powstaje. Sesje przerwane restartem serwera są przy starcie oznaczane jako błędne, żeby nie wisiały w nieskończoność jako trwające.
Czego tester wizualny AI nie zastąpi?
Narzędzie ocenia statyczne zrzuty, więc nie sprawdzi płynności animacji ani działania formularza po wysłaniu. Okna modalne i menu mobilne obsługuje tylko w zakresie kliknięć, które ma zaprogramowane. Nie porównuje też strony z projektem graficznym. Porównanie z ramką z Figmy mamy w planach, ale dziś go nie ma.
Najlepiej działa jako pierwsze sito: przechodzi przez wszystkie strony i wersje językowe, a tester dostaje listę kilkunastu miejsc do obejrzenia zamiast kilkuset stron do przeklikania. Decyzję, czy problem jest prawdziwy, podejmuje człowiek, który ma w raporcie zrzut obok opisu. Tak samo projektujemy agentów AI: model robi powtarzalną część pracy, a człowiek zatwierdza wynik.
Utrzymujesz serwis z wieloma wersjami językowymi i ręczne testy przed każdym wdrożeniem trwają dni? Zbudujemy tester dopasowany do Twojego WordPressa, szablonów i systemu tłumaczeń albo przejmiemy testy jako zewnętrzny dział IT. Zobacz, jak działamy w outsourcingu IT →
