Testowanie strony internetowej przed publikacją - co sprawdzić, zanim zobaczą ją użytkownicy?

Strona internetowa wygląda dobrze, wszystkie podstrony są gotowe, a wykonawca zapewnia, że można ją już publikować. Czy to oznacza koniec pracy? Niekoniecznie. Dopiero podczas testowania okazuje się czasem, że formularz kontaktowy nie wysyła wiadomości, na telefonie znika fragment menu, część odnośników prowadzi donikąd, a wyszukiwarka może indeksować adresy, które powinny pozostać ukryte. Niektóre błędy są widoczne od razu, inne wychodzą na jaw dopiero po kilku tygodniach. Przed uruchomieniem witryny warto więc przeprowadzić serię testów technicznych i użytkowych. Nie trzeba do tego rozbudowanego zaplecza ani płatnego oprogramowania.

Od czego zacząć testowanie strony internetowej?

Najpierw trzeba ustalić, co właściwie ma robić gotowa strona. W przypadku prostego serwisu firmowego najważniejsze będzie poprawne wyświetlanie oferty, łatwy kontakt i możliwość znalezienia podstawowych informacji. Sklep internetowy wymaga dodatkowo sprawdzenia koszyka, płatności, dostępności produktów i procesu zamawiania. Portal informacyjny będzie miał jeszcze inne wymagania, związane chociażby z wyszukiwarką treści, paginacją czy obsługą dużej liczby artykułów.

Zakres testów zależy również od rodzaju witryny. Pojedynczy landing page, przygotowany pod konkretną kampanię, można przeanalizować stosunkowo szybko. Rozbudowany serwis z wieloma kategoriami i dodatkowymi modułami wymaga sprawdzenia większej liczby zależności. Różnice między tymi rozwiązaniami, także z punktu widzenia ich zastosowania, opisano w artykule landing page czy rozbudowana strona internetowa. Przy testowaniu ma to praktyczne znaczenie: nie ma sensu przygotowywać identycznej procedury dla wizytówki firmy i portalu zawierającego kilka tysięcy podstron.

Pracę najlepiej prowadzić na środowisku testowym, możliwie zbliżonym do przyszłego serwera produkcyjnego. Powinno ono korzystać z porównywalnej wersji PHP, bazy danych, konfiguracji serwera i aktywnych rozszerzeń. W przeciwnym razie strona może działać prawidłowo podczas przygotowań, a po przeniesieniu pojawią się błędy wynikające z różnic w środowisku.

Przydatna jest również zwykła lista kontrolna. Nie musi być szczególnie rozbudowana. Wystarczy arkusz z nazwą testowanej funkcji, oczekiwanym wynikiem, rzeczywistym rezultatem i informacją, czy błąd został usunięty. Przy większych projektach można dodatkowo określić wagę problemu. Niedziałająca płatność w sklepie powinna mieć zdecydowanie wyższy priorytet niż niewielkie przesunięcie elementu graficznego.

Linki, nawigacja i struktura adresów URL

Jednym z najprostszych testów jest przejście przez menu strony i sprawdzenie wszystkich najważniejszych odnośników. Brzmi banalnie, ale przy kilkudziesięciu podstronach łatwo przeoczyć adres prowadzący do usuniętego artykułu, starej kategorii albo nieistniejącego pliku PDF. Problem bywa szczególnie częsty po migracji strony z innego systemu CMS lub zmianie struktury adresów.

Ręczne sprawdzanie wystarcza przy niewielkiej witrynie. W przypadku większego serwisu lepiej skorzystać z programu indeksującego odnośniki, na przykład Screaming Frog SEO Spider. Narzędzie przechodzi po adresach podobnie jak robot wyszukiwarki i pozwala wykryć odpowiedzi serwera oznaczające błędy, przekierowania oraz niektóre problemy z metadanymi. Trzeba jednak pamiętać, że analiza automatyczna nie zastąpi sprawdzenia działania menu, przycisków i elementów obsługiwanych przez JavaScript.

Najważniejsze kody odpowiedzi HTTP to 200, 301, 302, 404 i 500. Pierwszy oznacza poprawną odpowiedź na żądanie, dwa kolejne informują o przekierowaniach, 404 wskazuje na brak żądanego zasobu, a 500 na wewnętrzny błąd serwera. Nie każdy kod inny niż 200 musi oznaczać problem. Przekierowanie 301 może być całkowicie prawidłowe, jeśli stary adres został trwale zastąpiony nowym.

