Bez magii i bez folkloru liczbowego. To strona, która ma przetrwać rozmowę z architektem banku: pokazuje mechanizm, fundamenty i granice. „Gdy AI pisze kod, jakość staje się zawodem" — a zawód ma metodę.
SQLC nie obiecuje, że AI „samo napisze testy". Obiecuje operating model: ustandaryzowane kroki, model procesu z kontraktami danych, dane testowe bez PII, kontrolowane środowiska, testy kontraktowe na stykach i twardy ślad audytowy dla wszystkiego, co generuje AI. Poniżej — jak każdy z tych elementów działa.
Skąd bierze się poprawny scenariusz E2E i dlaczego nie powstaje z losowego łączenia kroków BDD.
Dane, środowiska i testy kontraktowe — to, bez czego automatyzacja E2E rozpada się po tygodniu.
Co AI w 2026 robi dobrze, gdzie potrzebuje człowieka i dlaczego dane zostają on-prem.
Najczęstsze nieporozumienie: „AI weźmie kroki Gherkina i sklei z nich proces". Tak nie wychodzi poprawny scenariusz — wychodzi sekwencja, która kompiluje się, ale nie odzwierciedla rzeczywistego przepływu biznesu.
Krytyczna ścieżka — np. kredyt: sprzedaż → uruchomienie → spłata → zamknięcie — opisana jako graf stanów, przejść i warunków. Warianty — jak kredyt konsolidacyjny — to gałęzie tego grafu, nie osobne procesy. To on decyduje, w jakiej kolejności i pod jakimi warunkami kroki mają sens.
Jakie pola, typy, identyfikatory i niezmienniki przechodzą ze sprzedaży do uruchomienia, a dalej do spłaty. Kontrakt jest jawny i wersjonowany — nie ukryty w kodzie czterech zespołów.
Smart.AI dobiera reużywalne kroki z biblioteki i układa je zgodnie z grafem i kontraktami. Rola człowieka: zatwierdza model i kontrakty — to one są źródłem prawdy, nie pojedynczy wygenerowany scenariusz.
Scenariusz E2E jest poprawny, bo respektuje graf i kontrakty — nie dlatego, że „AI tak zdecydowało".
E2E przez cztery systemy oznacza, że te same encje muszą się zgadzać w każdym z nich. Dane produkcyjne odpadają — w banku nie wynosi się PII na środowiska testowe. Generujemy dane syntetyczne, ale z zachowaniem więzów i realistycznych rozkładów.
Klient, wniosek, umowa generowane z zachowaniem reguł domeny: poprawne identyfikatory, zgodne typy, sensowne kwoty i daty. Dane mają „kształt" prawdziwego portfela, bez prawdziwych osób.
Ten sam wniosek_id i ta sama umowa istnieją w sprzedaży, uruchomieniu i spłacie. Bez tej spójności styk pęka na poziomie danych, zanim test zdąży cokolwiek sprawdzić.
Tam, gdzie potrzebny jest realistyczny wolumen, używamy maskowania / pseudonimizacji danych produkcyjnych — z zachowaniem więzów referencyjnych i bez możliwości odtworzenia tożsamości. Zgodność z reżimem ochrony danych jest warunkiem brzegowym, nie dodatkiem.
Najczęstsza przyczyna „flaky" testów E2E to nie kod testu — to niespójne lub krótkotrwałe dane. Traktujemy dane testowe jak artefakt wersjonowany razem ze scenariuszem: powtarzalny zestaw, który da ten sam wynik jutro i za miesiąc.
Wybór per styk: wirtualizujemy to, co bezpieczne; na żywo testujemy to, co ryzykowne.
Pełne, trwałe środowisko ze wszystkimi systemami naraz to wąskie gardło i koszt. Zamiast tego dobieramy strategię per styk — i jesteśmy w tym uczciwi: wirtualizacja przyspiesza, ale nie zastąpi testu na prawdziwej integracji tam, gdzie leży ryzyko.
Stawiane na żądanie na czas przebiegu E2E, na prerekwizytach z dev, i niszczone po. Czysty stan początkowy = powtarzalny wynik, brak dryfu konfiguracji.
Tam, gdzie system zewnętrzny jest niedostępny, kosztowny lub nieprzewidywalny — symulujemy go zgodnie z kontraktem. Szybko, tanio, deterministycznie.
Integracje będące głównym źródłem defektów (Schemat 1) testujemy na realnych połączeniach. Wirtualizacja tu uśpiłaby czujność — to świadoma decyzja ryzyka, nie skrót.
To jest sedno problemu ze Schematu 1: shift-left testuje każdy moduł osobno, na mockach, a proces pęka na stykach, bo kontrakty danych między systemami nie są testowane. Contract testing zamyka dokładnie tę lukę — zanim dojdzie do drogiej regresji E2E.
Że to, co jedna strona wytwarza, druga strona potrafi skonsumować: pola, typy, formaty, kody błędów, wersje. Kontrakt jest jawny i wersjonowany — staje się umową, nie domysłem.
Mock to założenie jednego zespołu o tym, jak zachowuje się sąsiad — i to założenie się starzeje. Kontrakt jest współdzielony i weryfikowany po obu stronach, więc nie da się go niezauważenie złamać.
„Każdy moduł zielony, a proces nie działa" — to klasyczny objaw nietestowanych styków. Contract testing zamienia milczące założenie w jawną, weryfikowaną umowę.
Skoro testy generuje AI, pojawia się ryzyko, którego klasyczne QA nie znało: zielony test, który sprawdza złą rzecz. Test przechodzi, daje fałszywe poczucie bezpieczeństwa, a asercja nie dotyczy tego, co istotne. Dlatego governance nie jest dodatkiem — jest warunkiem, by w ogóle ufać generowanym testom.
Każdy test wie, skąd pochodzi: który model, jaki prompt/kontekst, z jakiego modelu procesu i kroków powstał.
Człowiek zatwierdza model procesu, kontrakty i asercje krytyczne. AI proponuje — inżynier akceptuje.
Co przetestowano, czym, z jakim wynikiem i kto zatwierdził. Mapuje się wprost na zarządzanie ryzykiem ICT (DORA).
Asercje recenzowane pod kątem „czy sprawdzamy właściwą rzecz". Pokrycie liczone jako BJC, nie jako liczba zielonych przebiegów.
Uczciwa mapa: te zdolności są dziś dojrzałe na tyle, by dawać wartość w produkcyjnym QE — pod warunkiem governance z punktu 5. Każda z nich ma jasno wskazaną rolę człowieka.
Największy wpływ na TCO: utrzymanie zabija ROI automatyzacji. AI adaptuje selektory i kroki do drobnych zmian UI/API, zamiast wywracać całą suitę na czerwono.
Odkrywa nieznane ścieżki — „nie wiesz, czego nie wiesz". Agent przechodzi aplikację, proponuje journeys, które warto pokryć. Człowiek decyduje, które są krytyczne.
Z ruchu i specyfikacji AI wnioskuje kontrakty API i wykrywa dryf na stykach — zanim stanie się defektem w procesie.
Z diffa zmiany AI wybiera podzbiór E2E o największym wpływie (change-impact). To sprawia, że „regresja na żądanie" jest naprawdę szybka, a nie tylko z nazwy.
Asercje semantyczne tam, gdzie porównanie literalne nie wystarcza: treść dokumentu, komunikat, wyciąg. Werdykt modelu jest logowany i podlega przeglądowi — nie jest ostatnim słowem.
Nie definiuje, co jest krytyczne dla biznesu, nie zatwierdza asercji ryzyka i nie bierze odpowiedzialności za zgodność. To zostaje przy inżynierze jakości.
W banku to nie jest pytanie wygody, tylko warunek brzegowy: dane i PII zostają on-prem. Dlatego architektura jest hybrydowa — i jesteśmy szczerzy co do kompromisu.
Dane testowe, maskowanie i przetwarzanie wrażliwych wejść pozostają w granicach klienta. Nic, co identyfikuje osobę, nie opuszcza środowiska.
Najsilniejszy reasoning — kompozycja, eksploracja, inferencja kontraktów — może działać w chmurze na zsanityzowanych wejściach lub metadanych, gdy polityka klienta na to pozwala.
Lokalny model na zsanityzowanych wejściach bywa słabszy w trudnym reasoningu niż topowy model w chmurze. Nie udajemy inaczej — dobieramy granicę local/cloud per ryzyko i per polityka, świadomie.
Granica jest projektowana, nie domyślna — i dokumentowana w śladzie audytowym.
Model procesu, dane, środowiska, kontrakty i governance nie są celem samym w sobie — istnieją po to, by Business Journey Coverage rosło w sposób, któremu da się zaufać. Nie obiecujemy procentów z folderu — obiecujemy pomiar u Ciebie.
BJC = udział krytycznych procesów E2E, które są zielone, aktualne i reużywalne — przez realne styki, nie mocki. Plus metryki wspierające: defekty na stykach, czas pełnej regresji, MTTR, lead time wdrożenia. Realny efekt weryfikujemy w 90-dniowym pilotażu na Twoich danych — punkt startowy vs koniec.
Bierzemy jeden krytyczny proces (np. kredyt: sprzedaż → uruchomienie → spłata → zamknięcie), budujemy model procesu, kontrakty, dane, złożone E2E i kokpit BJC — i mierzymy realny efekt. Decyzja go/no-go należy do Ciebie.