Ciche błędy w ścieżce zakupu
Sklep się ładuje, produkty są dostępne, a banery promocyjne są widoczne. Problem wychodzi dopiero przy zakupie. Na telefonie okno z kodem rabatowym zasłania przycisk „Przejdź do kasy”. Klient wpisuje kod BF30 z banera, ale sklep go odrzuca, bo w panelu rabat ustawiono od soboty zamiast od piątku. Albo mapa punktów odbioru w ogóle się nie ładuje.
Nie możesz liczyć na to, że klient zgłosi taki błąd. Może po prostu zrezygnować. Łatwo też przeoczyć problem, jeśli sprawdzasz sklep tylko na komputerze i bez kodu rabatowego. Gdy kampania przyciąga więcej klientów, opóźnienie w wykryciu błędu może oznaczać więcej utraconych zamówień.
Przed promocją dochodzą nowe banery, reguły cenowe, skrypty reklamowe i aktualizacje wtyczek. Część tych zmian może wpłynąć na zakup. Dlatego warto przejść ścieżkę po wdrożeniu, a potem sprawdzać ją regularnie testem w przeglądarce. Test może co kilka minut powtarzać wybrane kroki i wysłać alert, gdy któryś z nich przestanie działać.
Lista kontrolna
Jeśli zostało Ci niewiele czasu, najpierw sprawdź, czy klient może przejść do płatności i skorzystać z kodu rabatowego oraz czy powiadomienie o błędzie trafia do osoby, która może zareagować. Poniższe terminy dostosuj do daty rozpoczęcia swojej promocji.
Teraz (2 do 3 tygodni przed)
- Wybierz najważniejszą ścieżkę: produkt, koszyk, dostawa i przejście do płatności. Uwzględnij zakup bez konta, jeśli jest dostępny, a następnie logowanie i kod rabatowy.
- Nagraj testy i uruchom je kilka razy przed zmianami promocyjnymi. Ustal, na którym kroku mają się kończyć i czy nie tworzą nieopłaconych zamówień ani nie rezerwują towaru.
- Zaplanuj zamrożenie zmian po wdrożeniu i sprawdzeniu promocji. Od tego momentu wdrażaj tylko niezbędne poprawki.
- Sprawdź datę wygaśnięcia certyfikatu SSL sklepu. Uwzględnij też krytyczne domeny zewnętrzne, np. ze skryptami płatności lub mapą punktów odbioru.
- Ustal, kto reaguje na alerty w weekend promocji, kto tę osobę zastępuje i jak się z nimi skontaktować. Wybierz kanał z powiadomieniami na telefonie, np. Slack lub Telegram.
Tydzień przed (do 20 listopada)
- Wdróż banery i stronę promocji, a kody przygotuj z właściwą datą aktywacji. Po każdej zmianie uruchom nagrane testy. Po zaakceptowaniu zmian wyglądu zaktualizuj wzorce porównania ekranu.
- Sprawdź daty i godziny ważności kodów, strefę czasową sklepu, limity użyć, minimalną wartość koszyka i wykluczone produkty.
- Przed startem promocji sprawdź w środowisku testowym, czy kod nalicza dokładnie obiecany rabat. Przygotuj test, który sprawdza, czy kod jest przyjmowany i rabat pojawia się w podsumowaniu. Włącz go po aktywacji kodu. Samo obniżenie kwoty zamówienia nie oznacza, że rabat został poprawnie obliczony.
- Sprawdź sklep także na mobilnej wielkości ekranu i przygotuj do tego osobny test. Przejdź też zakup na prawdziwym telefonie, szczególnie wybór dostawy i przejście do płatności.
- Zmierz wydajność strony promocji po dodaniu banerów i skryptów. Duże grafiki mogą opóźnić wyświetlenie największego elementu treści (LCP).
- Sprawdź, czy strona promocji pokazuje właściwą ofertę, a przycisk prowadzi do odpowiedniego produktu lub kategorii. Jeśli używasz odliczania, sprawdź jego termin i zachowanie strony po zakończeniu promocji.
Dzień przed (26 listopada)
- Ustaw częstotliwość odpowiednią do ruchu: np. ścieżka zakupu co 5 minut, dostępność najważniejszych stron co minutę. Jeśli duża część klientów kupuje na telefonie, test mobilnego układu uruchamiaj równie często.
- Dobierz próg alarmu. Przykładowo 2 nieudane uruchomienia z 3 ograniczają pojedyncze fałszywe alarmy, ale opóźniają powiadomienie. Przy testach co 5 minut wykrycie trwałej awarii zajmie około 5–10 minut, plus czas wykonania testu i wysłania alertu.
- Sprawdź, czy alert dociera do właściwej osoby. Użyj kopii testu z celowo błędnym sprawdzeniem i progiem 1 z 1, zachowując te same kanały powiadomień. Po próbie usuń kopię.
- Przejdź zakup ręcznie jeszcze raz i sprawdź, czy zaplanowane ceny oraz kody mają właściwy moment aktywacji.
W trakcie (27 do 30 listopada)
- Wdrażaj tylko niezbędne poprawki. Po każdej uruchom nagrane testy.
- Gdy przyjdzie alert, odtwórz sesję testu i zobacz, na którym kroku się zatrzymał. To pomoże zawęzić problem przed sprawdzeniem logów.
- Uruchom nagrane testy zaraz po starcie promocji i po każdej zaplanowanej zmianie cen, np. na Cyber Monday. Sprawdź też rzeczywistą wysokość rabatu.
Po promocji
- Zdejmij banery i wyłącz kody. Sprawdź, czy ceny wróciły do normalnych.
- Wyłącz lub zmień testy kodów promocyjnych i zaktualizuj wzorce wyglądu. Zaplanowane zakończenie promocji nie powinno wywoływać alarmów.
- Zmniejsz częstotliwość testów do zwykłego poziomu.
- Zapisz, co się zepsuło i jak to zauważyliście. Za rok ta notatka będzie warta więcej niż ta lista.
Jak to ustawić w TestCLIX
Przykładowy zestaw testów na czas promocji. Częstotliwość dopasuj do ruchu i tego, jak długo możesz czekać na wykrycie problemu:
| Co sprawdzamy | Typ testu | Jak często | Sprawdzenie |
|---|---|---|---|
| Produkt, koszyk, dostawa, strona płatności | Scenariusz | Co 5 minut | Po wyborze dostawy otwiera się właściwa strona płatności |
| Ta sama ścieżka przy szerokości telefonu | Scenariusz | Co 5 minut | Można użyć przycisków i przejść do strony płatności |
| Kod rabatowy | Scenariusz | Co 15 minut | Kod jest przyjmowany, a rabat widoczny w podsumowaniu |
| Logowanie | Scenariusz | Co 15 minut | Element dostępny dopiero po logowaniu, np. przycisk wylogowania |
| Strona główna, kategoria promocji, koszyk | Dostępność | Co minutę | Kod 200, czas odpowiedzi, certyfikat SSL |
| Strona promocji | Vitals | Raz dziennie | LCP, CLS, wynik Lighthouse |
Przy sprawdzeniach AI uwzględnij, co widać w zaznaczonym fragmencie ekranu. Porównanie ceny przed rabatem i po nim wymaga dostępu do obu kwot; nie zakładaj, że asystent zna wartość z poprzedniego kroku. Ocenę AI traktuj jako pomocniczą, a poprawność obliczeń sprawdź osobno.
Pułapki przed promocją
- Otwarcie bramki nie potwierdza płatności. Zatrzymaj test produkcyjny przed pobraniem pieniędzy. Sprawdź, czy samo otwarcie bramki nie tworzy nieopłaconego zamówienia lub rezerwacji towaru; jeśli tak, uwzględnij ich usuwanie lub wygasanie. Pełną płatność i potwierdzenie zamówienia sprawdź osobno, w trybie testowym bramki na środowisku testowym.
- Produkt do monitoringu. Wybierz produkt z odpowiednim zapasem i ustal, kiedy zmienić go w scenariuszu. Brak towaru może przerwać test mimo sprawnego sklepu i wywołać fałszywy alarm techniczny.
- Zmienne ceny. Jeśli nie sprawdzasz konkretnej kwoty, wyłącz zmienne ceny z porównania ekranu za pomocą stref ignorowanych. Oczekiwaną cenę sprawdzaj osobno po starcie promocji i każdej zmianie oferty. Ukrycie ceny przed porównaniem nie potwierdza, że jest poprawna.
- Konto testowe. Użyj osobnego konta z minimalnymi uprawnieniami. Nie wpisuj hasła w nazwach ani opisach testów i sprawdź, czy nie jest widoczne na zrzutach ekranu.
Czego ta lista nie obejmuje
- Wydajności pod obciążeniem. Monitoring przechodzi ścieżkę jako jeden klient co kilka minut. Nie powie, co się stanie przy 10 tysiącach klientów naraz. Do tego służą testy obciążeniowe, np. k6, JMeter albo Gatling, zrobione przed promocją.
- Pełnego działania płatności i usług dostawców. Test zatrzymany na otwarciu bramki może wykryć problem z dojściem do niej, ale nie potwierdzi autoryzacji płatności ani aktualizacji statusu zamówienia. Ustal też plan na awarię dostawcy, np. alternatywną metodę płatności, i sprawdź ją przed promocją.
- Problemów z magazynem i dostawą. Ścieżka może działać idealnie, a zamówienia i tak nie wyjdą na czas.