Osobno należy sprawdzić sposób budowania adresów. Jedna podstrona nie powinna być przypadkowo dostępna pod kilkoma wariantami URL bez odpowiedniej kanonikalizacji lub przekierowania. Dotyczy to między innymi wersji z www i bez www, protokołów HTTP i HTTPS, a czasami również końcowych ukośników. Szczególnie niebezpieczne są wieloetapowe łańcuchy przekierowań oraz sytuacje, w których dwa adresy odsyłają do siebie nawzajem.

Jak sprawdzić formularze i pozostałe funkcje strony?

Formularz kontaktowy potrafi wyglądać zupełnie poprawnie, a mimo to nie wysyłać żadnych wiadomości. Samo pojawienie się komunikatu "Wysłano pomyślnie" nie stanowi jeszcze dowodu, że e-mail rzeczywiście dotarł do odbiorcy. Trzeba przeprowadzić pełny test: wypełnić formularz, przesłać dane, sprawdzić odpowiedź aplikacji i potwierdzić dostarczenie wiadomości do wskazanej skrzynki.

Jeżeli formularz korzysta z poczty wysyłanej przez serwer, warto sprawdzić konfigurację SMTP lub innego mechanizmu dostarczania wiadomości. Problemy mogą wynikać z błędnego uwierzytelniania, niewłaściwego adresu nadawcy, ograniczeń hostingu albo ustawień SPF, DKIM i DMARC. Te ostatnie mechanizmy pomagają serwerom odbiorczym oceniać autentyczność wiadomości, choć same nie gwarantują ich dostarczenia.

Formularz należy też przetestować przy błędnych danych. Co stanie się po pozostawieniu pustego pola obowiązkowego? Czy nieprawidłowy adres e-mail zostanie odrzucony? Czy można wysłać załącznik przekraczający dozwolony rozmiar? Walidacja wykonywana wyłącznie w przeglądarce nie jest wystarczającym zabezpieczeniem - aplikacja musi również sprawdzać dane po stronie serwera.

Podobnie trzeba postąpić z wyszukiwarką, filtrami, logowaniem i pozostałymi interaktywnymi elementami. Test powinien uwzględniać nie tylko prawidłowe działanie, lecz także sytuacje wyjątkowe. Przykładowo wyszukiwarka powinna sensownie reagować na zapytanie, dla którego nie znaleziono żadnego wyniku, zamiast wyświetlać pustą stronę albo komunikat o błędzie aplikacji.

Testowanie strony na telefonach i różnych przeglądarkach

Responsywny szablon nie daje gwarancji, że witryna będzie wygodna na każdym urządzeniu. Elementy mogą zmieniać układ zgodnie z szerokością ekranu, ale nadal pozostawać zbyt małe do obsługi palcem. Zdarzają się również przyciski zasłaniane przez wyskakujące okna, tabele wychodzące poza ekran i menu, którego nie da się zamknąć.

Pierwszy etap testowania można wykonać bezpośrednio w przeglądarce. W Chrome, Firefoxie i Edge dostępne są narzędzia deweloperskie umożliwiające symulowanie różnych rozdzielczości. Zwykle otwiera się je klawiszem F12, a następnie wybiera tryb widoku mobilnego. Warto sprawdzić kilka szerokości ekranu, nie ograniczając się wyłącznie do gotowych profili popularnych telefonów.

Taka symulacja pokazuje jednak tylko część problemów. Nie odtwarza idealnie zachowania fizycznego urządzenia, rzeczywistej klawiatury ekranowej ani wszystkich cech przeglądarki mobilnej. Dlatego przed publikacją dobrze otworzyć stronę przynajmniej na jednym telefonie z Androidem i jednym urządzeniu Apple, jeżeli są dostępne. Szczególną uwagę należy zwrócić na formularze, rozwijane menu, galerie i elementy przyklejone do krawędzi ekranu.

Przydatny jest również test dostępności z użyciem klawiatury. Spróbuj przejść przez stronę za pomocą klawisza Tab, bez korzystania z myszy. Powinno być jasne, który element jest aktualnie aktywny, a rozwijane menu i przyciski muszą reagować na odpowiednie polecenia. Wiele błędów niedostrzegalnych podczas zwykłego przeglądania wychodzi na jaw właśnie w ten sposób.

Szybkość ładowania i podstawowe testy wydajności

Strona może działać błyskawicznie na komputerze wykonawcy, a na przeciętnym telefonie z wolniejszym połączeniem ładować się przez kilka sekund. Dlatego ocenianie wydajności wyłącznie na podstawie własnych odczuć jest mało miarodajne. Lepiej skorzystać z narzędzi takich jak Google PageSpeed Insights, Lighthouse albo panel Network w narzędziach deweloperskich przeglądarki.

