Responsive testing strony WWW: narzędzia, scenariusze i szybka checklista QA

Responsive testing ma odpowiedzieć na proste pytanie: czy użytkownik na telefonie może bez frustracji wykonać najważniejszą akcję? Samo “strona się skaluje” nie wystarcza. Trzeba sprawdzić menu, formularze, tabele, sticky elementy, obrazy, przyciski i treść.

Najlepszy workflow jest krótki: najpierw test statyczny w kilku viewportach, potem prawdziwy telefon albo emulator, na końcu szybki przegląd konsoli, sieci i elementów przewijających stronę w poziomie.

Viewporty, które warto sprawdzać

Widok	Przykładowy rozmiar	Co najczęściej pęka
Mały telefon	360×740	menu, CTA, długie nagłówki, cookie bar
Standardowy telefon	390×844	formularze, odstępy, karty ofert
Duży telefon	430×932	hero, sticky przyciski, sekcje z obrazami
Tablet	768×1024	grid 2 kolumny, sidebar, układ cennika
Desktop	1366×768	maksymalna szerokość treści i spacing

Minimalny zestaw narzędzi

• Chrome DevTools Device Mode do szybkiego przechodzenia między viewportami.
• Realny telefon do sprawdzenia dotyku, klawiatury, paska adresu i przewijania.
• Lighthouse albo PageSpeed Insights do wyłapania problemów z obrazami, fontami i CLS.
• BrowserStack / Playwright przy większych projektach, gdzie trzeba powtarzać testy.
• Prosty skrypt DOM, który wykrywa poziomy overflow i zepsute obrazki.

Najczęstsze błędy mobile

1. Poziomy scroll strony. Zwykle winna jest tabela, blok kodu, obraz bez max-width albo grid z minimalną szerokością.
2. Za małe przyciski. CTA powinno być łatwe do kliknięcia kciukiem, nie tylko “ładne”.
3. Ukryta wartość oferty. Hero na mobile nie może zjadać całego ekranu bez konkretu.
4. Formularz walczy z klawiaturą. Pola, selecty i błędy walidacji muszą być widoczne po otwarciu klawiatury.
5. Obrazy ładują się za późno albo za ciężko. Hero i grafiki w kartach muszą mieć rozsądne rozmiary.

Szybki test overflow w konsoli

const overflow = document.documentElement.scrollWidth > window.innerWidth;
console.log({
  width: window.innerWidth,
  scrollWidth: document.documentElement.scrollWidth,
  overflow
});

Jeżeli scrollWidth jest większy niż szerokość okna, znajdź elementy szersze od viewportu. Najczęściej są to tabele, pre, iframe, mapy, karuzele albo grafiki.

Scenariusz QA dla strony firmowej

• Wejdź z mobile na stronę główną i sprawdź, czy pierwsze CTA jest widoczne bez szukania.
• Otwórz menu, przejdź do usługi, wróć i sprawdź, czy scroll nie blokuje strony.
• Wypełnij formularz kontaktowy błędnymi i poprawnymi danymi.
• Sprawdź jedną podstronę z tabelą lub cennikiem.
• Przejdź do bloga i zobacz, czy obrazy, kod i powiązane artykuły nie rozpychają widoku.

FAQ

Czy emulator w DevTools wystarczy?

Do większości szybkich poprawek tak, ale przed publikacją warto sprawdzić chociaż jeden realny telefon. Klawiatura, pasek adresu i dotyk potrafią zmienić wynik.

Jak często robić responsive testing?

Po każdej zmianie komponentów globalnych, menu, formularzy, cenników, tabel oraz sekcji hero. Przy aktywnej stronie dobrze dodać prosty test przed każdym deployem.

Co jest ważniejsze: tablet czy mały telefon?

Najpierw mały telefon. Jeżeli tam działa czytelność, CTA i formularz, tablet zwykle jest łatwiejszy do dopracowania.