Checklista wizualnego QA: co zweryfikować przed każdym wydaniem

Wypuszczenie wydania bez wizualnego QA to gra w ruletkę. Testy funkcjonalne potwierdzają, że funkcje działają, ale nie potwierdzają, że interfejs wygląda poprawnie. Przycisk może przejść każdy test integracyjny, a mimo to nachodzić na pole formularza w mobilnym Safari. Nagłówek może renderować się idealnie po angielsku, a po przetłumaczeniu na niemiecki rozsadzić swój kontener.

Ta checklista obejmuje weryfikacje wizualne, które każdy zespół webowy powinien przeprowadzić przed wdrożeniem wydania na produkcję. Możesz ją stosować w obecnej formie lub dostosować do swojego stosu technologicznego i grupy odbiorców.

Dlaczego checklista wizualna jest ważna

Błędy wizualne są wyjątkowo szkodliwe, ponieważ są natychmiast widoczne dla użytkowników. Przekrzywiony element lub zepsuty układ podkopuje zaufanie w sposób, w jaki wolna odpowiedź API tego nie robi. Mimo to wizualne QA jest często najbardziej chaotyczną częścią procesu wydawniczego — przeprowadzane niespójnie, przez różne osoby, bez wspólnych kryteriów.

Spisana checklista rozwiązuje ten problem, czyniąc wizualne QA powtarzalnym i mierzalnym. Każdy w zespole wie, co oznacza „zweryfikowane wizualnie", i żadna kategoria sprawdzeń nie zostanie pominięta, bo ktoś o niej zapomniał.

Układ i odstępy

Problemy z układem to najczęstsze regresje wizualne. Sprawdzaj je systematycznie:

• Struktura strony jest zachowana — nagłówek, główna treść, sidebar (jeśli jest) i stopka renderują się w prawidłowej kolejności z oczekiwanymi odstępami.
• Układy grid i flexbox zawijają się poprawnie — zweryfikuj przy szerokościach desktopowej, tabletowej i mobilnej. Szukaj nieoczekiwanego zawijania kolumn lub elementów wychodzących poza kontenery.
• Odstępy między sekcjami są spójne — marginesy i paddingi odpowiadają specyfikacji projektu. Zwracaj uwagę na sekcje zbyt blisko siebie lub zbyt daleko od siebie.
• Brak nakładających się elementów — sprawdź, czy elementy z pozycją absolutną (tooltipy, dropdowny, modale) nie nakładają się na treść ani nie wychodzą poza viewport.
• Elementy sticky i fixed działają poprawnie — przyklejone nagłówki i stałe stopki powinny utrzymywać pozycję podczas przewijania bez zasłaniania treści za nimi.

Informacje o automatycznej weryfikacji układu w różnych breakpointach znajdziesz w naszym przewodniku dotyczącym workflow testowania międzyprzeglądarkowego.

Typografia i treść

Problemy z renderowaniem tekstu są subtelne, ale wpływają na czytelność i profesjonalizm:

• Nagłówki zachowują prawidłową hierarchię — rozmiary i grubości H1, H2, H3 odpowiadają systemowi projektowemu.
• Tekst główny jest czytelny — rozmiar czcionki, wysokość linii i kontrast spełniają standardy dostępności. Testuj z rzeczywistą treścią, nie tekstem zastępczym.
• Brak obcinania ani przepełnienia tekstu — długie nagłówki, przetłumaczone ciągi tekstowe i dynamiczna treść mieszczą się w swoich kontenerach. Sprawdzaj szczególnie przy dłuższych lokalizacjach, takich jak niemiecki.
• Linki są wizualnie rozróżnialne — podkreślenie, kolor lub inny styl pozwala zidentyfikować linki bez polegania wyłącznie na kolorze.
• Bloki kodu i tekst preformatowany renderują się poprawnie — czcionki monospace się ładują, podświetlanie składni działa, a przewijanie poziome pojawia się przy długich liniach.
• Listy renderują się z poprawnymi znacznikami — listy uporządkowane pokazują numery, listy nieuporządkowane pokazują punktory, a zagnieżdżenie jest wizualnie czytelne.

Responsywność

Błędy responsywności stanowią nieproporcjonalnie dużą część zgłaszanych przez użytkowników problemów wizualnych:

