Buduj pokrycie wokół zadań klienta
Wypisz trasy i wyniki, które tworzą wartość: znalezienie usługi, wyszukiwanie, dodanie przedmiotu, rezerwacja, logowanie, prośba o pomoc lub płatność. Dla każdego określ komponenty, które mogą zmienić kształt lub zawieść: nawigacja, filtry, kafelki, tabele, obrazy, banery, formularze, wysuwane panele oraz osadzone widżety. Testuj szerokości, w których Twoja zawartość staje się ograniczona, a nie jedynie katalog aktualnych modeli telefonów. Testuj tuż poniżej, w punkcie i tuż powyżej każdego punktu przerwania (breakpoint).
Uwzględnij wąskie i średnie szerokości telefonów, szerokość przypominającą tablet, laptop, szeroki desktop oraz orientację poziomą, gdy zmienia ona zadanie.
Użyj długich tytułów, pustych wyników, błędów walidacji, plakietek cenowych, pełnych adresów i dłuższych etykiet, jeśli te stany występują.
Udowodnij przepływ, czytelność i powiększenie
Potwierdź, że strona ma odpowiednie ustawienie viewport, a potem sprawdź przewijanie poziome na poziomie strony. Stałe obrazy, szerokie pola, ujemne marginesy, panele poza ekranem i banery są częstymi przyczynami. Kryterium Reflow WCAG 2.1 opisuje zawartość przewijaną pionowo przy szerokości odpowiadającej 320 pikselom CSS, włączając widok 1280 pikseli przy 400% powiększeniu. Jeśli to kryterium jest w zakresie, testuj rzeczywisty scenariusz zoomu. Mapa, wideo lub tabela danych mogą wymagać dwuwymiarowego układu, ale trzymaj przewijanie w obrębie komponentu i pozwól, by otaczająca strona się przepływała (reflow).
Kontroluj nagłówki, główną treść, stopki, paski przyklejone (sticky), dialogi oraz podsumowania błędów przy każdej testowanej granicy.
Przeorganizuj informację na wąskim ekranie; nie usuwaj cicho wymagań, szczegółów ceny ani ścieżki pomocy.
Obciążaj treści i formularze
Operacje na treści mogą powodować błędy responsywne bez wydania zmian w CSS. Testuj najdłuższy zatwierdzony nagłówek, kilka plakietek, brakujący obraz, wybrany filtr, duże ostrzeżenie prawne oraz pole wypełnione przez przeglądarkę. Gdy kolumny się układają jedna pod drugą, potwierdź, że kolejność czytania i kolejność focusu klawiatury nadal mają sens. Wypełnij rzeczywisty formularz na małym urządzeniu: otwórz kontrolki, popraw błąd i wyślij. Testuj widżety firm trzecich na stronie przypominającej produkcję, ponieważ ich kontener, stan zgody, fonty i style mogą zmienić rezultat.
Oddaj prawdopodobne maksymalne długości i kombinacje, ale nie umieszczaj danych klientów ani danych płatniczych w dowodach QA.
Otwórz powiadomienia, czat, promocje i komunikaty walidacyjne jednocześnie; żaden z nich nie powinien zasłaniać głównej akcji ani aktywnego pola.
Ćwicz wszystkie ścieżki wejścia
Duży ekran nie gwarantuje myszy, a mały ekran nie oznacza tylko dotyku. Funkcja mediów hover testuje, czy główne wejście może wygodnie używać hovera, dlatego hover powinien wzbogacać, a nie być jedyną drogą do akcji czy wyjaśnienia. Testuj użycie klawiatury i wskaźnika na desktopie, stuknięcia i przewijanie na urządzeniu dotykowym oraz urządzenia mieszane tam, gdzie to istotne. Przejrzyj małe przyciski zamykania, sterowniki krokowe (steppers), elementy typu chip, kalendarze i ikony akcji. WCAG 2.2 Target Size (Minimum) definiuje cel o rozmiarze 24 na 24 piksele CSS z określonymi wyjątkami, w tym odstępami i linkami inline. To kryterium z zakresem i wyjątkami, a nie obietnica, że każdy kontrolka 24-pikselowa jest równie wygodna dla wszystkich.
Przechodź klawiszem Tab przez stronę. Focus powinien pozostać widoczny, podążać sensowną kolejnością i przewidywalnie wchodzić i wychodzić z menu oraz dialogów.
Spraw, by istotne ujawnienia zależne od hover były dostępne przez focus, stuknięcie lub widoczny kontroler, i zapobiegaj mylącemu zachowaniu przy pierwszym stuknięciu.
Weryfikuj zasoby i wydajność w warunkach ograniczonych
Obraz może dopasować się do kontenera i nadal być niewłaściwym plikiem dla urządzenia. Sprawdź, czy media pozostają w obramowaniu, rezerwują miejsce w układzie tam, gdzie to ma sens, zachowują użyteczny przycin (crop) i żądają odpowiednich kandydatów. Srcset i sizes dają przeglądarce informacje, by wybrała spośród dostarczonych źródeł; nie gwarantują one konkretnego żądania. Używaj throttlingu w DevTools, aby odkryć problemy wcześnie, ale jego sterowanie CPU i siecią symuluje warunki względem komputera deweloperskiego. Ponownie sprawdź kluczowe ścieżki na rzeczywistym urządzeniu i połączeniu. Kontroluj fonty, materiały hero, karuzele, prace po stronie klienta i skrypty firm trzecich pod kątem opóźnień, przesunięć lub zablokowanych stuknięć.
Zarejestruj trasę, widok, rzeczywiste lub symulowane połączenie oraz co stało się wolne lub niestabilne; porównuj podobne warunki.
Tam, gdzie to bezpieczne, opóźnij osadzenia nieistotne w buildzie testowym, aby sprawdzić, czy rdzeń zadania pozostaje użyteczny.
Naprawiaj proaktywnie jako pracę nad dostępnością (uptime)
Dla Status Is UP, gotowość responsywna to proaktywna optymalizacja dostępności działania: zidentyfikuj ścieżkę blokującą użytkownika na urządzeniu, popraw jej przyczynę, udowodnij naprawę i zapobiegnij ponownemu wystąpieniu. To nie jest twierdzenie, że alert monitoringu może ocenić każdy błąd układu czy interakcji. Priorytetyzuj według wpływu zadania i zasięgu. Przed wdrożeniem przetestuj sąsiednie szerokości i zmienioną ścieżkę na rzeczywistym sprzęcie. Zaplanuj rollback dla zmian współdzielonej nawigacji, stylów, skryptów, płatności lub integracji. Po wydaniu powtórz kroki potwierdzające i dołącz dowody do zapisu zmiany.
Określ trasę, urządzenie lub viewport, orientację, wejście, stan, oczekiwany wynik, faktyczny wynik oraz zredagowany zrzut ekranu.
Wybieraj naprawy komponentu, reguły układu, tokenu lub dostarczania obrazu zamiast obejścia tylko dla jednej trasy; przydziel właściciela i plan usunięcia wyjątków.