01
Poziom C · Zespoły · Architekci

SQLC dla zespołów — jak to działa naprawdę

AI-native Quality Engineering z perspektywy QA, automatyków i architektów. Nie „mamy AI" — pokazujemy mechanikę: model procesu i kontrakty danych, kompozycję E2E, dane syntetyczne, środowiska, contract testing, governance testów AI i to, gdzie leży realna granica modeli językowych. SQLC to nasz operating model — wspólna biblioteka kroków, zespół platformowy i pętla, nie linia.

„Gdy AI pisze kod, jakość staje się zawodem."

02
Zasada

Zostaje shift-left. Dokładamy cienką warstwę kompozycji — i fundamenty

Nie odbieramy zespołom autonomii ani szybkości. Testy zostają wcześnie i blisko kodu. Na wierzchu budujemy warstwę, która odzyskuje globalny widok E2E — ale tylko wtedy, gdy stoją za nią rzeczy, których v1 nie pokazywał: model procesu, dane, środowiska, kontrakty.

1
Zostaje shift-left. Te same zespoły, ta sama szybkość, CI/CD bez zmian. Testy wcześnie, punktowo, na mockach i małych środowiskach, swobodny dobór technologii.
2
Dochodzi warstwa kompozycji. Standaryzacja kroków BDD → wspólna Biblioteka kroków → AI składa atomowe kroki w długie scenariusze E2E — ale wg modelu procesu i kontraktów danych, nie przez sklejanie Gherkina.
3
Bez centralnego QA jako wąskiego gardła. Globalny widok E2E powstaje z reużywalnych komponentów zespołów. Właścicielem standardu jest Quality Platform Team, nie blokujący zespół kontrolny.
4
To pętla, nie etap. Obserwowalność z produkcji wskazuje ryzykowne journeys → priorytet testów → kompozycja → regresja → znów produkcja.

Efekt: zielone CI przestaje znaczyć „działa u mnie", a zaczyna znaczyć „proces biznesowy zadziała po wdrożeniu".

03
Intencja jakości · Quality by Intent

Jeden zapis: wymaganie = testowalne kryterium

Wymagania od razu jako kryteria w Gherkin (Given/When/Then). To stała granica między biznesem a automatyzacją — czytelna dla analityka, wykonywalna dla automatu. Etap SQLC: Intencja jakości, moduł Smart.AI.Analyst.

# Cykl życia kredytu — etap: sprzedaż kredytu
Funkcja: Sprzedaż kredytu konsumenckiego

  Scenariusz: Pozytywna decyzja dla klienta z dodatnią zdolnością
    Zakładając klienta z dochodem 8000 PLN i bez zaległości
    Oraz wniosek o kredyt na kwotę 30000 PLN na 36 miesięcy
    Kiedy system oceni zdolność kredytową
    Wtedy decyzja kredytowa jest „pozytywna"
    Oraz umowa kredytowa zostaje wygenerowana
    Oraz kredyt jest gotowy do uruchomienia
04
Budowa z jakością · Quality by Construction

Biblioteka kroków: wspólny język mimo różnych technologii

Każdy zespół implementuje swoje kroki we własnej technologii, ale wystawia je w jednym słowniku Given/When/Then. Krok „klient z dochodem 8000 PLN" znaczy to samo niezależnie od tego, czy stoi za nim REST, UI czy kolejka. Etap SQLC: Budowa z jakością — Smart.Edytor, Smart.AI.Tester.

1
Reużywalność. Raz napisany krok obsługuje wiele scenariuszy. Atomowe kroki to klocki, z których powstają dziesiątki ścieżek.
2
Krok jako kontrakt. Analityk, tester i automatyk mówią tym samym Gherkin. Implementacja może się zmieniać pod spodem — sygnatura kroku jest stabilna i wersjonowana.
3
Niezależność technologiczna. Selenium, Playwright, REST-client, sterowniki kolejek — pod jednym krokiem. Zespół zachowuje swój stack.
★
Self-healing (granica AI nr 1). Utrzymanie testów zabija ROI automatyzacji. AI naprawia kruche lokatory i drobne dryfy UI/API, proponuje poprawkę kroku — z prowenancją i do zatwierdzenia. To największy wpływ na TCO, nie efekt „wow".
05
Kompozycja jakości · Quality by Composition

Serce: model procesu + kontrakty danych

Tu jest IP. Kompozycja E2E to nie sklejanie Gherkina — to złożenie kroków wg grafu journey i kontraktów danych między systemami, żeby scenariusz był biznesowo poprawny, a nie tylko składniowo wykonywalny. Etap nieobecny w klasycznym SDLC. Moduł: Smart.AI + Biblioteka kroków.