• Układ mobilny (szerokość 375px) — zweryfikuj pełną stronę przy typowej szerokości mobilnej. Nawigacja zwija się do hamburgera, obrazy skalują się, a treść układa się pionowo.
• Układ tabletowy (szerokość 768px) — to tutaj kryje się większość błędów responsywności. Układy dwukolumnowe powinny przechodzić płynnie, a cele dotykowe powinny mieć odpowiedni rozmiar.
• Układ desktopowy (szerokość 1440px) — główne doświadczenie na desktopie. Układy wielokolumnowe wyświetlają się poprawnie, a maksymalne szerokości treści są respektowane.
• Szeroki desktop (1920px+) — treść nie powinna rozciągać się na pełną szerokość ultraszerokich ekranów. Sprawdź, czy maksymalne szerokości i centrowanie działają poprawnie.
• Zmiana orientacji — na urządzeniach mobilnych i tabletach przełączanie między trybem pionowym a poziomym nie powinno psuć układu.
• Zachowanie przy powiększeniu — powiększenie przeglądarki do 150% i 200% nie powinno powodować nakładania się ani ukrywania treści.

Renderowanie międzyprzeglądarkowe

Różne silniki przeglądarek interpretują CSS w odmienny sposób. Sprawdź przynajmniej te kombinacje:

• Chrome desktop — Twoje bazowe renderowanie. Większość użytkowników zobaczy tę wersję.
• Firefox desktop — wyłapuje problemy specyficzne dla silnika Gecko z flexbox gap, metrykami czcionek i właściwościami niestandardowymi.
• Safari desktop — WebKit ma unikalne zachowania dla backdrop-filter, position-sticky i flex-wrap.
• Safari mobile (iOS) — wszystkie przeglądarki na iOS korzystają z WebKit. Obsługa viewportu, safe-area insets i zachowanie przewijania różnią się od wersji desktopowej.
• Chrome mobile (Android) — zweryfikuj cele dotykowe, zachowanie viewport meta i stylowanie specyficzne dla urządzeń mobilnych.

Nie musisz sprawdzać każdej przeglądarki dla każdej strony. Ustal priorytety na podstawie danych o ruchu: pokryj kombinacje reprezentujące 90% Twoich odbiorców. Więcej o budowaniu macierzy przeglądarek znajdziesz w naszym przewodniku po testowaniu regresji wizualnej.

Stany interaktywne

Elementy interaktywne mają wiele stanów wizualnych. Każdy z nich wymaga weryfikacji:

• Przyciski — stany: domyślny, hover, focus, active, disabled i loading — wszystkie renderują się poprawnie i są wizualnie rozróżnialne.
• Pola formularzy — stany: puste, aktywne, wypełnione, błąd i wyłączone. Sprawdź, czy komunikaty błędów pojawiają się we właściwym miejscu i nie przesuwają układu.
• Nawigacja — wskaźnik aktywnej strony, efekty hover na linkach, menu rozwijane otwierające i zamykające się we właściwej pozycji.
• Modale i dialogi — otwierają się płynnie, centrują poprawnie na wszystkich rozmiarach ekranu i wyświetlają widoczne tło. Przycisk zamknięcia jest dostępny.
• Tooltipy i popovery — pojawiają się we właściwej pozycji względem elementu wyzwalającego. Nie są obcinane przez kontenery z overflow-hidden ani krawędź viewportu.
• Stany ładowania — ekrany szkieletowe, spinnery i paski postępu wyświetlają się poprawnie podczas pobierania danych.

Obrazy i multimedia

Media wizualne wymagają osobnego zestawu sprawdzeń:

• Obrazy ładują się i wyświetlają — brak ikon uszkodzonego obrazu. Wszystkie obrazy mają odpowiedni tekst alternatywny dla celów dostępności.
• Obrazy mają prawidłowy rozmiar — brak zniekształceń ani nieoczekiwanego kadrowania. Proporcje są zachowane.
• Obrazy responsywne serwują odpowiednie rozmiary — urządzenia mobilne nie pobierają obrazów o rozmiarze desktopowym.
• Osadzone wideo działają — przyciski odtwarzania się wyświetlają, proporcje są prawidłowe, a osadzenia nie wychodzą poza swoje kontenery.
• Ikony renderują się poprawnie — ikony SVG wyświetlają się w prawidłowym rozmiarze i kolorze. Czcionki ikon ładują się bez pokazywania znaków zastępczych.

