Strona działa, a checkout nie. Czym jest monitoring ścieżek użytkownika

Piątek, 16:40

Sklep internetowy wdraża drobną zmianę: widżet z kodem rabatowym w podsumowaniu zamówienia. Strona główna ładuje się szybko, a monitoring dostępności co minutę otrzymuje kod HTTP 200 i świeci na zielono.

Klient dodaje produkty do koszyka, wybiera dostawę i klika „Zamawiam i płacę”. Nic się nie dzieje. Przycisk wygląda normalnie, ale zasłania go przezroczysty element nowego widżetu. Każde kliknięcie trafia w ten element zamiast w przycisk.

Podobny problem może wystąpić, gdy przycisk reaguje, ale nie przenosi do płatności. W konfiguracji został testowy klucz bramki albo nowe ustawienia bezpieczeństwa blokują przekierowanie. Klient widzi chwilę ładowania i zostaje na podsumowaniu.

Przez weekend nikt z zespołu nie próbuje złożyć zamówienia. W poniedziałek o 9:00 ktoś zauważa, że od piątku nie było ani jednego zakupu.

Serwer działał przez cały weekend. Nie działała ścieżka zakupowa. Kod 200 nie oznaczał, że klient może zapłacić. Test, który co pięć minut przechodzi przez koszyk, klika przycisk i sprawdza, czy otworzyła się bramka płatności, mógłby wykryć problem już w piątek o 16:45.

Monitoring dostępności vs Monitoring ścieżek użytkownika

Oba rodzaje monitoringu działają na produkcji i wysyłają alert, gdy coś jest nie tak. Sprawdzają jednak zupełnie co innego.

Nie wybierasz jednego zamiast drugiego. Monitoring dostępności najszybciej powie, że strona leży, ale tylko monitoring ścieżek powie, że klient nie może zapłacić.

Co może się zepsuć, gdy serwer zwraca 200

Każdy z tych przypadków przejdzie przez monitoring dostępności niezauważony:

• Skrypt JavaScript rzuca błąd i przycisk „Dalej” nic nie robi.
• Niewidoczny element leży nad przyciskiem i przechwytuje kliknięcie, np. przezroczysta warstwa widżetu czatu albo tło okna pop-up, którego skrypt nie usunął.
• Przycisk działa, ale nie przenosi do bramki płatności: wygasł klucz API bramki, po wdrożeniu został klucz testowy, nowe nagłówki bezpieczeństwa (Content Security Policy) blokują adres bramki albo zapytanie tworzące płatność kończy się błędem, którego strona nie pokazuje.
• Nie ładuje się usługa z zewnątrz: CAPTCHA, mapa punktów odbioru, kalkulator kosztów dostawy.
• Formularz odrzuca poprawne dane, bo zmieniły się reguły walidacji.
• Wygasł certyfikat SSL na zasobie z innej domeny, np. na serwerze ze skryptami, i przeglądarka go blokuje.
• Po aktualizacji tłumaczeń przycisk ma inny tekst albo znika cena.
• Po zalogowaniu strona w kółko przekierowuje między logowaniem a kontem, więc klient nie dociera do swojego panelu.

Wspólny mianownik: problem widzi tylko ktoś albo coś, co przechodzi ścieżkę w przeglądarce.

Które ścieżki monitorować najpierw i jak często?

Monitoring ścieżek nie musi od razu obejmować całej strony. Najwięcej daje pierwszy scenariusz, nagrany na ścieżce, na której zarabiasz. Żeby ją wybrać, zadaj jedno pytanie: gdyby ta ścieżka nie działała przez 48 godzin, ile byśmy stracili?

Od odpowiedzi zależy też, jak często uruchamiać test w przeglądarce. Im droższa jest godzina awarii, tym szybciej chcesz się o niej dowiedzieć.

Zacznij od jednego scenariusza na najważniejszej ścieżce i uruchamiaj go też zaraz po każdym wdrożeniu nowej wersji strony. Gdy przez tydzień działa bez fałszywych alarmów, dodaj kolejny. Pięć ścieżek nagranych na szybko da więcej fałszywych alarmów niż jedna dobrze ustawiona.

Ten harmonogram dotyczy testów w przeglądarce. Monitoring dostępności strony głównej może działać obok nawet co minutę, bo jest dużo lżejszy.

Trzy sposoby na monitoring ścieżek użytkownika

Każdy z nich sprowadza się do tego samego: ktoś albo coś regularnie przechodzi ścieżkę tak jak klient i daje znać, gdy się nie da. Różnią się tym, kto to robi i ile pracy to kosztuje.