→
Graf journey. Model przepływu: sprzedaż → uruchomienie → spłata → zamknięcie, z warunkami przejść i gałęziami wariantów (np. kredyt konsolidacyjny) — nie liniowy skrypt.
→
Kontrakty danych na stykach. Wyjście jednego etapu (ID kredytu, status umowy) jest wejściem kolejnego. Kontrakt opisuje schemat, typy i niezmienniki na granicy aplikacji.
→
AI składa wg modelu, nie losowo. Smart.AI dobiera kroki i mapuje dane na stykach zgodnie z grafem i kontraktami — generuje wykonywalny scenariusz E2E w Gherkin.
→
Człowiek zatwierdza. Inżynier przegląda i akceptuje kompozycję. AI usuwa mozół ręcznego sklejania, nie odbiera kontroli nad jakością.

Bez modelu procesu „kompozycja" jest zgadywaniem. Z modelem — atakuje dokładnie te styki, na których pęka proces (Schemat 1).

06
Dane testowe

Scenariusz E2E jest tak dobry, jak jego dane

Długi scenariusz przez cały cykl kredytu wymaga spójnych prerekwizytów na każdym styku. Stan wejściowy jednego etapu jest wyjściem poprzedniego — dlatego dane generujemy syntetycznie, deterministycznie i spójnie między systemami, bez PII z produkcji.

1
Syntetyczne i spójne między systemami. Ten sam klient, ten sam ID kredytu i ta sama umowa są zgodne w CRM, silniku decyzyjnym i księgowości — inaczej E2E przejdzie u jednego zespołu i pęknie na styku.
2
Bez PII z produkcji. Dane generowane lub maskowane — wymóg DORA/NIS 2 i higiena bezpieczeństwa, nie opcja. Maskowanie zachowuje referencyjność (te same klucze obce po obu stronach styku).
3
Dane jako kroki. „Zakładając klienta z dochodem 8000 PLN" to też krok z Biblioteki — przygotowanie danych jest reużywalne i wersjonowane.
4
Determinizm i izolacja. Każdy przebieg startuje z czystego, znanego stanu — bez „flaków" zależnych od kolejności i resztek danych.
07
Środowiska · Contract testing

Realne styki tam, gdzie ryzyko. Wirtualizacja tam, gdzie trzeba

Nie udajemy, że wszystko da się uruchomić na realnym, pełnym środowisku integracyjnym. Mieszamy podejścia świadomie — i pilnujemy styków kontraktami, bo to one pękają (Schemat 1).

1
Ephemeral environments. Środowiska tworzone na żądanie z czystego stanu, z syntetycznymi danymi — powtarzalne i tanie do zburzenia po przebiegu.
2
Service virtualization. Tam, gdzie realny system jest niedostępny, drogi lub niesterowalny (np. zewnętrzne BIK-i, systemy stron trzecich) — wirtualizujemy z zachowaniem kontraktu, nie naiwny mock.
3
Realne styki tam, gdzie ryzyko. Krytyczne granice testujemy na realnych integracjach — bo właśnie tam proces pęka i tam mock kłamie.
4
Contract testing na stykach. Konsument i dostawca weryfikują wspólny kontrakt (schemat, pola, semantyka). Wirtualizacja używa tego samego kontraktu co produkcja — dryf wychodzi, zanim trafi na integrację.
08
AI frontier · gdzie jest realna granica

Co AI dziś robi dobrze — uczciwie

Nie „AI testuje za was". AI przesuwa konkretne granice, w których ręczna praca jest droga lub niemożliwa. Każda z nich ma swoje ograniczenie i swój nadzór człowieka.

A
Agentowa eksploracja. Agent odkrywa nieznane ścieżki w aplikacji — „nie wiesz, czego nie wiesz". Znajduje journeys, których nikt nie opisał, i proponuje je jako kandydatów do Biblioteki.
B
Inferencja kontraktów API + dryf na stykach. AI wnioskuje schemat z ruchu/specyfikacji i wykrywa dryf (zmiana pola, typu, semantyki) na granicy aplikacji — wcześnie, zanim pęknie E2E.
C
Risk-based / change-impact selection. Z diffa zmiany AI wybiera podzbiór E2E, których zmiana dotyka — „na żądanie" jest naprawdę szybkie, bo nie uruchamiamy wszystkiego za każdym razem.
D
LLM-as-judge (asercje semantyczne). Tam, gdzie wynik to dokument, komunikat czy wyciąg, klasyczna asercja „equals" nie wystarczy. LLM ocenia zgodność semantyczną — sędzia, którego decyzję się audytuje, nie wyrocznia.
09
Governance testów AI

