Uruchomienie niesprawdzonej integracji może skończyć się błędnymi cenami, utraconymi zamówieniami, nieprzesłanymi fakturami albo rozbieżnymi stanami magazynowymi. Dlatego testowanie powinno obejmować nie tylko sprawdzenie, czy systemy komunikują się przez API, ale też pełny przebieg procesu sprzedaży. Takie prace wykonuj na środowisku stagingowym, nigdy na produkcji.
Dlaczego potrzebujesz środowiska testowego?
Środowisko stagingowe jest kopią sklepu przygotowaną do bezpiecznej weryfikacji konfiguracji i przepływu danych. Możesz na nim tworzyć testowe zamówienia, przerywać płatności, symulować brak odpowiedzi API, zmieniać statusy i czyścić bazę bez wpływu na rzeczywistych klientów.
Produkcja służy do obsługi prawdziwej sprzedaży. Test na tym środowisku może utworzyć dokument księgowy, pobrać płatność, zmniejszyć stan magazynowy albo wysłać wiadomość do klienta. Sama automatyzacja nie chroni przed skutkami błędnej konfiguracji.
| Cecha | Środowisko testowe (Staging) | Środowisko produkcyjne |
|---|---|---|
| Dane klientów | Testowe lub zanonimizowane, zgodnie z przyjętą procedurą | Rzeczywiste dane klientów i zamówień |
| Transakcje | Można je bezpiecznie symulować i anulować | Mogą powodować rzeczywiste obciążenia i zobowiązania |
| Możliwość czyszczenia bazy | Można usuwać rekordy po zakończeniu prób | Usunięcie danych może zakłócić sprzedaż i rozliczenia |
| Wpływ na sprzedaż | Brak bezpośredniego wpływu na klientów | Każdy błąd może zatrzymać lub zniekształcić obsługę zamówień |
Staging powinien możliwie wiernie odzwierciedlać produkcję. Sprawdź na nim wersję platformy, motyw, moduły, konfigurację płatności, dostaw, ERP i API. Dane dostępowe do środowiska testowego muszą być oddzielone od danych produkcyjnych.
Jak testować integrację krok po kroku?
Procedurę zacznij od spisania systemów, kierunków wymiany danych i oczekiwanych rezultatów. Przykładowo sklep może wysyłać zamówienia do ERP, ERP może przekazywać ceny i stany, a operator płatności może aktualizować status transakcji. Każdy z tych przepływów powinien mieć własne scenariusze odbioru.
- Przeanalizuj mapowanie pól – sprawdź, z którego systemu pochodzi identyfikator produktu, cena, stawka VAT, stan magazynowy, status zamówienia i dane klienta. Ustal, czy cena brutto jest przekazywana jako brutto, a netto jako netto. Zweryfikuj formaty dat, walut, numerów telefonów i adresów.
- Wykonaj test pozytywny – utwórz poprawny produkt lub zamówienie i obserwuj cały przepływ. Sprawdź, czy rekord pojawia się w systemie docelowym tylko raz, zawiera właściwe pozycje, ilości, ceny, rabaty, dostawę i płatność. Następnie prześledź zmianę statusu aż do realizacji.
- Przeprowadź testy negatywne – odrzuć płatność, przerwij proces płatności, ustaw brak towaru, wyślij niepoprawny identyfikator albo odłącz API. Sprawdź, czy system pokazuje błąd, zapisuje go w logach, ponawia próbę i nie tworzy drugiego zamówienia lub dokumentu.
- Sprawdź synchronizację statusów – zweryfikuj, co dzieje się po opłaceniu, anulowaniu, zwrocie i zmianie statusu wysyłki. Ustal, który system jest źródłem statusu i czy cofnięcie operacji w jednym miejscu aktualizuje drugi system.
- Przetestuj większy wolumen danych – wykonaj import wielu produktów, wariantów, stanów lub zamówień. Zmierz czas synchronizacji, sprawdź limity API i zobacz, czy zadanie wznawia się po przerwaniu. Przy dużej bazie jednorazowy test pojedynczego produktu nie pokazuje rzeczywistego ryzyka.
Test techniczny odpowiada na pytanie, czy API przyjęło żądanie i zwróciło odpowiedź. Test procesowy sprawdza, czy po tej odpowiedzi prawidłowo działa sprzedaż, magazyn, płatność, dokumentowanie i komunikacja z klientem. Dopiero oba wyniki razem dają podstawę do uruchomienia integracji.
Co sprawdzić w pierwszej kolejności?
Najwięcej rozbieżności pojawia się na styku danych handlowych i statusów. Przed odbiorem sprawdź następujące obszary:
- Ceny – zgodność wartości brutto i netto, stawek VAT, walut, poziomów cenowych oraz rabatów.
- Statusy zamówień – reakcję na opłacenie, odrzucenie płatności, anulowanie, zwrot i przekazanie do wysyłki.
- Stany magazynowe – kierunek synchronizacji, częstotliwość aktualizacji i zachowanie przy braku towaru.
- Dane klienta – kompletność imienia, adresu, telefonu, e-maila i danych do faktury, bez używania niepotrzebnych danych rzeczywistych.
- Dostawy i płatności – powiązanie metod sklepu z odpowiednikami w systemie ERP oraz zgodność kwoty, waluty i statusu transakcji.
- Rabaty i promocje – sposób zapisu ceny po rabacie, zwłaszcza gdy system zewnętrzny nie przekazuje rabatu jako osobnego pola.
Przykładowo integracja enova365 z Shoper przez e-Sklepy Konektor może wymagać osobnego sprawdzenia cen brutto, mapowania dostaw i płatności, statusów po wystawieniu faktury oraz parowania towarów po kodzie EAN. Zakres działania zależy od konfiguracji, wersji sklepu i dodatku, dlatego nie należy zakładać, że każdy przepływ działa tak samo w każdej instalacji.
Na co uważać podczas testów?
Nie testuj integracji na środowisku produkcyjnym. Rzeczywiste zamówienie, płatność lub zmiana stanu magazynowego może wywołać skutki, których nie da się łatwo cofnąć.
Nie używaj też żywych danych klientów tylko dlatego, że są wygodne do testu. Stosuj dane testowe albo przygotowany, zanonimizowany zestaw. Oddziel klucze API, konta płatnicze i adresy webhooków dla stagingu i produkcji.
Typowe problemy wynikają z pominięcia kontroli po błędzie. Sama informacja, że zadanie synchronizacji zakończyło się niepowodzeniem, nie wystarcza. Trzeba ustalić, kto otrzymuje alert, gdzie sprawdzić logi, kiedy system ponawia próbę i jak ręcznie wznowić proces. Automatyzacja bez nadzoru może powtarzać błędną operację albo pozostawić zamówienie w nieokreślonym statusie.
Czy sklep jest gotowy do startu?
Przed przełączeniem integracji na produkcję potwierdź każdy punkt z zespołem technicznym i osobami obsługującymi zamówienia:
- Przetestowano poprawne zamówienie od koszyka do realizacji.
- Sprawdzono anulowanie zamówienia, zwrot i zmianę statusu płatności.
- Zweryfikowano reakcję na brak towaru i rozbieżność ceny.
- Sprawdzono zachowanie po braku połączenia z API oraz po ponowieniu synchronizacji.
- Potwierdzono zgodność cen, stanów, dostaw, płatności i danych klienta.
- Zespół wie, gdzie znaleźć logi i jak reagować na błąd po uruchomieniu.
Do produkcji przenieś dopiero zaakceptowaną konfigurację i właściwe dane dostępowe. Ustal też moment przełączenia, osobę odpowiedzialną za monitoring oraz sposób kontroli pierwszych zamówień. Pełne testy wymagają czasu, ale koszt znalezienia błędu na stagingu jest zwykle znacznie niższy niż koszt jego skutków po otwarciu sprzedaży.
