Odpowiedź.

Ręczne testowanie integracji to proces sprawdzania interakcji między różnymi modułami, usługami lub zewnętrznymi systemami ręcznie, bez automatycznych skryptów.

Historia pytania:

Na początku rozwoju produktów IT wszystkie systemy były tworzone monolitycznie, ale wraz ze wzrostem skali firmy i liczby zewnętrznych usług zaczęły być istotne testy integracyjne. Testerzy zaczęli zastanawiać się, jak upewnić się, że dane i działania poprawnie przechodzą między systemami — na przykład, że udana płatność jest odzwierciedlana zarówno w systemie billingowym, jak i w systemie księgowym.

Problem:

Największą trudnością jest brak w pełni funkcjonalnego środowiska: integracje mogą zależeć od zewnętrznych usług, niestabilnych API lub ograniczeń zewnętrznych. Ponadto ręczne testowanie w każdym punkcie integracji może być bardzo czasochłonne, łatwo popełnić błąd w kolejności kroków lub przeoczyć ważne skutki kaskadowe.

Rozwiązanie:

Używaj środowisk testowych z „mockami” (mock/stub), aby zapewnić powtarzalność testu.
Strukturuj przypadki testowe, zapisuj krok po kroku weryfikację komunikatów, logów, statusów.
W pierwszej kolejności testuj przypadki brzegowe, timeouty, ponowne próby wywołania integracji, reakcję systemu na awarie.

Kluczowe cechy:

Konieczność zrozumienia logiki biznesowej obu integrujących się stron.
Uwzględnienie asynchroniczności i błędów przesyłania stanu.
Wsparcie dla odporności na częściowe awarie.

Pytania z podwójnym dnem.

Co to są „testowe duble” (test doubles) i po co są potrzebne w ręcznym testowaniu integracji?

Testowe duble to imitacje komponentów integracyjnych (np. mock, stub, fake). Przy ręcznym testowaniu są potrzebne, aby opracować scenariusze, gdy prawdziwy zewnętrzny system jest niedostępny lub jego wywołania są kosztowne.

Czy można uznać integrację za przetestowaną, jeśli przypadki testowe pokryły tylko „happy path”?

Nie. Należy koniecznie testować przypadki brzegowe: błędy połączenia, niewłaściwe formaty danych, timeouts, nieoczekiwane odpowiedzi.

Czy wystarczy sprawdzić tylko wysyłanie/odbieranie danych, czy trzeba jeszcze coś innego?

Ważne jest, aby sprawdzić poprawność ZAWARTOŚCI danych, ich transformację oraz zachowanie systemu w przypadku różnych błędów na styku.

Typowe błędy i antywzorce

Pracować tylko z „własną” częścią systemu, nie sprawdzając zachowania po stronie partnera.
Ignorować negatywne scenariusze.
Nie analizować logów ani nie gromadzić historii błędów integracyjnych.

Przykład z życia

Negatywny przypadek

Tester sprawdza integrację między CRM a systemem billingowym tylko pod kątem udanego dodania zamówienia. Nie sprawdza błędu synchronizacji i pominięcia transakcji.

Zalety:

Szybkie pokrycie podstawowych scenariuszy.

Wady:

Błąd przy awarii integracji zostanie wykryty dopiero na realnych danych.

Pozytywny przypadek

Tester tworzy zestaw testów z wyłączonym i włączonym połączeniem internetowym, z podstawionymi nieważnymi tokenami. Waliduje logi obu stron.