1. Ręcznie

Ktoś co rano lub po każdym wdrożeniu nowej wersji przechodzi checkout, odhaczając kolejne kroki scenariusza w TestRailu. Działa przy jednej ścieżce i w dni robocze. Nie działa w nocy, w weekendy i wtedy, gdy ta osoba jest niedostępna.

2. W kodzie

Programista pisze test w Playwright, Cypress, Selenium albo Puppeteer. Przykład w Playwright:

import { test, expect } from '@playwright/test';

test('checkout dochodzi do płatności', async ({ page }) => {
  await page.goto('https://sklep.example.com/produkt/kubek');
  await page.getByRole('button', { name: 'Dodaj do koszyka' }).click();
  await page.getByRole('link', { name: 'Koszyk' }).click();
  await page.getByRole('button', { name: 'Przejdź do kasy' }).click();
  await expect(page.getByRole('heading', { name: 'Płatność' })).toBeVisible();
});

Jeśli masz programistę, który i tak pisze testy w Playwright, to dobra droga. Do samego testu trzeba jednak doliczyć: uruchamianie według harmonogramu (np. cron w GitHub Actions), wysyłkę alertów, przechowywanie zrzutów ekranu i poprawianie selektorów po każdej zmianie strony.

3. W chmurze

Zamiast własnego kodu i serwera korzystasz z gotowej platformy w chmurze. Nagrywasz albo opisujesz ścieżkę raz, a platforma sama uruchamia ją w prawdziwej przeglądarce według harmonogramu, z wybranej lokalizacji. Harmonogram, alerty, zrzuty ekranu i historia uruchomień są w jednym miejscu, więc nie musisz ich budować ani utrzymywać.

Część narzędzi wymaga pisania testów w kodzie, inne pozwalają nagrać scenariusz, klikając, bez programowania. To drugie podejście sprawdza się, gdy ścieżek ma pilnować ktoś spoza zespołu developerskiego, np. właściciel sklepu albo marketing.

Jak to wygląda w TestCLIX

1. Nagrywasz ścieżkę w przeglądarce, która działa w chmurze i jest wyświetlana na Twoim ekranie. Nie instalujesz wtyczek, nie piszesz kodu. Klikasz tak, jak klient.
2. Dodajesz sprawdzenia. Wskazujesz, co musi być widoczne na danym kroku, np. nagłówek „Płatność”. Jeśli tego nie ma, test zgłasza błąd.
3. Ustawiasz harmonogram. Decydujesz, jak często test ma się uruchamiać: najczęściej co 5 minut, najrzadziej raz dziennie.
4. Wybierasz lokalizację. Test łączy się z Twoją stroną z serwera w Europie albo w USA.
5. Ustawiasz próg alarmu. Na przykład: alarm, gdy 2 z ostatnich 3 uruchomień się nie powiodą. Jeden przypadkowy błąd sieci nie budzi wtedy nikogo w nocy.
6. Wybierasz, gdzie ma przyjść alert: e-mail, Slack, Telegram, Jira albo webhook.

Gdy test się nie powiedzie, odtwarzacz sesji pokazuje krok po kroku, co zobaczyła przeglądarka, obok nagranego wzorca. Widzisz ten sam ekran, który zobaczyłby klient.

Pułapki na start

• Nie składaj prawdziwych zamówień. Kończ test na stronie płatności, przed ostatnim kliknięciem.
• Treści, które się zmieniają. Ceny, daty i rekomendacje zmieniają się same. Wyłącz je z porównania ekranu (strefy ignorowane) albo sprawdzaj je asystentem AI zamiast dokładnego tekstu.
• Hasła i 2FA. Hasła trzymaj w sekretach projektu, nie w treści testu. Kody jednorazowe (TOTP) TestCLIX potrafi generować w czasie testu.
• Zbyt czułe alarmy. Alarm po jednym nieudanym uruchomieniu szybko uczy zespół ignorowania alertów.

Kiedy to nie wystarczy

• Monitoring ścieżek nie zastąpi testów przed wdrożeniem. Łapie problem na produkcji, gdy już wystąpił, tyle że w ciągu minut, a nie dni.
• Sprawdza wybrane ścieżki, nie każdy wariant. Jeśli masz pięć metod płatności, test zwykle przejdzie jedną.
• Nie powie, ilu klientów trafiło na błąd. Do tego służą narzędzia do śledzenia błędów (np. Sentry) i analityka.
• W TestCLIX jeden test działa z jednej lokalizacji. Kilka regionów to kopia testu z inną lokalizacją. Testujemy strony internetowe, nie aplikacje natywne.