Metryki jakości, które naprawdę mają znaczenie

Na przeglądzie kwartalnym dyrektor obszaru IT pokazuje slajd: czternaście tysięcy testów automatycznych, pass rate 98,4%, pokrycie kodu 82%. Wszystko na zielono, wszystkie słupki rosną. Tydzień później wdrożenie wywraca proces sprzedaży kredytu i przez dwa dni klienci nie mogą podpisać umowy. Żadna liczba z tego slajdu nie zapowiadała problemu — bo żadna z nich nie mierzyła tego, co się właśnie wydarzyło.

Dashboard pełen zieleni, a produkcja płonie

To nie jest anegdota o złym zespole. To przewidywalny skutek tego, co zdecydowaliśmy się mierzyć. Większość dashboardów jakości w dużych organizacjach składa się z metryk, które są łatwe do policzenia — a nie z tych, które są ważne. Liczbę testów wylicza CI za darmo. Pass rate spada z raportu przebiegu. Pokrycie kodu generuje wtyczka. Wszystkie te liczby mają wspólną cechę: opisują aktywność zespołów, a nie ryzyko produktu.

W literaturze produktowej takie wskaźniki nazywa się vanity metrics — metryki próżności. Rosną, wyglądają dobrze na slajdzie i nie da się na ich podstawie podjąć żadnej decyzji. W testowaniu mają dodatkową, groźniejszą właściwość: usypiają. Zarząd, który co kwartał widzi 98% na zielono, przestaje pytać o ryzyko. A potem incydent produkcyjny spada „znikąd" — choć tak naprawdę spada z obszaru, którego żadna z raportowanych liczb nie obejmowała.

Cztery metryki, które kłamią

Liczba testów. Mierzy koszt, nie wartość. Dziesięć tysięcy testów sprawdzających gettery i settery jest wartych mniej niż dwadzieścia scenariuszy pokrywających krytyczny proces biznesowy od końca do końca. Co gorsza, ta metryka nagradza złe zachowania: skoro liczy się liczba, opłaca się produkować testy tanie i płytkie. Rosnący wykres liczby testów mówi tylko tyle, że zespół był zajęty.

Pass rate bez kontekstu. 98% zielonych testów brzmi świetnie — dopóki nie zapytamy, co te testy sprawdzają i na czym przechodzą. Sto procent pass rate na mockach oznacza tylko tyle, że każdy zespół potwierdził własne wyobrażenie o sąsiednich systemach. Kontrakty danych między aplikacjami — czyli miejsca, w których procesy pękają najczęściej — pozostają nietknięte. Dlaczego zielone CI w każdym zespole nie składa się na działający proces, opisaliśmy szczegółowo w schemacie problemu. Pass rate mierzony bez informacji o zakresie to licznik bez mianownika.

Pokrycie kodu mylone z pokryciem procesu. To chyba najczęstsze nieporozumienie na styku IT i biznesu. 82% pokrycia kodu znaczy, że 82% linii zostało wykonanych podczas testów — w izolacji, komponent po komponencie. Nie znaczy, że 82% procesów biznesowych zadziała. Proces sprzedaży kredytu — sprzedaż → uruchomienie → spłata → zamknięcie — może mieć zero pokrycia end-to-end w organizacji, w której każde z czterech repozytoriów raportuje pokrycie kodu powyżej 80%. To dwie różne miary dwóch różnych rzeczy i tylko jedna z nich odpowiada na pytanie zarządu.

Wykonane testy manualne jako miara postępu. „Wykonaliśmy 340 z 400 przypadków testowych" wygląda jak 85% postępu. Ale które 60 zostało? Jeśli wśród nich są scenariusze krytycznych ścieżek, realny obraz ryzyka jest odwrotny do wykresu. Liczenie wykonanych przypadków bez wagi ryzyka to mierzenie przebytej drogi bez sprawdzania kierunku.

Każda z tych metryk jest technicznie poprawna. Kłamstwo nie tkwi w liczbie, tylko w sugestii, że ta liczba mówi coś o bezpieczeństwie wdrożenia.

Metryki, które niosą decyzję

Dobra metryka jakości ma jedną cechę rozpoznawczą: gdy się zmienia, ktoś powinien podjąć inną decyzję. Poniższy zestaw nie jest długi — i to celowe. Pięć wskaźników, które faktycznie zmieniają decyzje, jest wartych więcej niż pięćdziesiąt, które nikogo do niczego nie zobowiązują.

Business Journey Coverage (BJC). Odsetek krytycznych procesów biznesowych, które mają aktualną, zieloną, reużywalną automatyzację E2E przechodzącą przez realne styki systemów — nie przez mocki. To metryka zarządcza: odpowiada wprost na pytanie „czy proces zadziała po wdrożeniu?" jedną liczbą, którą można śledzić w czasie. Kluczowa jest dyscyplina licznika: scenariusz oparty na niezweryfikowanych zaślepkach albo dawno nieuruchamiany do BJC nie wchodzi, bo inaczej metryka kłamie dokładnie tak samo jak pass rate. Pełną definicję, wzór i poziomy dojrzałości opisujemy na stronie Business Journey Coverage.

