Architektura, czyli jak nie utonąć w morzu skryptów. Odczarowujemy sylabus ISTQB TAE (cz. 3)
Jest taki moment w wielu firmach, kiedy automatyzacja przestaje być „fajnym dodatkiem”, a zaczyna być… ciężkim plecakiem. Na początku wszyscy są podekscytowani: testy klikają, raporty się świecą, a pipeline wygląda jak elegancka tablica rozdzielcza w nowym aucie. A potem przychodzi pierwszy większy refactor UI, zmiana API czy nowy mechanizm logowania – i nagle ten piękny zestaw testów zaczyna skrzypieć jak stara podłoga. Wtedy zwykle pada pytanie, które brzmi prosto, ale jest brutalnie szczere: „Czy my w ogóle mamy architekturę automatyzacji… czy tylko zbiór skryptów?”

Rozdział 3 sylabusa ISTQB CTAL-TAE odpowiada dokładnie na to pytanie. Robi to w sposób inżynierski: porządkuje myślenie o Test Automation Architecture (TAA) i o tym, jak zbudować rozwiązanie, które przetrwa próbę czasu.

 

gTAA: Fundament, który trzyma całość

Ten rozdział jest jak projekt konstrukcyjny mostu: nie skupia się na tym, czy śruby są ładne, tylko czy całość wytrzyma ruch, wiatr i „zmiany wymagań w ostatniej chwili”. Zaczynamy od gTAA (Generic Test Automation Architecture). To ramy, które pokazują, że automatyzacja nie żyje w próżni. Musi ona „rozmawiać” z całym ekosystemem projektu:
  • Zarządzanie testami: skąd bierzemy przypadki?
  • Zarządzanie konfiguracją: gdzie trzymamy artefakty?
  • Zarządzanie projektem: jak raportujemy status?
Dojrzała automatyzacja pobiera testy, uruchamia je w kontrolowany sposób, loguje błędy i daje sensowny sygnał zwrotny do ludzi i narzędzi.  

Architektura vs. „Klikanie” (TAE-3.1.1 & 3.1.2)

Wiele zespołów „przestrzela”, myląc automatyzację testów z automatyzacją klikania. Sylabus prostuje tę optykę, wskazując na kluczowe warstwy:
  1. Generacja i definicja: jak powstają testy?
  2. Wykonanie i logowanie: jak zbieramy dowody?
  3. Adaptacja: warstwa, która pozwala podłączyć się do interfejsów SUT (API, protokoły, serwisy).
To tutaj projektujemy TAS (Test Automation Solution). To jak instalacja w domu: możesz mieć najlepszy kran (narzędzie), ale bez sensownych rur (adapterów) i zaworów (konfiguracji) będziesz mieć albo powódź, albo brak wody.  

Warstwowanie frameworku (TAF) – Twój klucz do ROI

Najbardziej „inżynierską” częścią jest podział na warstwy (TAE-3.1.3). Sylabus promuje strukturę:
  • Warstwa skryptów (test scripts)
  • Warstwa logiki biznesowej
  • Warstwa bibliotek core
Dlaczego to się opłaca? Izolujesz zmienność SUT. Zamiast poprawiać 50 testów po zmianie jednego ekranu, poprawiasz jedno miejsce w kodzie. Przy dobrze poukładanej architekturze aktualizacja skryptów powinna zajmować nie więcej niż 25% całkowitej pracochłonności. To realny zwrot z inwestycji (ROI).  

Wybór podejścia (TAE-3.1.4)

Sylabus daje Ci język do rozmów z biznesem i managementem. Zamiast mówić „tak będzie lepiej”, możesz argumentować wybór konkretnego modelu:
  • Data-Driven / Keyword-Driven: Skalowanie i angażowanie osób nietechnicznych.
  • BDD / TDD: Skupienie na procesie i komunikacji.
  • Linear / Structured: Szybkie "proof of concept", ale trudniejsze utrzymanie.
 

Programistyczne standardy w testach (TAE-3.1.5)

Na deser dostajemy zasady projektowe i wzorce. Sylabus mówi wprost: automatyzacja to development. Liczą się tu:
  • Zasady SOLID i podstawy OOP.
  • Wzorce takie jak Facade, Singleton czy Page Object Model.
  • Flow Model Pattern: rozwinięcie POM, które poprawia abstrakcję w złożonych przepływach użytkownika.
Pamiętajcie: im lepszymi programistami jesteście, tym lepszymi automatykami będziecie. Najważniejsze korzyści z opanowania rozdziału 3:
  • Dla testera/TAE: umiejętność projektowania architektury (gTAA, TAS, TAF), świadomego doboru podejścia do automatyzacji (DDT/KDT/BDD itd.) oraz budowania testware w sposób „programistycznie czysty” (SOLID, POM, flow model).
  • Dla organizacji: mniej kosztownych zwrotów akcji, mniej kruchej automatyzacji i większa przewidywalność utrzymania dzięki warstwom, adapterom i sensownym integracjom z ekosystemem narzędzi.
  • Dla jakości dostarczania: stabilniejszy sygnał z pipeline (logowanie, raportowanie, lepsza adaptacja do interfejsów SUT), czyli krótsza droga od „coś się zepsuło” do „wiemy co i gdzie”