Ryzyko: zielony test, który sprawdza złą rzecz

Największe ryzyko AI w testach to nie czerwony fałszywy alarm — to halucynowany test, który jest zielony, a nie weryfikuje tego, co trzeba. Dlatego governance jest częścią produktu, nie dodatkiem.

1
Provenance. Każdy test ma pochodzenie: kto/co go wygenerował, z jakiego wejścia, na bazie którego kroku i modelu. Bez prowenancji nie ma zaufania.
2
Human-in-the-loop. AI proponuje — inżynier zatwierdza. Kompozycje, self-healing i nowe kroki przechodzą przez przegląd, zanim wejdą do regresji.
3
Ślad audytowy. Co przetestowano, czym, z jakim wynikiem i kto zatwierdził — spójnie z DORA (zarządzanie ryzykiem ICT, dowody jakości).
4
Walidacja asercji. LLM-as-judge bywa niespójny — kotwiczymy go przykładami referencyjnymi i mierzymy zgodność z oceną człowieka, zanim mu zaufamy w bramce.

Quality Platform Team jest właścicielem reguł governance i Biblioteki — to nie odtworzenie centralnego QA jako wąskiego gardła, lecz właściciel standardu.

10
Architektura AI · local vs cloud

Hybryda local/cloud — uczciwie

W banku dane decydują o architekturze. Nie udajemy, że lokalny model dorównuje topowemu wszędzie — pokazujemy realny kompromis i jak go domykamy.

1
On-prem dla danych i PII. Wszystko, co dotyka danych wrażliwych, zostaje w infrastrukturze klienta — wymóg sektora, nie preferencja.
2
Hybryda jest kompromisem. Reasoning na zsanityzowanych/zamaskowanych wejściach jest trudniejszy niż na pełnym kontekście. Mówimy to wprost — to wpływa na jakość kompozycji i asercji.
3
Cięższe zadania tam, gdzie wolno. Trudniejszy reasoning kierujemy do mocniejszego modelu wtedy i tylko wtedy, gdy wejście jest pozbawione PII i polityka klienta na to pozwala.
4
Domknięcie deterministyczne. Tam, gdzie model lokalny jest słabszy, dokładamy reguły, kontrakty i asercje referencyjne — mniej polegamy na „rozumieniu", więcej na strukturze.
11
Ciągła jakość · Wgląd w jakość

Regresja na żądanie i metryka, której banki nie mierzą

Mając Bibliotekę kroków, kompozycję wg modelu, dane, środowiska i change-impact selection, pełną regresję funkcjonalną uruchamiasz na żądanie. Efektu nie obiecujemy liczbą — mierzymy go u klienta metryką Business Journey Coverage. Moduły: Smart.Runner + Continuous Testing, Smart.Kokpit.

1
Na żądanie, nie raz na kwartał. Regresja E2E jako rutynowa operacja: przed wdrożeniem, po zmianie na styku, w cyklu nocnym. Change-impact selection skraca przebieg do tego, co zmiana naprawdę dotyka.
2
Przewidywalna, szybka, w większości zielona. Większość błędów łapana wcześniej (taniej), więc E2E jest krótkie i mało awaryjne — nie „formalność", lecz przewidywalna bramka.
3
Pętla z produkcji. Obserwowalność (Dynatrace) wskazuje ryzykowne journeys → priorytet testów → kompozycja → regresja. SQLC to loop, nie linia.
BJCBusiness Journey Coverage — naszą metrykę mierzymy w pilotażu (start vs koniec)
MTTRczas reakcji na incydent — szybsze wykrycie na stykach (metryka wspierająca)
lead timeczas wdrożenia zmiany — efekt regresji na żądanie (do zmierzenia u klienta)
12
Porozmawiajmy

Zacznijmy od jednej ścieżki E2E

Pilotaż 90 dni (30/60/90) na jednej ścieżce kredytowej. Dostarczamy model procesu, zestaw standardowych kroków, złożone E2E i kokpit BJC. Mierzymy BJC start vs koniec plus metryki wspierające — bez przebudowy zespołów i bez centralnego wąskiego gardła. „Gdy AI pisze kod, jakość staje się zawodem."

Pilotaż 90 dni → Schemat 1 — problem Business Journey Coverage

biuro@smartware.pl · +48 609 410 984 · ul. Strzegomska 140A, 54‑429 Wrocław