Wiedza Testin
Jak odebrać stronę internetową od wykonawcy — praktyczna lista testów
Strona wygląda dobrze na ekranie wykonawcy. Można już pokazać ją klientom, ale przed publikacją warto sprawdzić coś więcej niż kolory i układ. Czy zapytanie dociera do właściwej skrzynki? Czy menu działa na telefonie? Czy firma otrzyma dostęp do domeny, treści i kopii zapasowych? Odbiór strony internetowej powinien potwierdzać uzgodniony rezultat oraz możliwość późniejszego korzystania z niego.
Poniższa lista pomaga przygotować taki odbiór. Nie zastępuje zapisów umowy ani pełnego audytu technicznego. Pozwala jednak zebrać testy, uwagi i odpowiedzialności w jednym miejscu, zamiast kończyć projekt wiadomością „na pierwszy rzut oka wszystko działa”.
Najpierw ustal, co właściwie odbierasz
Punktem odniesienia jest zaakceptowany zakres: lista podstron, funkcji, materiałów oraz integracji. Oddziel brak elementu objętego ofertą od nowego pomysłu, który pojawił się podczas oglądania gotowej strony. Oba mogą być ważne, ale wymagają innej decyzji.
Dla każdej istotnej funkcji zapisz prosty scenariusz i oczekiwany efekt. „Formularz kontaktowy” to zbyt ogólne kryterium. „Użytkownik wysyła zapytanie z telefonu, widzi potwierdzenie, a wiadomość dociera do wskazanej skrzynki” można już sprawdzić.
- Zakres: co ma być dostępne w odbieranej wersji.
- Środowisko: na jakim adresie, urządzeniu i koncie wykonujesz test.
- Oczekiwany rezultat: co dokładnie ma wydarzyć się po działaniu użytkownika.
- Osoba odpowiedzialna: kto ocenia wynik i kto poprawia ewentualną usterkę.
Jeżeli projekt dopiero się zaczyna, przydatny będzie poradnik o porównywaniu wycen strony internetowej. Dobrze opisany zakres ułatwia późniejszy odbiór.
Przejdź rzeczywistą ścieżkę klienta
Nie ograniczaj testu do strony głównej. Zacznij także od podstrony usługi, realizacji lub artykułu — właśnie na takim adresie może rozpocząć wizytę klient. Spróbuj znaleźć ofertę, ustalić następny krok i skontaktować się z firmą.
W przykładowym serwisie gabinetu test może wyglądać tak: otwierasz opis konkretnej konsultacji, sprawdzasz informacje o przygotowaniu, znajdujesz sposób umówienia wizyty i przechodzisz do formularza lub telefonu. To przykład scenariusza, a nie opis wyniku konkretnego projektu Testin.
- Sprawdź menu, logo prowadzące do strony głównej, stopkę i linki do kontaktu.
- Otwórz najważniejsze dokumenty i sprawdź, czy ich nazwy odpowiadają zawartości.
- Przejrzyj treść: nazwy usług, dane firmy, numery telefonu, adresy i informacje o terminach.
- Sprawdź, czy przyciski prowadzą do właściwych miejsc, także po wejściu bezpośrednio na podstronę.
Przetestuj formularz od pola do skrzynki
Uzgodnij z wykonawcą bezpieczny test i oznacz wiadomość jako testową. Sprawdź poprawne wysłanie, brak wymaganego pola oraz błędny format adresu e-mail. Komunikat o powodzeniu nie powinien pojawiać się tylko dlatego, że kliknięto przycisk. Osobno potwierdź rzeczywiste dostarczenie wiadomości.
Po błędzie użytkownik powinien wiedzieć, co poprawić, i zachować już wpisane dane, o ile pozwala na to sposób działania formularza. Etykiety pól i zrozumiałe powiadomienia należą do zasad opisanych w poradniku formularzy W3C WAI.
Sprawdź też odpowiedzialność za dalszą obsługę: kto monitoruje skrzynkę, kto reaguje na problem z wysyłką i gdzie zmienić adres odbiorcy. Nie umieszczaj haseł do poczty lub hostingu w testowym formularzu.
Telefon, klawiatura i powiększony tekst
Otwórz stronę na rzeczywistym telefonie. Sprawdź menu, dłuższe nagłówki, formularz, zdjęcia oraz kontakt. Obróć ekran i powiększ tekst. Upewnij się, że elementy nie zasłaniają przycisków, a ważna treść nie wymaga przesuwania całej strony na boki.
Następnie użyj klawiatury: przechodź klawiszem Tab, aktywuj linki Enterem i sprawdź zamykanie otwartych paneli. Powinno być widać, który element ma focus. Wstępne sprawdzenia W3C WAI obejmują między innymi obsługę klawiaturą, teksty alternatywne i powiększanie. Takie testy mogą ujawnić problemy, lecz ich zaliczenie nie stanowi potwierdzenia pełnej zgodności z WCAG.
Sprawdź ustawienia publikacji i wyszukiwarek
Środowisko robocze może być chronione hasłem lub wyłączone z indeksowania. Przed startem trzeba ustalić, które zabezpieczenia pozostają na wersji testowej, a które należy zmienić na publicznej.
Poproś o potwierdzenie, że najważniejsze publiczne adresy działają, Googlebot nie jest przypadkowo zablokowany i strony mają treść możliwą do indeksowania. Są to minimalne wymagania techniczne Google; ich spełnienie nie gwarantuje indeksowania ani pozycji.
Przejrzyj również tytuły podstron. Powinny opisywać konkretną zawartość, a nie wszędzie powtarzać „Strona główna”. Takie podejście jest zgodne z zaleceniami Google dotyczącymi tytułów wyników. Przy przebudowie istniejącego serwisu sprawdź dodatkowo uzgodnioną mapę starych i nowych adresów.
Zapisz uwagi i odbierz dostęp do projektu
Lista uwag jest najbardziej użyteczna, gdy każdy punkt zawiera adres strony, kroki odtworzenia, oczekiwany rezultat i zrzut ekranu. „Na telefonie coś się rozjeżdża” trudno sprawdzić. „Na podstronie usługi, przy szerokości 320 px, przycisk formularza jest zasłonięty przez panel” wskazuje konkretną sytuację.
Rozdziel uwagi blokujące publikację, pozostałe poprawki i prace dodatkowe. Priorytety oraz termin zakończenia uzgodnijcie wspólnie. W protokole można zapisać:
- wersję i adres odbieranego serwisu oraz datę sprawdzenia;
- zakres wykonanych testów i zaakceptowane elementy;
- otwarte uwagi, osoby odpowiedzialne i uzgodnione terminy;
- przekazane konta, instrukcje, licencje i zasady kopii zapasowych;
- początek oraz zakres późniejszego wsparcia wynikający z umowy.
Ustal, kto jest właścicielem kont domeny, hostingu i usług zewnętrznych. Dostępy przekazujcie bezpiecznym, uzgodnionym kanałem. Dla istniejącej witryny więcej szczegółów znajdziesz w poradniku o przejęciu strony WordPress po innym wykonawcy.
Przy projekcie strony internetowej warto ustalić sposób odbioru już na etapie zakresu. Wtedy obie strony wiedzą, co sprawdzają, a publikacja kończy się konkretną decyzją zamiast zgadywania.