Nie warto jednak sprowadzać całej oceny do jednego wyniku punktowego. Istotne są konkretne wskaźniki, w tym Largest Contentful Paint (LCP), Interaction to Next Paint (INP) i Cumulative Layout Shift (CLS). Pierwszy odnosi się do czasu wyświetlenia największego istotnego elementu treści, drugi mierzy responsywność interakcji, a trzeci opisuje nieoczekiwane przesunięcia układu strony.

Za dobre wartości przy 75. percentylu pomiarów rzeczywistych użytkowników przyjmuje się zwykle LCP nieprzekraczające 2,5 sekundy, INP nieprzekraczające 200 ms i CLS nieprzekraczające 0,1. Trzeba przy tym odróżnić dane laboratoryjne od rzeczywistych. Raport wygenerowany w Lighthouse jest symulacją określonych warunków, podczas gdy dane terenowe pokazują doświadczenia prawdziwych odwiedzających, o ile zostały zebrane w wystarczającej liczbie.

W praktyce najczęściej warto zacząć od obrazów, skryptów i sposobu ładowania czcionek. Zdjęcie o wymiarach kilku tysięcy pikseli, wyświetlane w niewielkim kontenerze, może niepotrzebnie zwiększać transfer. Zbyt dużo skryptów JavaScript opóźnia interakcje, a brak określonych wymiarów grafik sprzyja przesuwaniu elementów podczas ładowania. Trzeba też sprawdzić buforowanie zasobów i kompresję danych po stronie serwera.

Indeksowanie, przekierowania i ustawienia SEO

Jednym z bardziej dotkliwych błędów przy uruchamianiu strony jest pozostawienie ustawień blokujących indeksowanie. W czasie prac nad witryną takie ograniczenie bywa celowe, ale po publikacji może uniemożliwić robotom wyszukiwarek dodawanie nowych adresów do wyników. W systemach CMS trzeba więc sprawdzić, czy nie pozostawiono globalnych ustawień ograniczających widoczność strony.

Należy przeanalizować plik robots.txt, znaczniki meta robots i nagłówki X-Robots-Tag. Każdy z tych mechanizmów ma inne zastosowanie. Ważne jest między innymi to, że zablokowanie adresu w robots.txt nie jest równoznaczne z pewnym usunięciem go z indeksu Google. Jeżeli robot nie może pobrać strony, nie musi zobaczyć umieszczonego na niej znacznika noindex.

Dobrze również sprawdzić mapę XML. Powinna zawierać właściwe, kanoniczne adresy przeznaczone do indeksowania, a nie przypadkowe przekierowania, strony błędów czy podstrony oznaczone noindex. Samo umieszczenie adresu w sitemapie nie daje gwarancji indeksacji, ale pomaga wyszukiwarce odkrywać zawartość serwisu.

Przy przenoszeniu istniejącej witryny szczególnego znaczenia nabierają przekierowania ze starych adresów na nowe. Zmiana systemu CMS, struktury kategorii lub sposobu generowania URL może spowodować, że wcześniej działające linki zaczną prowadzić do błędu 404. Trzeba przygotować mapę przekierowań i zweryfikować, czy najważniejsze adresy zachowują ciągłość dostępu do właściwych treści.

Przed uruchomieniem warto ponadto przejrzeć tytuły stron, nagłówki, opisy alternatywne obrazów i elementy nawigacyjne. Automatycznie wygenerowane tytuły typu "Home", "Nowa strona" albo "Untitled" nadal zdarzają się w publikowanych witrynach. To drobne przeoczenia, których poprawienie po wdrożeniu zajmuje więcej czasu niż podczas końcowej kontroli.

Bezpieczeństwo i konfiguracja serwera

Prawidłowo działający certyfikat TLS i obsługa HTTPS to absolutna podstawa, ale sam symbol kłódki w przeglądarce nie oznacza, że cała aplikacja jest bezpieczna. Trzeba sprawdzić, czy wszystkie zasoby ładują się przez bezpieczne połączenie, a żądania HTTP są prawidłowo przekierowywane na HTTPS. Problem mieszanej zawartości pojawia się na przykład wtedy, gdy witryna działa przez HTTPS, lecz próbuje pobrać grafikę lub skrypt przez niezabezpieczony protokół HTTP.

