Testy integracji: co sprawdzić przed produkcją
W integracjach real-time większość problemów nie wychodzi w “happy path”. Ta lista jest po to, żeby wdrożenie było przewidywalne w szczytach i awariach: timeouty, Busy/Noanswer, błędne DTMF, wolny CRM, błędny JSON.
Minimalny zestaw testów (który warto odhaczyć)
| Test | Wejście | Oczekiwane zachowanie |
|---|---|---|
| Happy path | Connected → Play → Call… | Routing działa, CallStatus=Answer, brak opóźnień, logi kompletne (UniqueCallId + Event + Action). |
| Webhook timeout | Endpoint nie odpowiada / “wisi” | Uruchamia się działanie awaryjne z panelu (kolejka/komunikat), rozmowa nie kończy się ciszą. |
| Webhook błąd / zły JSON | HTTP 500 / niepoprawna odpowiedź | Działanie awaryjne + w logach widzisz błąd powiązany z UniqueCallId (i ewentualnie ErrorNo/ErrorMsg). |
| DTMF timeout | GetDTMF i brak cyfr | Powtórka pytania lub przejście do kolejki po X próbach (licznik w Session), bez “pętli w nieskończoność”. |
| Błędny DTMF | cyfra spoza menu | Krótki komunikat + powtórka / domyślna ścieżka, bez blokowania rozmowy. |
| Busy / Noanswer | Call… bez odbioru | Plan B: backup (drugi obiekt/agent/kolejka) → na końcu kolejka/komunikat. Brak pętli “dial-dial-dial”. |
Jeśli masz czas tylko na 3 testy: timeout webhooka, Noanswer i DTMF timeout. To one najczęściej “psują” obsługę w realnym ruchu.
Testy negatywne (najbardziej “produkcyjne”)
- CRM/DB wolne (np. 2–3 s): czy webhook robi fast-fallback (zamiast czekać do limitu), a rozmowa trafia do kolejki ogólnej.
- Endpoint offline przez kilka minut: czy rozmowy nadal “dochodzą” dzięki działaniu awaryjnemu w panelu.
- CallStatus=Busy/Noanswer: czy masz skończoną liczbę prób i czy plan B jest czytelny.
- DTMF: 2–3 błędy / timeouty: czy rozmowa przechodzi do kolejki, a nie kończy się frustracją.
- Po godzinach / weekend: czy uruchamia się właściwa ścieżka (dyżur tylko dla “pilne”, reszta do komunikatu/kolejki).
Co sprawdzić w logach (żeby debug nie trwał godzinami)
- UniqueCallId – jeden klucz do całej rozmowy.
- EventName + (skrót) EventData – np. Connected, GetDTMF, CallStatus.
- Action.Type + kluczowe parametry (Prompt / Destination / Timeout).
- Session.step (i np. tries) – żeby widzieć “gdzie” jesteś w flow.
- czas odpowiedzi webhooka w ms (median / p95, jeśli mierzysz).
Regresje po zmianach
- każda zmiana routingu = powtórz: happy + timeout + Busy/Noanswer + DTMF timeout,
- zmiana zapowiedzi = sprawdź Play i przejście do kolejnego kroku,
- zmiana Hash/HTTPS = sprawdź, czy nie odrzucasz poprawnych wywołań,
- zmiana działania awaryjnego = zasymuluj offline webhooka i sprawdź efekt “na numerze”.
Pro tip: trzymaj “numer testowy” przypięty do IVR API. To skraca regresje do kilku minut.
Jeśli coś nie działa
Zacznij od logów: UniqueCallId → EventName → Action → czas webhooka. Potem przejdź do listy typowych błędów i gotowych napraw.