W dużym banku detalicznym piątkowy release przeszedł wzorcowo. Wszystkie pipeline'y na zielono, wszystkie zespoły z odhaczonym „done". W poniedziałek rano klient, który właśnie skonsolidował dwa kredyty, nie zobaczył nowego harmonogramu spłat. Żaden zespół nie miał czerwonego testu. Każdy powtarzał to samo zdanie: „u mnie działa".
Ta scena powtarza się w niemal każdej dużej organizacji, która przez ostatnią dekadę z sukcesem przesunęła testy „w lewo". Shift-left zrobił dokładnie to, co obiecywał: błędy zaczęto wykrywać wcześnie i tanio, jak najbliżej developera. Zespoły dostały autonomię, szybkość i własne CI. Problem w tym, że ta sama decyzja, która dała szybkość, po cichu zlikwidowała coś, czego nikt nie wpisał do backlogu: globalny widok na to, czy cały proces biznesowy nadal działa — i jakąkolwiek liczbę, która by to opisywała.
To nie jest artykuł przeciwko shift-left. To artykuł o tym, że w erze, w której coraz więcej kodu pisze AI, samo pisanie kodu przestaje być wąskim gardłem — a jakość staje się osobnym zawodem. Quality Engineering nie polega na dokładaniu testów do komponentów. Polega na umieniu odpowiedzieć na jedno pytanie zarządcze: czy proces, za który klient płaci, zadziała po wdrożeniu.
Kontekst: bank, który zrobił wszystko „zgodnie ze sztuką"
Wyobraźmy sobie organizację, którą znamy z sektora finansowego — duży bank z dziesiątkami zespołów produktowych. Kilka lat temu przeszedł transformację, którą każdy konsultant by pochwalił. Monolit rozbito na produkty. Każdy zespół dostał pełną odpowiedzialność za swój kawałek: własny backlog, własny pipeline, własny wybór technologii. Testy zeszły do poziomu kodu, do CI, jak najbliżej developera.
Decyzje, które wtedy zapadły, były racjonalne — każda z osobna. Razem ułożyły się jednak w pułapkę, której konsekwencje widać dopiero na produkcji.
Anatomia problemu: pięć rozsądnych decyzji, jeden martwy punkt
Decentralizacja. Małe, autonomiczne zespoły to przepis na szybkość. Ale autonomia oznacza też, że każdy zespół optymalizuje swój wycinek — i nikt nie jest właścicielem całości. Proces biznesowy biegnący w poprzek dziesięciu zespołów nie ma jednego gospodarza.
Testy na mockach i małych środowiskach. Żeby testować wcześnie i szybko, sąsiednie systemy się zaślepia. Mock zwraca to, czego się od niego oczekuje — czyli założenia autora testu, a nie realne zachowanie sąsiedniej aplikacji. Test jest zielony, bo sprawdza świat, który zespół sam sobie wyobraził.
Automaty „przy kodzie", w CI. Testy żyją w repozytorium konkretnego zespołu i sprawdzają jego komponent. Doskonale chronią pojedynczy moduł. Z definicji nie widzą jednak, co dzieje się za jego granicą.
Swobodny dobór technologii. Jeden zespół pisze testy w jednym frameworku, drugi w innym, trzeci ma własną konwencję. Nie istnieje wspólny język ani wspólne „klocki", z których można by złożyć test całej ścieżki. Reużycie między zespołami jest praktycznie niemożliwe.
Zlikwidowane lub mocno ograniczone centralne QA. W imię zwinności rozwiązano dział, który kiedyś patrzył na system jako całość. Razem z nim zniknął jedyny zespół, który zadawał pytanie „a czy cały proces nadal działa?". Teraz nie zadaje go nikt — i nikt nie ma narzędzia, żeby na nie odpowiedzieć liczbą.
Zielone CI w każdym zespole to nie to samo, co działający proces biznesowy. To dwie różne rzeczy, które przez lata myliliśmy ze sobą — dopóki produkcja nie pokazała różnicy.
Sedno: styki to nietestowane kontrakty danych
Najważniejsze zdanie tego artykułu: granica między dwiema aplikacjami nie jest pustym miejscem — jest kontraktem danych. Aplikacja A obiecuje przekazać aplikacji B rekord o określonym kształcie, w określonym formacie, o określonym znaczeniu każdego pola. Aplikacja B zakłada, że ta obietnica zostanie dotrzymana. Cały proces biznesowy trzyma się na sumie tych obietnic.
Problem w tym, że w architekturze po shift-left tych kontraktów nie testuje nikt na realnym łączeniu. Zespół A testuje siebie przy zamockowanym B — czyli przy własnym wyobrażeniu kontraktu. Zespół B testuje siebie przy zamockowanym A — przy własnym wyobrażeniu tego samego kontraktu. Oba mocki są zielone. Oba kodują różne założenia. Kontrakt, który łączy te dwa systemy, nigdy nie został zweryfikowany jako całość — istnieje wyłącznie jako dwa rozbieżne wyobrażenia po dwóch stronach granicy.
To dlatego styki są najdroższym i najbardziej ryzykownym miejscem w systemie. Defekt wewnątrz komponentu łapie ten, kto go napisał. Defekt na styku — niezgodność dwóch kontraktów — nie ma właściciela, nie ma testu i nie ma czerwonego sygnału. Ujawnia się dopiero u klienta.
Konkret: cykl życia kredytu, który pęka na stykach
Weźmy proces, który w banku przechodzi przez cztery aplikacje i cztery zespoły: sprzedaż kredytu → uruchomienie → spłata → zamknięcie. Każdy etap obsługuje inna aplikacja, każdą rozwija inny zespół. Do tego dochodzą warianty — np. kredyt konsolidacyjny — czyli gałęzie tego samego procesu, nie osobne procesy.
Zespół sprzedaży testuje wniosek i decyzję kredytową — u niego wszystko działa. Zespół uruchomienia testuje wypłatę środków — zielono. Zespół spłaty testuje naliczanie rat na swoich danych testowych — bez zarzutu. Zespół zamknięcia testuje wygaszanie umowy — komplet zielony. Cztery aplikacje, cztery komplety zielonych testów, cztery zadowolone zespoły.
A potem proces biznesowy przechodzi w poprzek tych granic — i właśnie tam pękają kontrakty danych. Sprzedaż przekazuje uruchomieniu rekord w formacie, który u sprzedaży jest poprawny, ale uruchomienie interpretuje jedno pole inaczej. Uruchomienie przekazuje spłacie nowy harmonogram, którego moduł spłaty nie odświeża, bo testował na zamockowanym, „starym" harmonogramie. Każdy styk między aplikacjami to obietnica danych, której nikt nie zweryfikował end-to-end — bo każdy zespół testował przy zaślepionym sąsiedzie. Klient po uruchomieniu kredytu nie widzi harmonogramu nie dlatego, że któryś moduł jest zepsuty, ale dlatego, że nikt nie przetestował kontraktu między modułami na realnym połączeniu.
Martwe pole: brak globalnego E2E i brak reużywalnej automatyzacji
W tej organizacji nie ma już nikogo, kto testowałby pełną ścieżkę end-to-end. Nie ma reużywalnej automatyzacji E2E, bo każdy zespół mówi innym „językiem" technologicznym i nie da się złożyć jego testów z testami sąsiada. Nie ma wspólnego słownika kroków, z których można by zbudować scenariusz całego procesu kredytowego. Styki aplikacji — najdroższe i najbardziej ryzykowne miejsca w systemie — są dokładnie tym obszarem, którego nie testuje nikt.
To nie jest luka, którą da się załatać jednym testem. To strukturalne martwe pole: shift-left z założenia patrzy w dół, do komponentu, a proces biznesowy biegnie w bok, przez granice komponentów i przez kontrakty danych między nimi. Im więcej zespołów, tym więcej styków — i tym większy obszar, którego nikt nie widzi.
Brakuje metryki: nikt nie mierzy pokrycia procesów
Tu dochodzimy do drugiego, cichszego problemu — głębszego niż brak testów. Zapytaj w takim banku o pokrycie testami, a dostaniesz liczby: pokrycie kodu w każdym repozytorium, liczbę przypadków testowych, odsetek zielonych buildów. Wszystkie te metryki dotyczą komponentów. Żadna z nich nie odpowiada na pytanie, które naprawdę zadaje zarząd: jaki procent naszych krytycznych procesów biznesowych jest dziś przetestowany od końca do końca, przez realne styki?
Nie ma takiej liczby, bo nie ma takiej metryki. Organizacja mierzy dziesiątki rzeczy na poziomie kodu i nie mierzy ani jednej na poziomie procesu. To dlatego decyzja o wdrożeniu zapada na podstawie sumy zielonych pipeline'ów i nadziei — nie ma wskaźnika, który mógłby ją uzasadnić ani podważyć.
Tę lukę nazywamy Business Journey Coverage (BJC): odsetek krytycznych ścieżek biznesowych z aktualną, zieloną, reużywalną automatyzacją E2E przechodzącą przez realne styki — a nie przez mocki. To metryka zarządcza, nie inżynierska: odpowiada na pytanie „czy proces zadziała po wdrożeniu?" jedną liczbą, którą da się śledzić w czasie. Banki dziś tego nie mierzą — i dlatego nie potrafią odpowiedzieć. Czym dokładnie jest BJC i jak liczymy poziomy pokrycia, opisujemy osobno: Business Journey Coverage →
Konsekwencje: strach przed własnym wdrożeniem
Skutki są przewidywalne. Ryzyko produkcyjne rośnie z każdym releasem, bo styki — czyli nietestowane kontrakty danych — mnożą się szybciej niż jakakolwiek ręczna weryfikacja zdąży je objąć. Pojawia się strach przed wdrożeniem — paradoksalny w organizacji, która inwestowała w automatyzację właśnie po to, żeby wdrażać bezpiecznie. Incydenty koncentrują się na stykach aplikacji, w obszarze niczyim. „Działa u mnie" staje się oficjalnym statusem zamykającym dyskusję, mimo że proces dla klienta nie działa.
I pytanie, które najlepiej obnaża problem — pada na każdym przeglądzie przed releasem i pozostaje bez odpowiedzi: „czy sprzedaż kredytów na pewno zadziała po tym wdrożeniu?". Nikt nie potwierdzi, bo nikt nie ma narzędzia, mandatu ani metryki, żeby to sprawdzić na całej ścieżce. Wdrożenie staje się aktem wiary, nie decyzją opartą na danych.
Gdzie naprawdę leży ryzyko
Koszt tego martwego pola nie sprowadza się do jednej liczby — i nie chcemy udawać, że tak jest. Ryzyko koncentruje się w czterech miejscach, z których każde da się zmierzyć, gdy odzyska się widok na proces:
- Styki = nietestowane kontrakty danych. Defekt na granicy aplikacji nie ma właściciela ani czerwonego sygnału — ujawnia się dopiero na produkcji, czyli tam, gdzie naprawa jest najdroższa.
- Brak metryki procesu. Decyzja o wdrożeniu zapada bez wskaźnika, który by ją uzasadniał. Ryzyko jest realne, ale niewidoczne — bo nikt go nie liczy.
- Strach przed releasem. Niepewność spowalnia wdrożenia i podnosi koszt każdego z nich; tempo, które dał shift-left, jest zjadane przez ostrożność na końcu.
- Utrata reużycia. Brak wspólnego języka kroków oznacza, że automatyzacja E2E powstaje od zera dla każdego procesu — albo nie powstaje wcale.
Skali tego ryzyka nie zgadujemy — mierzymy ją u klienta. W 90-dniowym pilotażu ustalamy punkt wyjścia (BJC start), defekty wykrywane na stykach i czas pełnej regresji, a na końcu pokazujemy realny efekt na jednym, krytycznym procesie.
Shift-left nie jest błędem — jest niedokończony. Złapał błędy tam, gdzie powstają, wewnątrz komponentu, ale zostawił otwarte całe ryzyko na stykach, czyli dokładnie tam, gdzie błędy są najdroższe. Brakuje warstwy, która odzyska globalny widok na proces — i metryki, która ten widok wyrazi liczbą — bez likwidowania szybkości i autonomii, które shift-left dał zespołom.
Gdy AI pisze kod, jakość staje się zawodem. A jakość procesu biznesowego mierzy się na stykach — na kontraktach danych między systemami — nie wewnątrz pojedynczego komponentu.
Dobra wiadomość: nie trzeba wracać do centralnego QA jako wąskiego gardła ani odbierać zespołom ich pipeline'ów. Trzeba dołożyć cienką warstwę, która ze standaryzowanych, reużywalnych kroków składa scenariusze E2E całych procesów — wg modelu procesu i kontraktów danych — testuje styki na realnym połączeniu i daje jeden kokpit z odpowiedzią opartą na BJC. To operating model, który nazywamy SQLC. O tym, jak działa naprawdę, piszemy osobno.
Chcesz zmierzyć to ryzyko na swoim procesie, a nie zgadywać? Zobacz pilotaż 90 dni → · Poznaj metrykę, której dziś brakuje: Business Journey Coverage →