Dostępność i kolory

Wizualne QA i dostępność w znacznym stopniu się pokrywają:

• Kontrast kolorów spełnia WCAG AA — tekst i elementy interaktywne mają wystarczający kontrast wobec tła. Sprawdź zarówno jasny, jak i ciemny motyw, jeśli dotyczy.
• Wskaźniki fokusu są widoczne — nawigacja klawiaturą powinna pokazywać wyraźny pierścień fokusu na wszystkich elementach interaktywnych.
• Tryb ciemny renderuje się poprawnie — jeśli Twoja aplikacja obsługuje tryb ciemny, zweryfikuj, czy wszystkie komponenty, obrazy i tekst są czytelne w obu motywach.
• Informacje nie są przekazywane wyłącznie kolorem — stany błędów, wskaźniki statusu i pola wymagane używają ikon lub tekstu oprócz koloru.

Sprawdzenia wizualne związane z wydajnością

Problemy z wydajnością mogą objawiać się jako problemy wizualne:

• Brak przesunięć układu podczas ładowania — treść nie przeskakuje, gdy ładują się czcionki, obrazy lub skrypty. Mierzy się to wskaźnikiem Cumulative Layout Shift (CLS).
• Czcionki webowe ładują się przed renderowaniem — brak błysku niestylizowanego tekstu (FOUT) ani niewidocznego tekstu (FOIT) podczas ładowania strony.
• Treść above-the-fold renderuje się szybko — widoczna część strony powinna pojawić się w ciągu 1–2 sekund przy dobrym połączeniu.

Workflow weryfikacji przedwydaniowej

Stosuj ten workflow, aby przeprowadzać checklistę konsekwentnie:

1. Wdróż na staging — weryfikuj w środowisku, które jak najdokładniej odwzorowuje produkcję.
2. Uruchom automatyczne testy zrzutów ekranu — wykonaj wzorce bazowe w macierzy przeglądarek i urządzeń. Instrukcje konfiguracji znajdziesz w naszym przewodniku po automatyzacji CI/CD.
3. Przejrzyj automatyczne diffy — sklasyfikuj każdy diff jako celowy, regresję lub szum.
4. Przeprowadź ręczne wyrywkowe sprawdzenia — testy automatyczne obejmują statyczne renderowanie. Ręcznie zweryfikuj stany interaktywne, animacje i przypadki brzegowe.
5. Udokumentuj wyniki — zapisz, które sprawdzenia przeszły, które nie, i co zostało naprawione. Tworzy to ścieżkę audytu dla przyszłych wydań.
6. Zatwierdź lub zablokuj — jeśli wszystkie sprawdzenia przeszły, zatwierdź wydanie. Jeśli pozostały krytyczne błędy wizualne, zablokuj do momentu ich naprawienia.

Dostosowanie checklisty do Twojego zespołu

Ta checklista jest celowo kompleksowa. Dostosuj ją do swojego zespołu w oparciu o:

• Twój stos technologiczny — jeśli nie obsługujesz trybu ciemnego, usuń te sprawdzenia. Jeśli korzystasz z systemu projektowego, dodaj sprawdzenia na poziomie komponentów.
• Twoich odbiorców — jeśli 95% Twojego ruchu pochodzi z Chrome, ogranicz zakres testów międzyprzeglądarkowych i zwiększ testowanie mobilne.
• Twoją tolerancję na ryzyko — aplikacje generujące przychody potrzebują ściślejszych sprawdzeń. Narzędzia wewnętrzne mogą korzystać z lżejszego procesu.

Kluczem jest konsekwencja. Krótsza checklista przeprowadzana przy każdym wydaniu ma większą wartość niż kompleksowa, która jest pomijana pod presją terminu.

Zacznij korzystać z ScanU

Automatyczne testowanie zrzutami ekranu obsługuje najbardziej czasochłonne części tej checklisty: weryfikację układu, renderowanie międzyprzeglądarkowe i sprawdzanie responsywnych breakpointów. ScanU wykonuje zrzuty ekranu w różnych przeglądarkach i na różnych urządzeniach, dzięki czemu Twój zespół może skupić się na stanach interaktywnych i przypadkach brzegowych. Sprawdź dostępne plany na stronie Cennik, poznaj platformę na Funkcje i znajdź odpowiedzi na najczęstsze pytania w FAQ.