Pułapka fałszywego zaufania: Case study z życia
W jednym z zespołów ludzie codziennie rano dostawali mailowe raporty z Jenkinsa. Przez dłuższy czas wyglądało to uspokajająco: większość jobów była na zielono, a w skrzynkach pojawiało się znajome „SUCCESS”. Zespół zaczął ufać tym raportom jak porannemu budzikowi:
„Skoro Jenkins mówi, że jest green, to możemy wdrażać”.
I właśnie wtedy weszła zmiana pozornie niewinna: nowy adres usługi na środowisku testowym i drobna modyfikacja w API jednego z mikroserwisów. Nocna regresja dalej „przechodziła”, ale tylko dlatego, że uruchamiała się na starej konfiguracji, a testy integracyjne odpalały się w miejscu, które w praktyce nie blokowało wdrożenia.
Efekt był klasyczny: raporty z Jenkinsa wyglądały dobrze, a na produkcji pokazywały się błędy.
O czym mówi Rozdział 5 sylabusa ISTQB CTAL-TAE?
Ten obszar bierze na warsztat
strategie implementacji i wdrożenia automatyzacji. Kluczowe zagadnienia to:
- Jak umieścić testy w CI/CD, aby wynik pipeline’u miał realną wartość.
- Jak utrzymać porządek w konfiguracjach testów automatycznych.
- Jak podejść do zależności w automatyzacji API (z naciskiem na testy kontraktowe).
1. Gdzie postawić bramkę? (TAE-5.1.1)
Pierwsza część rozdziału sprowadza temat do prostego pytania:
w którym miejscu CI/CD test ma dać sygnał „stop”, a w którym ma tylko dać informację?
- Poziom Build: Tu warto odpalić testy szybko łapiące błędy konfiguracji i narzędzi.
- Poziom CI: Testy komponentowe i integracja komponentów jako twarda bramka.
- Poziom CD: Testy systemowe i integracyjne (bramki po stronie Continuous Deployment).
Dwa warianty dla testów systemowych:
- Część deploymentu: Mogą realnie zablokować wdrożenie i uruchomić rollback.
- Osobny pipeline: Uruchamiane po wdrożeniu – wygodne organizacyjnie, ale ze słabszą kontrolą jakości.
Wskazówka: Przydatną techniką są też
uruchomienia cykliczne (np. nocne regresje). Dają codzienny sygnał o jakości i pozwalają wychwycić problemy niewidoczne na „krótkiej ścieżce” CI, wspierając monitorowanie cech niefunkcjonalnych (np. wydajności).
- Zarządzanie konfiguracją (TAE-5.1.2)
Temat, który staje się krytyczny przy wielu środowiskach, wersjach SUT i wariantach danych. Rozdział porządkuje trzy obszary:
- Konfiguracja środowiska: Adresy usług, poświadczenia, przełączniki zależne od platformy.
- Dane testowe: Muszą być świadomie zarządzane (gdzie je trzymać i jak odtwarzać per wydanie).
- Zestawy testów: Mechanizm sterowania tym, co uruchamiamy (tagi, profile, powiązanie wersji skryptów z wersją SUT), aby nie testować „innej rzeczywistości” niż ta wdrażana.
3. Automatyzacja API i testy kontraktowe (TAE-5.1.3)
Sensowna strategia wymaga zrozumienia relacji między usługami i solidnej dokumentacji (parametry, nagłówki, schematy request/response). Kluczowym pojęciem jest
Contract Testing:
- Cel: Weryfikacja, czy usługi komunikują się zgodnie z regułami i czy struktura danych jest poprawna.
- Podejścia: Consumer-driven (oczekiwania definiuje konsument) oraz Provider-driven (kontrakt tworzy dostawca).
- Zaleta: W mikroserwisach działa to jak bezpiecznik – zmiana w jednej usłudze nie „przepala” innych po cichu.
Dlaczego warto znać ten rozdział?
Tester zyskuje umiejętność umieszczania testów na właściwych etapach pipeline’u, tak aby wynik był wiarygodny. Organizacja natomiast zyskuje szybszy feedback, stabilniejsze bramki jakości i mniejsze ryzyko „zielonego pipeline’u, który nic nie gwarantuje”.
Najważniejsze korzyści (krótko, na koniec):
- Dla testera: świadome wpinanie testów w CI/CD na różnych poziomach oraz praktyczna kontrola konfiguracji, danych i zestawów testów, aby wyniki były porównywalne i powtarzalne.
- Dla organizacji: mocniejsze bramki jakości tam, gdzie naprawdę są potrzebne, lepsza przewidywalność wdrożeń i mniej kosztownych niespodzianek po release.
- Dla systemów opartych o API: wcześniejsze wykrywanie niezgodności między usługami i szybsze namierzanie źródła defektu dzięki testom kontraktowym.
