„Sprawdziłem na swoim komputerze i działa" – to zdanie słyszę regularnie i za każdym razem trochę mnie mrozi. Twój komputer, Twoja przeglądarka i Twoje łącze internetowe to jeden konkretny przypadek. Twoi klienci korzystają z setek różnych urządzeń, systemów, przeglądarek i rozdzielczości ekranów. To, że strona działa u Ciebie, nie znaczy, że działa dla nich.
Co właściwie znaczy „przetestowana strona"?
Testowanie strony internetowej to nie kliknięcie raz w kilka przycisków i stwierdzenie, że się nie wysypała. To systematyczne sprawdzanie, czy strona działa poprawnie w różnych warunkach – na różnych urządzeniach, przeglądarkach, przy różnych rozmiarach okna, z wolniejszym internetem, z klawiaturą zamiast myszki, z wyłączonym JavaScript i dziesiątkami innych scenariuszy, o których projektant zwykle w ogóle nie myśli podczas budowania.
Co się psuje bez testowania
Z własnego doświadczenia QA – oto rzeczy, które najczęściej wyglądają dobrze na desktopie dewelopera, a sypią się w praktyce:
Najczęstszy i najbardziej kosztowny błąd. Klient wypełnia formularz, klika „wyślij", widzi komunikat „dziękujemy" – a wiadomość nigdy nie dociera. Właściciel strony dowiaduje się o tym po miesiącu, gdy zastanawia się, czemu nie ma zapytań.
Strona świetnie wygląda na 1920px i na 375px (iPhone), ale na 768px (popularne tablety i małe laptopy) tekst wychodzi poza kontener, przyciski się nakładają albo zdjęcie przykrywa menu. Nikt tego nie sprawdził, bo wszyscy testowali tylko na swoich ekranach.
Safari jest znane z tego, że interpretuje CSS inaczej niż Chrome i Firefox. Rzeczy, które działają wszędzie indziej, potrafią w Safari wyglądać lub zachowywać się zupełnie inaczej. A Safari to przeglądarka domyślna na każdym iPhonie – czyli dla bardzo dużej części odwiedzających.
Podczas budowania strony deweloper zwykle ma szybkie łącze i widzi stronę w ułamku sekundy. Klient na telefonie z LTE w centrum galerii handlowej może czekać kilka sekund. Przy zbyt dużych zdjęciach bez optymalizacji – jeszcze dłużej. Większość użytkowników zamknie stronę zanim się załaduje.
Literówka w href, zmiana nazwy podstrony bez aktualizacji linku, link do zewnętrznej strony, która już nie istnieje. Użytkownik klika i dostaje błąd 404. Drobnostka, która podkopuje zaufanie i niszczy SEO.
Dlaczego to ważne akurat przy stronie wizytówkowej?
Przy rozbudowanej aplikacji błędy są nieuniknione i wszyscy o tym wiedzą – jest czas na poprawki, jest QA, są wersje beta. Przy stronie wizytówkowej klient często zakłada, że skoro to „tylko strona", to po prostu działa. Tymczasem to właśnie strony wizytówkowe mają często największe konsekwencje błędów – bo odwiedzający to potencjalny klient, który odwiedza ją raz, wyrabia sobie zdanie w kilka sekund i albo dzwoni, albo wychodzi i idzie do konkurencji.
Zawodowo zajmuję się testowaniem oprogramowania, więc do każdej strony podchodzę z tym samym nastawieniem co do projektu software'owego: sprawdzam scenariusze brzegowe, testuję na różnych urządzeniach i przeglądarkach, weryfikuję formularze, linki i zachowanie przy różnych rozmiarach okna. Nie dlatego, że jestem perfekcjonistką – ale dlatego, że błędy kosztują, a testowanie jest po to, żeby ich nie było.