Warto zweryfikować aktualność systemu CMS, rozszerzeń i środowiska serwerowego. Niepotrzebne dodatki najlepiej usunąć, a konta administracyjne zabezpieczyć silnymi, unikalnymi hasłami i uwierzytelnianiem wieloskładnikowym, jeśli system je obsługuje. Konta przeznaczone dla redaktorów nie powinny otrzymywać uprawnień administratora wyłącznie dla wygody.

Kolejny etap to kontrola publicznego dostępu do plików. Kopie baz danych, archiwa instalacyjne, pliki konfiguracyjne i logi nie powinny być możliwe do pobrania przez przypadkowego użytkownika. Trzeba też sprawdzić, czy serwer nie ujawnia niepotrzebnych informacji diagnostycznych w komunikatach błędów. W środowisku produkcyjnym szczegółowe błędy aplikacji powinny trafiać do odpowiednio zabezpieczonych logów, a nie na ekran odwiedzającego.

Przed publikacją należy również wykonać kopię zapasową i sprawdzić możliwość jej odtworzenia. Posiadanie pliku z backupem nie daje jeszcze pewności, że w razie awarii uda się z niego skorzystać. Test odtwarzania na osobnym środowisku pozwala zweryfikować kompletność danych oraz procedurę przywracania witryny.

Jak sprawdzić, czy użytkownik poradzi sobie z obsługą strony?

Nawet witryna bez błędów technicznych może być trudna w obsłudze. Przycisk prowadzący do formularza znajduje się w nietypowym miejscu, nazwy kategorii są niezrozumiałe, a ważne informacje ukryto w rozbudowanym menu. Osoby pracujące nad projektem często przestają dostrzegać takie problemy, ponieważ doskonale znają jego strukturę. Dlatego dobrze poprosić o przetestowanie strony kogoś, kto widzi ją po raz pierwszy.

Nie trzeba organizować dużego badania. Można poprosić kilka osób o wykonanie prostych zadań, na przykład znalezienie konkretnej usługi, sprawdzenie kosztu dostawy, dotarcie do danych kontaktowych lub wysłanie zapytania. Ważne, żeby nie podpowiadać im kolejnych kroków. Jeśli użytkownik przez kilkadziesiąt sekund szuka przycisku, który projektant uważa za oczywisty, warto przyjrzeć się jego umiejscowieniu.

Takie sprawdzanie użyteczności jest częścią szerszego podejścia do analizy doświadczeń klientów. W materiale opisującym badania marketingowe i testowanie ścieżki użytkownika pokazano między innymi znaczenie obserwowania momentów, w których odwiedzający gubią się lub rezygnują z wykonania określonej czynności. Dla osoby przygotowującej stronę szczególnie cenne jest rozróżnienie między błędem technicznym a problemem wynikającym z nieczytelnego interfejsu.

Po uruchomieniu witryny można analizować rzeczywiste zachowania użytkowników, na przykład korzystając z danych analitycznych, statystyk wyszukiwarki wewnętrznej i testów poszczególnych elementów strony. Przy wdrażaniu narzędzi monitorujących należy jednak uwzględnić ochronę prywatności, sposób przetwarzania danych oraz wymagane ustawienia zgód. Nie każde narzędzie analityczne można uruchomić bez dodatkowej konfiguracji.

Lista kontrolna przed publikacją strony WWW

Końcowa kontrola powinna odbywać się po wprowadzeniu ostatnich zmian, a nie kilka dni wcześniej. Nawet drobna aktualizacja szablonu lub rozszerzenia może wpłynąć na działanie innych elementów. Dobrym rozwiązaniem jest wykonanie krótkiego testu regresji, czyli ponownego sprawdzenia najważniejszych funkcji, które wcześniej działały prawidłowo.

Po zakończeniu testów pozostaje jeszcze sprawdzić witrynę już na docelowym serwerze. To ważne, ponieważ konfiguracja środowiska produkcyjnego może różnić się od testowego. Należy ponownie skontrolować działanie formularzy, przekierowań, certyfikatu TLS, zadań automatycznych i mechanizmów buforowania. Warto również sprawdzić, czy serwis nie odwołuje się przypadkowo do adresów testowych.

Publikacja strony internetowej nie kończy jej testowania. Pierwsze dni działania są dobrym momentem na kontrolę logów serwera, błędów aplikacji, zgłoszeń użytkowników i danych dotyczących wydajności. Nie wszystkie problemy da się przewidzieć wcześniej, zwłaszcza jeśli serwis ma wiele funkcji lub obsługuje duży ruch. Dobrze przeprowadzona kontrola przed uruchomieniem pozwala jednak wyeliminować większość podstawowych usterek, zanim zaczną przeszkadzać odwiedzającym.