Odpowiedź.

Ręczne testowanie integracyjne to ważny etap cyklu życia oprogramowania, który przeprowadza się po testach jednostkowych. Jego celem jest upewnienie się, że poszczególne moduły lub komponenty systemu prawidłowo ze sobą współdziałają.

Historia pytania: Początkowo testowanie oprogramowania odbywało się etapami: najpierw sprawdzano pojedyncze moduły (testy jednostkowe), następnie cały system w całości. Jednak w praktyce okazało się, że większość krytycznych błędów występuje właśnie na styku między modułami. Pojawiła się potrzeba testowania integracyjnego, które ręcznie ujawnia rozbieżności w zachowaniu różnych części systemu.

Problem: Główną trudnością jest niewystarczające opracowanie scenariuszy współdziałania między modułami oraz zapomniane wzajemne zależności. Prowadzi to do "niewidocznych" błędów: podczas izolowanego testowania wszystko działa poprawnie, ale po integracji występują awarie (na przykład nieprawidłowe przetwarzanie danych między API a DB).

Rozwiązanie: Prawidłowa organizacja ręcznego testowania integracyjnego obejmuje:

Analizę architektury systemu i budowę mapy interakcji komponentów.
Opracowanie testów integracyjnych na podstawie scenariuszy użytkowników i danych granicznych.
Modelowanie częściowych awarii (na przykład awaria jednej z usług) i ocena reakcji całego systemu.
Dokumentowanie wyników i rejestrowanie zależności między błędami.

Kluczowe cechy:

Utrzymywanie aktualnej architektonicznej schemy.
Uwzględnienie wszystkich ukrytych i jawnych zależności między częściami systemu.
Szczególna uwaga na scenariusze przekazywania i przekształcania danych na stykach modułów.

Pytania z podchwytliwością.

Jaka jest różnica między ręcznym testowaniem integracyjnym a systemowym?

Testowanie integracyjne koncentruje się na testowaniu połączeń między konkretnymi modułami, podczas gdy testowanie systemowe sprawdza cały system w całości z punktu widzenia jego funkcjonalności biznesowej.

Czy podczas testowania integracyjnego należy używać rzeczywistych zewnętrznych usług, czy wystarczą emulatory?

Dla krytycznych integracji rzeczywiste środowisko jest preferowane, ale można zacząć od emulatorów (mock/stub). Finalne testowanie powinno odbywać się w maksymalnie zbliżonym do PROD środowisku.

Czy wszystkie błędy integracyjne można wykryć tylko poprzez automatyzację?

Nie: część defektów wykrywa się tylko ręcznie, gdy tester zauważa nieoczywiste problemy w logice biznesowej wymiany danych lub w scenariuszach użytkowników, które nie są pokryte automatyzacją.

Typowe błędy i antywzorce

Brak wyraźnej listy punktów integracyjnych.
Przeprowadzanie testów bez izolacji środowiska.
Niewystarczająca szczegółowość testów integracyjnych.

Przykład z życia

Negatywny przypadek

Testowanie integracji między modułem płatności a modułem zamówień przeprowadzono tylko po zakończeniu wszystkich innych testów i bez oddzielnej dokumentacji.

Zalety:

Oszczędność czasu przy przygotowaniu test cases.
Szybkie uruchomienie testów bez skomplikowanej koordynacji.

Wady:

Wycieki poważnych błędów na produkcję, związane z podwójnym obciążeniem środków.
Opóźnienia w wydaniu w celu naprawienia problemów znalezionych w ostatniej chwili.

Pozytywny przypadek

Scenariusze integracyjne zostały zapisane na początku, a dane testowe maksymalnie zbliżono do rzeczywistych zadań użytkowników.