Lista kontrolna QA po uruchomieniu

Przeprowadź kompletny zakup samodzielnie na żywej stronie — nie w środowisku testowym — obejmując ścieżki, z których faktycznie korzystają klienci: zakup jako gość i zakup zalogowanego użytkownika, przynajmniej jeden produkt z wariantami oraz wszelkie aktualnie aktywne kody rabatowe czy promocje. Sprawdź, czy e-maile z potwierdzeniem zamówienia wysyłają się poprawnie i czy zamówienie następnie prawidłowo pojawia się w Twoim panelu administracyjnym/systemie zamówień.

Nie zakładaj, że pokrycie testowe przenosi się automatycznie. Żywe bramki płatności, żywe usługi podatkowe i żywe API stawek wysyłki czasem zachowują się inaczej niż ich odpowiedniki testowe czy sandboksowe, dlatego właśnie potrzeba tu prawdziwej weryfikacji w realnych warunkach, a nie polegania na tym, co przeszło w środowisku testowym.

Zweryfikuj, że przetwarzanie płatności działa w trybie live (nie testowym/sandboksowym), że wszystkie metody płatności wcześniej obsługiwane przez sklep są włączone i działają, oraz że prawdziwa transakcja rozlicza się poprawnie od początku do końca — środki faktycznie docierają, nie tylko zmienia się status zamówienia. Sprawdź też funkcję zwrotów, ponieważ jest używana rzadziej niż kasa i łatwo pozostawić ją niezweryfikowaną.

Jeśli obsługujesz wiele metod płatności lub walut, przetestuj każdą osobno, zamiast zakładać, że skoro jedna metoda działa, pozostałe są skonfigurowane tak samo.

Logika podatków i wysyłki łatwo ulega subtelnym błędom podczas migracji, ponieważ obie często zależą od konfiguracji, która nie mapuje się czysto między platformami. Złóż testowe zamówienia do Twoich najczęstszych miejsc docelowych wysyłki i potwierdź, że podatek jest naliczany poprawnie, a stawki wysyłki i dostępne metody odpowiadają temu, co zamierzałeś — a nie tylko temu, co nowa platforma ustawiła domyślnie.

Zwróć szczególną uwagę na wszelkie szczególne przypadki, na których polega Twoja firma: zwolnienia podatkowe, progi darmowej wysyłki, zasady specyficzne dla regionu czy ograniczenia wysyłki dla niektórych produktów. To właśnie te szczegóły konfiguracji najczęściej giną albo ustawiają się domyślnie błędnie podczas migracji.

Nawet mając kompletną mapę przekierowań zbudowaną przed uruchomieniem, sprawdź wyrywkowo realną próbkę adresów URL po przełączeniu: strony o najwyższym ruchu, kilka o niższym ruchu oraz kilka celowych wyjątków (wycofane produkty, scalone kategorie). Potwierdź, że każdy przekierowuje na właściwy cel jednym skokiem, bez łańcuchów czy pętli.

Sprawdź też próbkę adresów URL, które nie powinny istnieć na starej stronie — literówki, stare adresy URL oparte na parametrach, cokolwiek, co robot indeksujący mógł przypadkowo zaindeksować — aby upewnić się, że rozwiązują się sensownie, zamiast zwracać błąd w sposób, który wygląda na szerszy problem.

Zweryfikuj, że Twoja platforma analityczna, śledzenie konwersji oraz wszelkie piksele reklamowe działają poprawnie na nowej stronie — złożone testowe zamówienie powinno pojawić się w raportowaniu Twojej analityki i platform reklamowych tak samo jak wcześniej. Kod śledzący łatwo zgubić po cichu podczas zmiany platformy, ponieważ brakujący lub źle skonfigurowany piksel nie generuje komunikatu błędu — po prostu przestaje raportować dane.

Porównuj wczesne dane analityczne po uruchomieniu z Twoim wynikiem sprzed migracji dla tego samego typu dnia (dzień roboczy w porównaniu do weekendu, podobne źródła ruchu), a nie surowe porównanie przed/po, ponieważ normalna zmienność ruchu może inaczej maskować lub imitować rzeczywisty problem ze śledzeniem.

Poproś kilka prawdziwych (lub testowych) kont klientów o potwierdzenie, że mogą się zalogować, widzą poprawną historię zamówień i mają dostęp do funkcji konta, na których wcześniej polegali — zapisane adresy, zapisane metody płatności tam, gdzie dotyczy, salda punktów lojalnościowych, jeśli sklep je ma. Problemy z dostępem do konta są wysoce widoczne dla klientów, którzy ich doświadczają, i bezpośrednio wpływają na zaufanie, więc warto je zweryfikować celowo, a nie zakładać, że migracja konta „prawdopodobnie zadziałała”.

Jeśli migracja haseł nie była częścią technicznego przeniesienia (co zdarza się, gdy platformy używają niekompatybilnego hashowania haseł), upewnij się, że klienci mają jasną ścieżkę resetu hasła i że jest ona zakomunikowana, a nie tylko technicznie dostępna.

Obserwuj Search Console (lub odpowiednik dla innych wyszukiwarek) długo po dniu uruchomienia — błędy indeksowania, status indeksacji oraz wszelkie skoki zgłaszanych błędów 404 to najwcześniejsze sygnały problemu z przekierowaniem lub tagiem kanonicznym, który umknął testom. Porównuj z wynikiem sprzed migracji, aby odróżnić prawdziwą regresję od normalnej krótkoterminowej fluktuacji po zmianie strony.

Ten okres monitorowania to też dobry moment, by ponownie przesłać mapę strony, jeśli jeszcze tego nie zrobiłeś, i potwierdzić, że strony, które mają być zaindeksowane, faktycznie pojawiają się w wynikach wyszukiwania w kolejnych tygodniach, a nie tylko są odwiedzane przez roboty.