01
Poziom B · Kierownictwo

SQLC dla kierownictwa:
operating model, adopcja, metryka

Shift-left dał szybkość, ale rozproszył odpowiedzialność za jakość całego procesu biznesowego. Smart Testing Suite odzyskuje globalny widok E2E jako operating model — bez przywracania centralnego QA jako wąskiego gardła. Pokażemy, kto jest właścicielem jakości, jak napędzamy adopcję, jak rządzimy testami tworzonymi przez AI i którą metryką to potwierdzimy.

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

02
Diagnoza

Gdzie jesteśmy po shift-left

Decentralizacja testów przyniosła realne korzyści — i równie realne luki. Trzeba nazwać jedno i drugie, bez deprecjonowania inżynierów.

+
Mocne strony. Małe, autonomiczne zespoły testują wcześnie i punktowo — na mockach i małych środowiskach. Automaty stoją przy kodzie, działają w CI/CD, technologia dobierana swobodnie. Lokalnie jakość jest pod kontrolą i chcemy to utrzymać.
−
Słabe strony. Centralne QA zlikwidowane lub mocno ograniczone — brak właściciela całości. Proces biznesowy biegnie w poprzek zespołów i pęka na stykach aplikacji, gdzie kontrakty danych nie są testowane. Brak reużywalnej automatyzacji E2E i wspólnego języka między zespołami.
!
Sedno. Zielone CI nie równa się działającemu procesowi biznesowemu. Mamy pewność co do komponentów, nie mamy pewności co do całości — a w erze AI komponentów przybywa szybciej, niż rośnie pewność co do procesu.
03
Problem operacyjny

Co realnie boli w codziennej pracy

Przykład: cykl życia kredytu — sprzedaż → uruchomienie → spłata → zamknięcie. Każdy etap obsługuje inna aplikacja i inny zespół.

1
Brak właściciela E2E. Każdy zespół odpowiada za swój fragment, nikt za przepływ end-to-end. Na pytanie „czy sprzedaż kredytów na pewno zadziała po wdrożeniu" nie ma jednej, wiarygodnej odpowiedzi popartej dowodem.
2
Brak reużywalnej automatyzacji E2E. Różne technologie i konwencje uniemożliwiają złożenie scenariuszy procesu z gotowych klocków. Testy międzyaplikacyjne powstają ręcznie i jednorazowo, na mockach zamiast realnych styków.
3
Skutki. Ryzyko produkcyjne i strach przed wdrożeniem, incydenty na stykach, syndrom „działa u mnie". Regresja całego procesu jest długa i kosztowna, więc uruchamiana rzadko — co znów podnosi ryzyko.
04
Operating model

SQLC — pięć etapów cyklu jakości

Kategoria to AI-native Quality Engineering. SQLC to nasz operating model: jakość jako pętla w rdzeniu cyklu, nie etap na końcu. SDLC ustępuje miejsca SQLC — z mapowaniem na moduły STS.

1
Intencja jakości (Quality by Intent) — wymagania od razu jako testowalne kryteria BDD. STS: Smart.AI.Analyst
2
Budowa z jakością (Quality by Construction) — AI pisze kod (mechaniczne), kroki testowe standaryzowane, self-healing testów. STS: Smart.Edytor, Smart.AI.Tester
3
Kompozycja jakości (Quality by Composition) — AI składa kroki w E2E wg modelu procesu i kontraktów danych. Serce rozwiązania, etap nieobecny w SDLC. STS: Smart.AI + Biblioteka kroków
4
Ciągła jakość (Continuous Quality) — continuous testing, risk-based selection, dane testowe, środowiska. STS: Smart.Runner + Continuous Testing
5
Wgląd w jakość (Quality Insight) — kokpit, metryka BJC, pętla z produkcji → wraca do intencji. STS: Smart.Kokpit
05
Jak to działa naprawdę

Kompozycja E2E to nie „sklejanie" Gherkina

Żeby złożony scenariusz był poprawny, potrzebne są fundamenty — to one decydują, czy obietnica jest uczciwa wobec architekta banku.

