Co dokładnie psuje się w koszyku po wdrożeniu?
Prawie nigdy nie jest to cały sklep. Serwer stoi, strona główna odpowiada kodem 200, a sprzedaż i tak spada do zera, bo pękł jeden krok w środku ścieżki. Takie awarie mają wspólną cechę: z zewnątrz wyglądają jak słabszy dzień, a nie jak awaria, więc potrafią trwać do pierwszego telefonu od klienta.
Najczęstsze źródła są cztery i wszystkie są normalnym skutkiem wdrożenia, a nie czyimś błędem. Pierwsze to zmiana w warstwie wizualnej: przebudowany szablon zmienia nazwy klas i identyfikatory, więc przycisk dodania do koszyka nadal wygląda tak samo, ale skrypt, który do niego mówił, trafia w pustkę. Drugie to pamięć podręczna: nowa wersja plików skryptów jedzie w świat, a przeglądarka klienta albo warstwa pośrednicząca trzyma starą i miesza obie. Trzecie to integracje: klucz do bramki płatności albo do kuriera zostaje ze środowiska testowego i na produkcji nie zostaje podmieniony. Czwarte to konfiguracja: podatki, koszt dostawy albo minimalna wartość zamówienia policzone dla nowego szablonu inaczej niż wcześniej.
Do tego dochodzi pułapka, która nie ma nic wspólnego z kodem. Wdrożenie idzie w godzinach, w których nikt nie kupuje, czyli wieczorem albo w weekend, a pierwszy prawdziwy klient pojawia się kilkanaście godzin później. Jeżeli nikt nie przeszedł ścieżki od razu, awaria czeka sobie w spokoju do rana.
Jaką ścieżkę przejść zaraz po wdrożeniu?
Zasada jest jedna: przejdź dokładnie to, co robi klient, w tej samej kolejności i w tej samej przeglądarce co on, a nie to, co sprawdza się najwygodniej. Poniższa lista zajmuje kilka minut i wyłapuje większość tego, co psuje się po wdrożeniu. Warto przejść ją dwa razy: raz jako gość, raz na koncie klienta, bo to dwie różne drogi przez ten sam sklep.
Karta produktu i wyszukiwarka
Wejdź na produkt z listy i przez wyszukiwarkę. Sprawdź cenę, dostępność i zdjęcie. Cena widoczna na liście i na karcie musi być ta sama, bo po zmianie szablonu to jedno z pierwszych miejsc, które się rozjeżdża.
Dodanie do koszyka
Kliknij przycisk i poczekaj na potwierdzenie. Patrz na licznik przy ikonie koszyka: jeżeli produkt jest w koszyku, a licznik pokazuje zero, widok nie odświeża się po wdrożeniu i część klientów kliknie drugi raz albo wyjdzie.
Zmiana ilości i usunięcie pozycji
Podnieś ilość, potem usuń produkt i dodaj ponownie. Wartość zamówienia ma się przeliczyć za każdym razem. Puste albo zamrożone pole z sumą to klasyczny skutek błędu skryptu na tej jednej podstronie.
Koszt dostawy i kod rabatowy
Wybierz kolejno każdą metodę dostawy i sprawdź, czy koszt się zmienia, a przy paczkomacie czy działa wybór punktu. Wpisz działający kod rabatowy i jeden nieistniejący: pierwszy ma obniżyć sumę, drugi dać czytelny komunikat, a nie ciszę.
Formularz zamówienia
Wypełnij dane, w tym pole NIP i adres do faktury. Sprawdź też odpowiedź na błąd: zostaw puste pole wymagane i zobacz, czy formularz mówi które. Po wdrożeniu psuje się częściej sprawdzanie danych niż samo wysyłanie.
Przejście do płatności
Kliknij zapłać i poczekaj na ekran operatora. To jest moment, w którym najczęściej kończy się cicha awaria: sklep działa, a bramka nie odpowiada albo odrzuca żądanie z powodu klucza ze środowiska testowego.
Powrót ze strony płatności
Sprawdź obie drogi powrotne: udaną i przerwaną. Klient, który zrezygnuje, ma wrócić do koszyka z zawartością, a nie do pustej strony. Ten przypadek sprawdza się najrzadziej i psuje najczęściej.
Potwierdzenie i zamówienie w panelu
Na końcu sprawdź to, co dzieje się po: strona z podziękowaniem, wiadomość e-mail do klienta i zamówienie widoczne w panelu sklepu ze wszystkimi pozycjami. Zamówienie, które powstaje, ale nie wysyła powiadomienia, wygląda z zewnątrz na sukces.
Jak przetestować płatność, nie wydając pieniędzy?
Są trzy uczciwe sposoby i każdy ma inne zastosowanie. Pierwszy to tryb testowy operatora płatności: bramka przyjmuje wtedy dane testowe opisane w jej dokumentacji, a żadne pieniądze nie zmieniają właściciela. To jedyna droga, która sprawdza całą płatność do końca, razem z powrotem do sklepu i zmianą statusu zamówienia, więc warto mieć ją przygotowaną przed wdrożeniem, a nie szukać jej w trakcie awarii.
Drugi sposób to produkt za symboliczną kwotę albo za 0 zł, ukryty przed wyszukiwarką sklepu i dostępny tylko pod znanym adresem. Zamówienie powstaje naprawdę, więc widać cały łańcuch: potwierdzenie, wiadomość e-mail, zamówienie w panelu, a potem po prostu się je anuluje. Trzeci sposób jest najtańszy i wystarcza po drobnych wdrożeniach: przejść ścieżkę do ekranu bramki i zatrzymać się na nim. Jeżeli ekran operatora pokazał się z poprawną kwotą, sklep dotarł do bramki i podał jej właściwe dane.
Czego nie robić: nie testuj płatności prawdziwą kartą firmową na produkcji, bo zwroty i faktury korygujące kosztują więcej pracy niż cały test, a przy powtarzaniu potrafią wyglądać w systemie operatora jak podejrzana seria. Nie zostawiaj też trybu testowego włączonego po sprawdzeniu. Włączony tryb testowy na produkcji jest gorszy od awarii: klient przechodzi całą ścieżkę, widzi podziękowanie, a pieniądze nigdy nie wpływają.
Czego nie zobaczysz, sprawdzając tylko na swoim komputerze?
Twoja przeglądarka jest najgorszym możliwym miejscem do sprawdzania sklepu po wdrożeniu, bo zna go za dobrze. Masz w niej zalogowaną sesję, ciasteczka sprzed wdrożenia, czasem podgląd wersji roboczej i blokadę reklam, która wycina skrypty działające u klienta. Dlatego pierwsze przejście rób w oknie prywatnym, a drugie w innej przeglądarce niż codzienna.
Druga różnica to urządzenie. Duża część ruchu w sklepie przychodzi z telefonu, a na telefonie ścieżka wygląda inaczej: przycisk potrafi schować się pod paskiem, pole kodu pocztowego wywołuje inną klawiaturę, a lista metod dostawy nie mieści się na ekranie. Przejście ścieżki na telefonie zajmuje dwie minuty i wyłapuje rzeczy, których na monitorze nie widać w ogóle.
Trzecia to sieć i lokalizacja. Sklep otwierany z biura, z tej samej sieci co serwer, omija po drodze wszystko, co dzieje się w publicznym internecie: rozwiązywanie nazw, certyfikat, warstwę pośredniczącą, ograniczenia dla ruchu spoza kraju. Jeżeli wdrożenie ruszyło cokolwiek w tej warstwie, sprawdzenie z biura powie, że jest dobrze, a klient zobaczy ostrzeżenie albo pustą stronę.
Co zapisać, gdy coś w koszyku padnie?
Zanim zaczniesz naprawiać, zbierz materiał, bo połowa takich awarii znika po odświeżeniu i wraca dopiero u klienta. Minimum to: dokładna godzina z sekundami, krok, na którym ścieżka pękła, adres strony, przeglądarka i urządzenie oraz zrzut ekranu z widocznym komunikatem. To wystarczy, żeby zgłoszenie do zespołu brzmiało konkretnie, a nie „coś się dzieje z koszykiem”.
Gdy błędu nie widać na ekranie, otwórz narzędzia dla programistów i zajrzyj w dwa miejsca: w konsolę, gdzie widać błędy skryptów, i w listę żądań sieciowych, gdzie widać, które wywołanie zwróciło kod błędu albo nie wróciło wcale. Tę listę da się zapisać do pliku HAR i dołączyć do zgłoszenia; jak go czytać, opisaliśmy osobno w tekście o pliku HAR w tej samej bazie wiedzy.
Zapisz też jedną rzecz, o której łatwo zapomnieć: co dokładnie zostało wdrożone i o której godzinie. Awaria koszyka, która zaczyna się dwadzieścia minut po wdrożeniu, ma inne prawdopodobne przyczyny niż ta, która zaczyna się w środku nocy bez żadnej zmiany po Waszej stronie.
Jak sprawdzać koszyk po każdym wdrożeniu, nie klikając za każdym razem?
Lista z drugiej sekcji ma jedną wadę: działa dokładnie raz, w dniu, w którym komuś się chciało. Wdrożeń jest kilkanaście w miesiącu, część robi się w piątek po południu, a ścieżka zakupowa potrafi pęknąć także wtedy, gdy nic nie wdrażacie, bo zmieni się coś po stronie bramki płatności albo kuriera. Dlatego to samo przejście warto oddać maszynie.
W Uptimo układasz scenariusz z listy kroków, bez pisania kodu: przejdź, wypełnij, kliknij, poczekaj na element, sprawdź tekst, sprawdź brak tekstu, sprawdź zmianę strony. Prawdziwa przeglądarka przechodzi tę drogę co kilka minut, zawsze tak samo. Krok „sprawdź tekst” jest tu najważniejszy, bo pilnuje, żeby ładna strona błędu z kodem 200 nie została zaliczona jako sukces. Scenariusz zakupowy kończy się zwykle na ekranie bramki płatności, więc zamówienie nie zostaje złożone; do sprawdzania samej płatności używa się trybu testowego operatora albo konta testowego i produktu za 0 zł. Jeśli masz już nagraną ścieżkę z narzędzia Recorder w Chrome albo skrypt z Playwright, wgrywasz plik zamiast przepisywać kroki.
Na czas prac ustawia się okno serwisowe: zaplanowane okno wycisza alerty, więc nikt nie dostaje alarmu o awarii, którą sam wywołał, a wyłączenie tego okresu z wyliczeń dostępności jest osobną, świadomą decyzją. Gdy wdrożenie zmieniło stronę na stałe, krok scenariusza poprawia się w panelu w minutę. Scenariusze są od planu Start; darmowy plan Solo ich nie ma, ale pilnuje dostępności adresu i terminu ważności certyfikatu.
Czego takie sprawdzanie nie zastąpi?
Nie zastąpi testów w procesie wydawniczym. Monitoring odpowiada na pytanie, czy to, co już jest wdrożone, działa dla klienta o tej godzinie. Testy end to end odpowiadają na pytanie, czy zmianę w ogóle wolno wdrożyć, i uruchamiają się przed wydaniem, na środowisku testowym. Jedno nie jest zamiennikiem drugiego i dobrze mieć oba, a jeśli wybierasz, od czego zacząć, zacznij od tego, co pilnuje produkcji, bo tam są prawdziwi klienci.
Scenariusz nie omija zabezpieczeń antybotowych ani weryfikacji dwuetapowej i nie powinien. Do monitoringu zakłada się konto testowe bez logowania dwuetapowego, a jeśli CAPTCHA stoi zawsze, sprawdza się kroki przed nią i osobno kroki po zalogowaniu. Nie sprawdzamy też logiki Twojego panelu sprzedaży: tego, czy zamówienie poprawnie zdjęło produkt ze stanu magazynowego, nie widać z zewnątrz.
I rzecz ostatnia, o której warto wiedzieć zawczasu: scenariusze wykonują się z jednej lokalizacji w Unii Europejskiej, więc nie powiedzą, czy sklep zachowuje się inaczej dla klientów z drugiego końca świata. Materiał po nieudanym przejściu, czyli nagranie, zrzuty z każdego kroku i plik HAR, przechowujemy 14 dni; historia incydentów zostaje dłużej, bo z niej liczy się dostępność.
Przejdź listę raz, potem niech przechodzi się sama
Lista kroków z tego tekstu jest dobra na dzisiejsze wdrożenie. Scenariusz przeglądarkowy jest tą samą listą, tyle że wykonywaną co kilka minut, także w piątek wieczorem i w środku sezonu, z nagraniem i plikiem HAR wtedy, gdy coś pęknie.