Defekty wykryte na stykach aplikacji. Osobny licznik dla błędów znalezionych na integracjach i kontraktach danych między systemami. To najdroższa klasa defektów — nie ma właściciela, nie ma czerwonego sygnału w żadnym pojedynczym CI i zwykle ujawnia się dopiero u klienta. Jeśli testy E2E zaczynają je łapać przed produkcją, to najtwardszy dowód, że automatyzacja pracuje tam, gdzie ryzyko jest realne.

Czas i stabilność pełnej regresji. Ile trwa regresja krytycznych procesów i jaki odsetek czerwonych wyników to prawdziwe defekty, a jaki — flaki i nieaktualne skrypty. Regresja, która trwa trzy tygodnie albo w połowie świeci się na czerwono „bo tak ma", nie jest bramką jakości — jest rytuałem. Krótka i przewidywalna regresja to warunek wdrożeń na żądanie zamiast kwartalnych okien wydaniowych.

MTTR — średni czas przywrócenia po incydencie. Uczciwie: to metryka reaktywna, mierzy sprawność reagowania, a nie zapobieganie. Ale w sektorach regulowanych to język, którym o odporności operacyjnej mówi DORA — a szybsze wykrywanie problemów na stykach skraca MTTR w sposób mierzalny.

Odsetek wdrożeń bez incydentu. Najprostsza miara wyniku całego systemu jakości. Jeśli rośnie BJC, a odsetek czystych wdrożeń stoi w miejscu — coś jest nie tak z licznikiem BJC albo z listą procesów uznanych za krytyczne. Te dwie liczby czytane razem weryfikują się nawzajem.

Jedna zasada: pytanie decydenta, nie aktywność zespołu

Wszystkie powyższe wskaźniki łączy jedna reguła, którą warto przyłożyć do każdej metryki na własnym dashboardzie: metryka ma odpowiadać na pytanie, które zadaje decydent — nie opisywać, czym zajmował się zespół.

Decydent przed wdrożeniem pyta: „czy możemy bezpiecznie wydać?". Liczba testów na to pytanie nie odpowiada. Pass rate nie odpowiada. Pokrycie kodu nie odpowiada. BJC, defekty na stykach i stabilność regresji — odpowiadają, bo mierzą stan procesu, za który klient płaci, a nie stan repozytoriów, o których klient nie wie. Test tej zasady jest prosty: jeśli metryka może rosnąć kwartał po kwartale, a ryzyko wdrożenia się nie zmienia, to nie jest metryka jakości. To metryka zajętości.

Jak raportować, żeby raport był czytany

Jedno źródło prawdy. Jeżeli wyniki testów żyją w pięciu narzędziach i siedmiu arkuszach, każdy przegląd zaczyna się od uzgadniania liczb zamiast od decyzji. W naszym stacku tę rolę pełni Smart.Kokpit — agreguje wyniki testów z wielu technologii i zespołów w jeden obraz, niezależnie od tego, w czym poszczególne zespoły automatyzują. Nie chodzi o konkretne narzędzie, tylko o zasadę: liczby, o których się dyskutuje, muszą pochodzić z jednego, automatycznie zasilanego miejsca. Jak to działa u nas, pokazujemy na stronie produktów STS.

Trend zamiast snapshotu. Pojedyncza wartość BJC mówi niewiele — 40% może być świetne (jeśli kwartał temu było 15%) albo alarmujące (jeśli spadło z 60%). Raportujcie kierunek i tempo zmiany, nie stan. To także uczciwsze: trend trudniej „ustawić" pod jeden przegląd.

Raport operacyjny to nie raport zarządczy. Zespoły potrzebują szczegółu: które scenariusze czerwone, które kontrakty się rozjechały, gdzie flaki. Zarząd potrzebuje trzech–pięciu liczb i ich trendu. Wysyłanie obu grupom tego samego dashboardu kończy się tak, że nie czyta go nikt: dla jednych za płytki, dla drugich nieczytelny. To dwa różne dokumenty z tego samego źródła danych — i tak trzeba je projektować.

Na koniec uczciwe zastrzeżenie: żadna metryka nie jest odporna na złą wolę ani na bezrefleksyjne optymalizowanie „pod wskaźnik" — BJC też można zepsuć, wpuszczając do licznika scenariusze na mockach. Różnica polega na tym, że dobre metryki psuje się trudniej, a ich definicje — jak reguły licznika BJC — da się audytować. Dashboard nie zastąpi rozmowy o ryzyku. Może ją tylko oprzeć na faktach zamiast na przeczuciach — i dokładnie po to jest.

Jak metryki procesu wpisują się w cały operating model jakości, opisujemy w manifeście SQLC.