▸
Model procesu i kontrakty danych. Graf journey opisuje, jak systemy przekazują sobie dane między etapami. AI komponuje E2E wg tego modelu, a nie losowo — tu jest nasze IP.
▸
Dane testowe. Syntetyczne, spójne między systemami, maskowane — bez PII z produkcji. Bez spójnych danych scenariusz międzyaplikacyjny po prostu się rozjeżdża.
▸
Środowiska i styki. Ephemeral envs + service virtualization tam, gdzie realny system jest niedostępny; realne styki tam, gdzie to ryzyko. Contract testing atakuje wprost pęknięcia na stykach.
▸
Risk-based selection + pętla z produkcji. Z diffa AI wybiera podzbiór E2E (change-impact); obserwowalność (Dynatrace) wskazuje ryzykowne journeys i ustawia priorytet testów. SQLC to pętla, nie linia.
06
Adopcja · role

Kto jest właścicielem jakości E2E

Odpowiedzialność za widok E2E wraca do organizacji — ale jako warstwa platformowa, nie jako centralne QA odtwarzające wąskie gardło. Podział jest jasny i nienakładający się.

▸
Quality Platform Team — właściciel platformy. Utrzymuje bibliotekę kroków i model procesu / kontrakty danych, dba o standard i jakość katalogu. Nie pisze wszystkich testów za zespoły — dostarcza im narzędzia i wzorce. To „paved road", nie bramka.
▸
Zespoły produktowe — kontrybuują kroki. Wnoszą reużywalne, standardowe kroki BDD do wspólnej biblioteki jako element definition-of-done. Pracują dalej w swoim tempie i swoich technologiach; kontrybucja kroku jest częścią „skończone".
▸
AI (Smart.AI) — składa E2E. Z biblioteki kroków komponuje długie scenariusze procesów wg modelu procesu. Zdejmuje z ludzi mozół ręcznego budowania testów międzyzespołowych.
▸
Kierownictwo QA/IT — konsument widoku. Korzysta z kokpitu (Smart.Kokpit): metryka BJC, decyzja o wdrożeniu i ślad audytowy. Zarządza, nie wytwarza.
07
Silnik adopcji · governance

Academy napędza zmianę, governance ją zabezpiecza

Operating model bez adopcji to martwa biblioteka, a testy generowane przez AI bez nadzoru to ryzyko „zielonego testu sprawdzającego złą rzecz". Adresujemy oba.

▸
Academy — silnik adopcji. Szkolenia i certyfikacja „SQLC / Quality Engineer" uczą zespoły pisać standardowe kroki i myśleć o jakości procesu. To kanał, którym standard wchodzi do organizacji — i nasz wyróżnik oraz linia przychodu.
▸
Provenance i zatwierdzanie. Każdy test ma pochodzenie: skąd powstał, na jakim modelu procesu, kto zaakceptował. Human-in-the-loop dla scenariuszy krytycznych — AI proponuje, człowiek zatwierdza.
▸
Ślad audytowy. Dowód „co przetestowano i z jakim wynikiem" — wprost pod wymóg zarządzania ryzykiem ICT (DORA). Testy AI nie są czarną skrzynką.
▸
Ryzyko halucynacji. Nazywamy je wprost: AI może wygenerować test, który jest zielony, a sprawdza złą rzecz. Mitigacja: model procesu jako źródło prawdy, przegląd, LLM-as-judge tam, gdzie asercja jest semantyczna.
08
Metryka zarządcza

Business Journey Coverage — metryka, która brakuje

Banki dziś tego nie mierzą. BJC odpowiada na pytanie zarządcze „czy proces zadziała po wdrożeniu?". Kto definiuje metrykę, kontroluje rozmowę.

