Wdrażajcie interfejs, który zaprojektowaliście — nie ten, który prześlizgnął się przez CI

Testy funkcjonalne dobrze odpowiadają na jedno pytanie: „czy przycisk robi, co trzeba po kliknięciu?”. Milczą o wszystkim, co dzieje się przed kliknięciem — czy przycisk ma właściwy kolor, właściwy rozmiar, właściwe miejsce, czy pozostaje czytelny na ekranie 360 px i czy w ogóle jest widoczny po ostatnim refaktorze CSS. Właśnie w tej luce żyje większość incydentów dnia wydania.

Realne regresje, które widzimy i do wyłapywania których ScanU został zbudowany, skupiają się wokół garstki przewidywalnych wyzwalaczy:

• Refaktor CSS składa gap kontenera flex na jednym breakpoincie. Na desktopie układ wygląda identycznie; na tablecie 768 px dwie karty zaczynają się nakładać.
• Aktualizacja design tokenów przesuwa każdą wartość spacingu o dwa piksele. Nic nie przepada; tuzin starannie zrównoważonych kompozycji po cichu traci równowagę.
• Widget zewnętrzny — baner ciasteczek, live-chat, slot reklamowy — wydaje cichą aktualizację, która przesuwa first paint. Core Web Vitals regresują z dnia na dzień, bez jednej zmiany kodu po Państwa stronie.
• Upgrade frameworka podmienia domyślny stos font-feature. Tekst na długich stronach ucieka o pół linii. Hero-CTA nagle wpada pod krawędź widoku.
• Rollout feature flagi przestawia DOM. W Safari zmienia się stacking context modala i przycisk zamknięcia staje się nieklikalny. W Chrome wszystko wygląda normalnie.

Żadna z tych zmian nie wywoła fałszywej asercji. Każda psuje doświadczenie użytkownika. Zadaniem ScanU jest sprawić, by ta druga klasa błędów była tak samo łatwa do zauważenia, przejrzenia i zablokowania jak czerwony test jednostkowy. Gdy diff pojawia się na pull request, designerka może wtrącić się tak, jak reviewer wtrąca się w sygnaturę funkcji — przed mergem, nie po wydaniu na produkcję.

To przejście — z „liczmy, że ktoś zauważy na stagingu” na „rewidujmy zmianę wizualną tak jak zmianę kodu” — to kluczowa wartość narzędzia regresji wizualnej w nowoczesnym pipeline wydawniczym.

Każde uruchomienie to pipeline w trzech krokach. Najpierw ScanU w każdym silniku nawiguje do strony lub komponentu pod testem, czeka na skonfigurowany zestaw sygnałów gotowości — załadowane czcionki, zdekodowane obrazy, cichy ruch sieciowy, atrybut data-ready lub własna sonda JavaScript — i przypina wszystkie animacje CSS do ich ostatniej klatki. Następnie rejestruje stronę na każdym skonfigurowanym viewporcie w tym samym uruchomieniu, ze scroll-stitching dla długich stron, dzięki czemu otrzymujecie pełny artefakt, a nie tylko widoczny fragment. Na końcu pipeline porównuje rejestrację z zaakceptowaną baseline i produkuje wynik dla każdej pary (przeglądarka, viewport): identyczne, w tolerancji lub znacząco różne.

Samo porównanie nie jest naiwnym diffem pikseli. ScanU stosuje model percepcyjny, który rozumie anti-aliasing, renderowanie sub-pikselowe i drobne przesunięcia przestrzeni barw, tak aby osobliwość kerningu w WebKicie nie udawała buga. Obsługuje też jawne maski dla stref, o których wiadomo, że zmieniają się przy każdym ładowaniu — dane live, relatywne znaczniki czasu, treści losowe, karuzele — dzięki czemu wnoszą one zerowy szum do diffu.

Gdy pojawia się realna zmiana, platforma pokazuje trzy zsynchronizowane panele: baseline, bieżącą rejestrację i nakładkę diffu, która dokładnie zaznacza, co się przesunęło. Dla każdej zmiany zapisywana jest jedna decyzja do przeglądu — akceptuj, odrzuć lub zaktualizuj baseline — a ta decyzja staje się częścią historii projektu. Nie ma cichego dryfu ani automatycznej akceptacji: baseline porusza się tylko wtedy, gdy uprawniona osoba tego zażąda.

Ten sam pipeline można uruchamiać z trzech punktów wejścia: przeciwko żywym URL-om (produkcja, staging, podglądy PR), przeciwko statycznej stronie lub zbudowanej paczce assetów, albo przeciwko podglądom komponentów w sandboksie w stylu Storybooka. Większość zespołów używa pierwszej drogi jako release gate, drugiej — do artefaktów wdrożenia, trzeciej — do pracy nad design systemem; wszystkie trzy zasilają ten sam magazyn baseline.

Niezależnie od kształtu zespołu, ScanU zwykle wchodzi z jednego z pięciu powodów: niedawny incydent produkcyjny, który wizualna regresja by wyłapała; migracja design systemu, której zasięgu nie da się zaudytować ręcznie; workflow CI/CD, który potrzebuje release gate bogatszego niż „testy zielone”; dostawa zorientowana na klienta, wymagająca dowodu przed/po; albo postawa compliance, która preferuje narzędzia testowe hostowane w UE. Wspólna integracja CI/CD stoi za wszystkimi pięcioma — ten sam pipeline wykonuje pracę, czy wyzwala go PR, merge, czy nocny harmonogram.

