Co dokładnie mierzymy
Business Journey Coverage to udział krytycznych ścieżek biznesowych, które mają aktualną, zieloną i reużywalną automatyzację end-to-end — uruchamianą przez realne styki systemów, a nie przez zaślepki. To nie jest „pokrycie kodu". To pokrycie procesu.
„Zielone i aktualne" znaczy: scenariusz przeszedł w ostatnim oknie regresji oraz odpowiada bieżącej wersji procesu i kontraktów danych. Test, który nie był uruchomiony albo testuje nieaktualną ścieżkę, do licznika nie wchodzi.
Krytyczne procesy
Mianownik to nie „wszystkie testy", tylko ścieżki, na których stoi biznes — np. cykl kredytu: sprzedaż → uruchomienie → spłata → zamknięcie. Listę ustala biznes, nie zespół testowy.
Przez realne styki
Liczy się tylko automatyzacja przechodząca przez faktyczne integracje i kontrakty danych między systemami. Scenariusz oparty na mockach potwierdza, że kod działa „u siebie" — nie że proces przejdzie przez styki.
Aktualna i reużywalna
Scenariusz musi być zbudowany ze wspólnych kroków i nadążać za zmianą procesu. Jednorazowy skrypt, którego nikt nie utrzymuje, nie podnosi BJC — bo za tydzień będzie czerwony albo nieaktualny.
To metryka zarządcza, nie inżynierska
Pokrycie testami jednostkowymi, liczba przypadków, „zielony build" — to wskaźniki techniczne. Żaden z nich nie odpowiada na pytanie, które zadaje zarząd i regulator: czy ten proces zadziała po wdrożeniu, od początku do końca?
Odpowiada na jedno pytanie
„Czy proces zadziała po wdrożeniu?" — to samo pytanie, na którym pęka zdecentralizowany shift-left. BJC zamienia je z przeczucia na liczbę.
Jeden wskaźnik dla zarządu
Zarząd nie czyta raportów z przebiegów testów. Czyta trend: ile krytycznych procesów jest realnie pokrytych dzisiaj — i czy ta liczba rośnie.
Język ryzyka i DORA
Niskie BJC na krytycznym procesie to udokumentowana luka w testowaniu odporności operacyjnej — wprost do rozmowy o ryzyku ICT, nie do backlogu QA.
Kto definiuje metrykę, kontroluje rozmowę
Dziś banki tego nie mierzą. Wprowadzając BJC, zmieniamy temat z „ile macie testów" na „które procesy są realnie zabezpieczone".
Liczymy przez realne styki, nie przez mocki
Wartość BJC zależy od tego, co wpuszczamy do licznika. Trzymamy tu twarde reguły — inaczej metryka kłamie i usypia czujność.
✓ Wchodzi do licznika
- Scenariusz E2E przechodzący przez realne integracje i kontrakty danych między systemami.
- Service virtualization tam, gdzie realny system jest niedostępny — ale zwalidowana contract testingiem względem prawdziwego kontraktu.
- Scenariusz uruchomiony w ostatnim oknie regresji i zakończony zielono.
- Scenariusz aktualny wobec bieżącej wersji procesu (model journey + kontrakty).
✗ Nie liczy się
- Ścieżka oparta na mockach na stykach, których nikt nie weryfikuje względem realnego kontraktu — to właśnie tam proces pęka.
- Test, który dawno nie był uruchomiony — „zielony" rok temu nie znaczy zielony dziś.
- Scenariusz testujący nieaktualną wersję procesu po zmianie kroków lub kontraktu.
- Zielony przebieg, który sprawdza złą rzecz — dlatego trzymamy governance: provenance, zatwierdzenie, human-in-the-loop.
Skąd biorą się dane do liczenia
Mianownik (lista krytycznych procesów) ustala biznes i model journey. Licznik wyliczamy automatycznie z wyników regresji E2E i statusu kontraktów na stykach, a pętla z produkcji (observability — np. Dynatrace) podpowiada, które journeys są dziś najbardziej ryzykowne i wymagają priorytetu. BJC nie jest deklaracją — to wartość wyliczana z faktów.
Metryki wspierające
BJC to wskaźnik nadrzędny. Pod nim trzymamy pięć metryk, które pokazują, dlaczego BJC rośnie lub spada — i mapują się wprost na obszary DORA.
% błędów łapanych przed E2E
Im więcej błędów łapie shift-left wcześnie, tym tańsza i bardziej przewidywalna jest pełna regresja E2E na końcu.
Defekty na stykach aplikacji
Liczba błędów wykrytych na integracjach — bezpośredni sygnał ryzyka z miejsc, w których proces pęka najczęściej.
Czas pełnej regresji
Ile trwa zielona regresja E2E krytycznych procesów. Krótki czas = wdrożenia na żądanie zamiast okien wydaniowych.
MTTR
Średni czas przywrócenia po incydencie. Szybsze wykrycie na stykach skraca MTTR i zasila raportowanie incydentów (DORA).
Lead time wdrożenia
Od gotowego kodu do produkcji. Przewidywalna regresja E2E skraca lead time, bo wdrożenie przestaje być wydarzeniem wysokiego ryzyka.
Razem dają trend
Pojedyncza liczba bywa myląca. Dopiero BJC plus te pięć metryk pokazuje, czy jakość procesu realnie rośnie — i to weryfikujemy w pilotażu.
Co oznaczają progi BJC
Poniższe progi to definicja poziomów metryki, nie obietnica wyniku. Pokazują, jak czytać wartość BJC dla portfela krytycznych procesów. Realny wynik u klienta mierzymy w pilotażu.
Większość krytycznych procesów nie ma aktualnego, zielonego E2E przez realne styki. Pewność wdrożenia opiera się na przeczuciu i testach ręcznych. To punkt wyjścia, w którym banki zwykle są dziś, choć tego nie mierzą.
Część procesów ma E2E, ale pokrycie jest wyspowe i trudne w utrzymaniu. Styki bywają na mockach. Regresja całości wciąż jest długa i ryzykowna.
Większość krytycznych procesów ma reużywalne E2E przez realne styki. Regresja staje się przewidywalna, a BJC zaczyna pełnić rolę realnej bramki przed wdrożeniem.
Niemal wszystkie krytyczne procesy mają aktualne, zielone E2E. Pełna regresja jest krótka i w większości zielona, a wdrożenia mogą iść bezpiecznie wtedy, kiedy potrzebuje ich biznes.
Liczy się nie sama wartość, lecz trend i jakość licznika. Dla ilustracji: wysokie BJC zbudowane na mockach jest mniej warte niż niższe BJC przez realne styki — bo tylko to drugie naprawdę odpowiada na pytanie „czy proces zadziała po wdrożeniu?".
Od martwego pola do wdrożeń na żądanie
BJC nie rośnie od dokładania kolejnych skryptów. Rośnie, gdy działa operating model: wspólne kroki, model procesu z kontraktami, kompozycja E2E przez AI i continuous testing.
Wspólne kroki + model procesu
Standardowe kroki BDD i model journey z kontraktami danych — to tu jest IP. Bez tego kompozycja E2E to tylko sklejanie Gherkina.
AI składa E2E wg modelu
AI komponuje scenariusze z reużywalnych kroków zgodnie z modelem procesu — a contract testing zabezpiecza styki, na których proces pęka.
Continuous testing + pętla
Risk-based selection, dane testowe spójne między systemami, środowiska — i pętla z produkcji, która pilnuje, by licznik pozostawał aktualny.
Zobacz, jak podnosimy BJC w praktyce
Mechanika rozwiązania i to, co działa „pod maską" — model procesu, kontrakty, governance AI-testów i środowiska.
Zmierz swoje BJC w pilotażu 90 dni
Bierzemy jedną krytyczną ścieżkę — np. cykl kredytu — i mierzymy BJC na starcie i na końcu, wraz z metrykami wspierającymi. Bez obietnic liczbowych z góry: pokazujemy realny wynik na Twoich procesach.