B
BJC — definicja. Udział krytycznych ścieżek biznesowych z aktualną, zieloną, reużywalną automatyzacją E2E przez realne styki (nie mocki). Wzór: krytyczne procesy E2E zielone i aktualne ÷ wszystkie krytyczne procesy.
▸
Metryki wspierające — zamiast obietnic procentowych. Udział błędów łapanych przed E2E · liczba defektów na stykach aplikacji · czas pełnej regresji · MTTR · lead time wdrożenia. To zestaw, który kierownictwo śledzi w kokpicie.
▸
Obiecujemy pomiar, nie liczby z folderu. Realny efekt u Was mierzymy w pilotażu — start vs koniec. Benchmarki branżowe traktujemy jako punkt odniesienia do potwierdzenia Waszymi danymi, nie jako gwarancję.

Efekt brzmieniowy: pełna regresja E2E staje się przewidywalna, szybka i w większości zielona — co umożliwia bezpieczne wdrożenia na żądanie.

09
Mapa wdrożenia · pilotaż

Od pilotażu 90 dni do skali

Wdrożenie przyrostowe — wartość już po pierwszym procesie, bez zatrzymywania zespołów. Punkt startu: jedna ścieżka kredytowa (sprzedaż → uruchomienie → spłata → zamknięcie).

Pilotaż 90 dni (30/60/90)
30
Model i kroki. Model procesu wybranej ścieżki + pierwszy zestaw standardowych kroków od zespołów.
60
Kompozycja. Smart.AI składa pierwsze pełne E2E przez realne styki; pierwsza zielona regresja procesu.
90
Pomiar i decyzja. Kokpit BJC (start vs koniec) + raport; decyzja go/no-go o rozszerzeniu.
Skalowanie po pilotażu
▸
Kolejne ścieżki. Biblioteka kroków rośnie, kontrybucja staje się rutyną (definition-of-done).
▸
Academy. Certyfikacja zespołów — adopcja samonapędzająca się.
▸
Kokpit jako proces zarządczy. BJC i metryki wspierające wchodzą do cyklu decyzji o wdrożeniach.

Po stronie klienta: dostęp do środowisk dev, dane do maskowania, 1–2 osoby kontaktowe z zespołów. Kryterium sukcesu: wzrost BJC do ustalonego celu i działająca regresja E2E na żądanie.

10
Ryzyka

Ryzyka i jak je adresujemy

Najczęstsze obawy kierownictwa przy zmianie operating modelu — i konkretna, uczciwa odpowiedź na każdą.

▸
Nowe wąskie gardło QA. → Quality Platform Team utrzymuje platformę i wzorce, nie pisze testów za zespoły. Kroki tworzą zespoły, scenariusze składa AI, kierownictwo konsumuje widok. „Paved road", nie bramka.
▸
Heterogeniczne technologie. → Standard kroków BDD daje wspólny język ponad technologiami; integracje (Jira/Xray/Dynatrace) wpinają STS w istniejący stos.
▸
Testy AI niewiarygodne. → Governance: model procesu jako źródło prawdy, provenance, human-in-the-loop dla krytycznych scenariuszy, LLM-as-judge dla asercji semantycznych. Ryzyko nazwane, nie ukrywane.
▸
Spowolnienie zespołów. → Wdrożenie przyrostowe, CI/CD bez zmian, kontrybucja kroku jako część definition-of-done, a nie osobny projekt.
▸
Zgodność i audyt (DORA / NIS 2). → Ślad audytowy jakości, dowody „co przetestowano i z jakim wynikiem", testowanie odporności operacyjnej krytycznych procesów, niższy MTTR na stykach.
11
Następny krok

Zacznijmy od jednej ścieżki — i zmierzmy efekt

Wybierzmy jeden krytyczny proces i przejdźmy z nim przez pełny cykl SQLC — od intencji po kokpit BJC. W 90 dni zobaczycie pierwszą zieloną regresję E2E przez realne styki i realny, zmierzony wzrost Business Journey Coverage.

▸
Pilotaż 90 dni → warsztat diagnozy, model procesu, pierwsze E2E, kokpit BJC i raport go/no-go.
▸
Business Journey Coverage → jak definiujemy poziomy pokrycia i metryki wspierające.
▸
Jak to działa naprawdę → model procesu, dane, środowiska, governance testów AI.

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