ScanU jest budowany i hostowany w Unii Europejskiej, z magazynowaniem i przetwarzaniem na infrastrukturze operowanej w UE. Dla zespołów ze zobowiązaniami co do lokalizacji danych — branży regulowanych, zamawiających publicznych, klientów B2B wrażliwych na prywatność — to często wymóg zakupowy, a nie preferencja. ScanU jest zaprojektowany, by ten wymóg spełniać bez kompromisów w możliwościach produktu.

Z tej postawy wynika kilka świadomych decyzji projektowych:

• Minimalizacja danych. Platforma przechowuje zrzuty i metadane niezbędne do wykonania diffu; nie zasysa kodu źródłowego strony, ciasteczek ani ciał zapytań, które nie wnoszą nic do diffu.
• Maskowanie w kontekstach wrażliwych. Pola znane z przenoszenia danych osobowych — nagłówki konta, adresy e-mail, numery zamówień — można zadeklarować jako maskowane obszary, dzięki czemu zarejestrowany obraz jest już zredagowany w chwili zapisu do magazynu.
• Kontrola dostępu. Kto może widzieć dany diff, jest uprawnieniem pierwszej klasy. Reviewerzy, współtwórcy i zewnętrzni audytorzy otrzymują jawne role, a każda aktualizacja baseline jest rejestrowana wraz z osobą, która ją zatwierdziła.
• Transparentność wobec podprocesorów. Lista podprocesorów jest publikowana i wersjonowana. Żadna ukryta analityka nie widzi Państwa zrzutów.
• Retencja pod Państwa kontrolą. Baseline i artefakty diffu są przechowywane przez horyzont, który Państwo konfigurują; stare uruchomienia wygasają automatycznie, zamiast po cichu się kumulować.

Pełna postawa prywatności — podprocesorzy, hosting regionalny, umowa powierzenia, okna retencji — znajduje się w dokumentacji RODO i przetwarzania danych. Dla większości zespołów liczy się wersja skrócona: Państwa zrzuty zostają w UE, a platforma jest zbudowana tak, aby tam pozostały.

Błędy wizualne skupiają się w garstce powtarzalnych wzorców. Każdy w izolacji wygląda na banalny; każdy może dolecieć do produkcji bez ani jednego czerwonego testu. Wszystkie ujawniają się jako diff w kolejnym uruchomieniu ScanU — zanim PR zostanie zmergowany.

• Przesunięcia spacingu. Utility gapa skacze z 16 na 20 pikseli; siatka kart, która wcześniej oddychała, na mobile nagle sprawia wrażenie ściśniętej. HTML bez zmian; układ — już tak.
• Zepsute układy po wdrożeniu. Upgrade pipeline’u builda gubi plugin PostCSS odpowiedzialny za autoprefiks backdrop-filter. W Safari pasek nawigacji staje się nagle nieprzezroczysty tam, gdzie wcześniej rozmazywał tło.
• Regresje CSS z przesunięć specyficzności. Zmiana kolejności klas Tailwinda, nowa warstwa utility albo zrefaktorowana kaskada subtelnie zmieniają, która reguła wygrywa — nagłówek traci kolor akcentu na kilku stronach.
• Niedziałające breakpointy responsywne. Nowa pozycja w nawigacji wychodzi poza breakpoint tabletowy i łamie się do drugiej linii, spychając hero poniżej krawędzi na iPadach i dużych Androidach.
• Różnice renderowania między przeglądarkami. Projekt oparty na text-wrap: balance wygląda ostro w Chromie, ale pozostaje niezrównoważony w silnikach, które jeszcze go nie wydały. Bez sprawdzenia cross-browser na maszynie dewelopera jest to niewidoczne.
• Dryf czcionek i typografii. Dostawca czcionek wymienia subset, wagi przesuwają się o sto gramów i każdy akapit na stronie marketingowej ucieka o ćwierć linii. Gęstość tekstu się zmienia; żaden diff w repo tego nie tłumaczy.
• Regresje widgetów zewnętrznych. Dostawca bannera zgód wydaje aktualizację, która na ciemnych motywach sprawia, że przycisk akceptacji staje się niewidoczny. Konwersja spada; testy nadal zielone.
• Dryf design systemu. Komponent przycisku zmienia offset pierścienia fokusu. Dwudziestu konsumentów wisi na tym komponencie. Dwadzieścia stron wygląda teraz subtelnie inaczej. Nikt nie przegląda dwudziestu stron ręcznie.
• Błędy wizualne, które uciekają na produkcję. Każdy z powyższych, pomnożony przez routy i breakpointy, których w danym tygodniu nikt nie otwiera, i przez przeglądarki, z których w zespole nikt codziennie nie korzysta.

Przegląd funkcji opisuje prymitywy wykrywania bardziej szczegółowo — tolerancje percepcyjne, maskowane obszary, przechwyt przy scrollu, branching baseline — i pokazuje, która prymitywa adresuje którą z kategorii powyżej. Dla większości zespołów krótka wersja brzmi: jeśli coś zmienia się wizualnie, ScanU to zauważa; jeśli jest to oczekiwane, akceptujecie jednym kliknięciem; jeśli nie — wyłapaliście to wcześniej niż ktokolwiek inny.