Trzy metryki jakości, które CFO rozumie bez tłumacza

Źródło: opracowanie własne Quality Island, przeliczenie 200 słów na minutę.

Koniec kwartału, sala konferencyjna, Wy z raportem z testów, po drugiej stronie dyrektor finansowy z arkuszem. Pokazujecie pokrycie testami i liczbę wykonanych przypadków, a w odpowiedzi pada pytanie o pieniądze i termin. To nie jest spór o kompetencje, tylko różnica języków. Ten artykuł da Wam trzy metryki, które przekładają pracę Waszego zespołu QA na język rachunku wyników: defekty, które uciekły na produkcję, czas regresji i koszt jednego wydania. Każdą z nich policzycie w 30 dni z danych, które już u Was są.

Dlaczego raport z testów nie przekonuje zarządu

Jeśli po prezentacji budżetowej czujecie, że mówiliście do ściany, to prawdopodobnie nie Wasza wina. Wasz raport z testów odpowiada na pytanie, czy produkt działa. Zarząd pyta o co innego: ile kosztuje to, że nie działa, i kiedy zacznie zarabiać. Według raportu State of Testing 2024 od PractiTest 50 procent organizacji w ogóle nie mierzy kosztu defektów, które przedostają się na produkcję. Połowa firm negocjuje więc budżet jakości bez najważniejszej liczby na stole.

Z tego samego badania PractiTest z 2024 roku wynika, czym organizacje takie jak Wasza zastępują pieniądze: połowa mierzy wpływ testowania pokryciem testami i wykonaniem testów, efektywnością testów oraz wskaźnikiem NPS. Wszystkie te miary są uczciwe, ale żadna nie mówi dyrektorowi finansowemu, co się dzieje z rachunkiem wyników. Skala problemu wygląda tak:

Zanim weźmiecie się za liczenie, posłuchajcie, jak Wasze obecne metryki brzmią po drugiej stronie stołu. Tabela niżej to zapis rozmów, które prowadziliśmy przy audytach procesów QA u klientów.

Metryka pierwsza: defekty, które przeszły do produkcji

Defekt, który uciekł na produkcję, to błąd, który ominął Wasze testy i został znaleziony po wydaniu: przez użytkownika, monitoring albo zespół utrzymania. Dane już u Was są. Wystarczy w Waszym systemie zgłoszeń oznaczyć, w którym wydaniu defekt powstał i kto go znalazł: jedno pole w narzędziu, zero nowych zakupów. Po trzech wydaniach zobaczycie trend, a trend to pierwsza rzecz, którą dyrektor finansowy naprawdę czyta.

Sama liczba defektów jeszcze nie przekonuje, przekonuje jej cena. Policzcie dla każdego Waszego defektu produkcyjnego trzy składniki: godziny ludzi na diagnozę i poprawkę, przestój albo degradację usługi oraz utracone transakcje. Skala bywa zaskakująca. Według badania ITIC Hourly Cost of Downtime z 2024 roku godzina przestoju kosztuje ponad 300 tysięcy dolarów w przeszło 90 procentach średnich i dużych przedsiębiorstw, a 41 procent badanych firm wycenia ją na od 1 miliona do ponad 5 milionów dolarów, i to bez kosztów postępowań sądowych oraz kar.

Ta metryka reaguje też najszybciej na porządki w procesie. W projekcie dla Argos, firmy e-commerce, liczba błędów krytycznych na produkcji spadła o 46 procent, a awarie w okresach szczytowych o 72 procent po automatyzacji testów i uporządkowaniu procesów QA. W tym samym projekcie dla Argos stabilny checkout i płatności przełożyły się na wzrost konwersji o 12 procent, a takie zdanie obroni Wasz budżet lepiej niż dziesięć wykresów pokrycia.

Metryka druga: czas regresji jako czas zamrożonych pieniędzy

Regresja przed wydaniem to moment, w którym Wasz kod jest gotowy, zapłaciliście za jego powstanie, a on jeszcze nie zarabia. Każdy dzień regresji to dzień zamrożonych pieniędzy: funkcje czekają, konkurencja nie, a Wasi developerzy budują kolejne zadania na niewydanym kodzie. Dla CFO to konstrukcja znajoma z logistyki: magazyn pełen towaru, którego nikt nie wysłał.

Przeliczenie jest proste: zmierzcie czas od zamrożenia kodu do zgody na wdrożenie i pomnóżcie go przez koszt dnia opóźnienia, czyli sumę dziennego kosztu zespołu czekającego na wydanie i wartości, której niewydana wersja nie dowozi Waszym klientom. Jak policzyć te składniki krok po kroku, znajdziecie w tekście o tym, ile kosztuje dzień opóźnienia wydania.

Da się to skrócić radykalnie. W projekcie dla Argos regresja przed releasem spadła z 5 dni do 10 godzin, a cały proces opisaliśmy w artykule jak skróciliśmy testy regresyjne z 5 dni do 10 godzin. Jeśli Wasza regresja trwa tydzień, dobrze zaprojektowane testy regresyjne to w naszej praktyce pierwsza rzecz, którą warto policzyć i zautomatyzować.

Czas regresji warto też osadzić w szerszym systemie pomiaru dostarczania. Zespół badawczy DORA z Google Cloud opisuje w swoim przewodniku pięć metryk: change lead time, czyli czas od zatwierdzenia zmiany w repozytorium do wdrożenia na produkcję, deployment frequency, czyli częstotliwość wdrożeń, failed deployment recovery time, czyli czas powrotu do sprawności po wdrożeniu wymagającym natychmiastowej interwencji, change fail rate, czyli udział wdrożeń wymagających takiej interwencji, oraz deployment rework rate, czyli udział wdrożeń nieplanowanych po awarii na produkcji. Regresja to często największy składnik change lead time, więc skracając ją, poprawiacie wskaźnik, który Wasz zarząd technologiczny już zna. Zanim jednak oprzecie na tych wskaźnikach system premiowy, przeczytajcie, dlaczego metryki DORA psują się w erze AI.

Koszt jednego wydania, czyli liczba, której prawie nikt nie liczy

Koszt jednego wydania to suma, której prawie nikt nie widzi w całości, bo jej składniki siedzą w różnych budżetach. Policzcie cztery rzeczy: godziny wszystkich Waszych ludzi zaangażowanych w wydanie, od developerów przez QA po DevOps, koszt środowisk testowych i narzędzi, poprawki po wydaniu oraz rollbacki z pełną obsługą. Ta liczba zwykle szokuje, ale w dobrą stronę: pokazuje, że rzadkie i nerwowe wydania wcale nie są tanie, tylko drogo udają oszczędność.

Skalę zaniedbań widać w danych makro. Według raportu CISQ z 2022 roku koszt złej jakości oprogramowania w samych Stanach Zjednoczonych wyniósł co najmniej 2,41 biliona dolarów, a skumulowany dług techniczny to około 1,52 biliona dolarów. To nie są koszty egzotycznych katastrof, to suma codziennych, niepoliczonych wydań takich jak Wasze.

Znając pełny koszt wydania, inaczej czyta się też oferty, które do Was trafiają: zależności między zakresem a ceną zebraliśmy w tekście ile kosztują testy oprogramowania, a podejście do rocznego planu znajdziecie w poradniku o tym, jak wygląda planowanie budżetu na QA na cały rok.

Tomasz Stelmach, CEO Quality Island, mówi o tym krótko: „Zarząd nie kupuje pokrycia testami. Kupuje przewidywalność: kiedy wydacie, ile to kosztuje i co się stanie, jeśli coś pójdzie nie tak. Pokażcie te trzy liczby, a rozmowa o budżecie jakości skróci się o połowę.” Z naszego doświadczenia to działa dosłownie: rozmowy budżetowe, w których na stole leżą te trzy liczby, kończą się decyzją, a nie kolejnym terminem spotkania.

Jak zacząć w 30 dni, gdy nie macie żadnych danych

Nie potrzebujecie platformy analitycznej ani pół roku. Potrzebujecie pięciu kroków i jednego wydania, żebyście mieli własny punkt odniesienia. Wasze pierwsze 30 dni może wyglądać tak, bo taki plan wdrażaliśmy u klientów przy porządkowaniu pomiaru:

Źródło: opracowanie własne Quality Island, praktyka wdrażania pomiaru jakości u klientów.

Jeśli dane są rozsiane po narzędziach i nikt nie wie, które są prawdziwe, pomaga uporządkowanie pomiaru w modelu TestOps: jedno miejsce, jedna definicja każdej metryki obowiązująca w całej Waszej firmie i koniec dyskusji o tym, czyj arkusz mówi prawdę.

Metryki, które brzmią dobrze i nic nie mówią

Czas na miary, które w raportach wyglądają świetnie, a nie mówią niczego. Pokrycie testami jako cel sam w sobie to najpopularniejszy mit: mówi, ile kodu testy dotknęły, a nie czy sprawdziły cokolwiek istotnego. Jako sygnał ostrzegawczy przy niskich wartościach bywa użyteczne, ale jako KPI do maksymalizacji psuje więcej, niż pomaga, bo Wasz zespół szybko nauczy się podbijać wynik testami bez asercji.

Podobnie liczba przypadków testowych i procent wykonania testów: mierzą aktywność, nie skutek. Liczba znalezionych błędów jako KPI testera to już aktywna szkoda, bo premiuje zgłaszanie drobiazgów zamiast zapobiegania poważnym awariom. Jeśli Wasz dashboard składa się głównie z takich miar, zajrzyjcie do tekstu o tym, jak rozpoznać dashboard jakości, który kłamie.

Z naszego doświadczenia jedyna metryka, która rośnie w każdej firmie bez wyjątku, to liczba slajdów o metrykach. Zanim dołożycie kolejny, sprawdźcie, czy któryś z obecnych odpowiada na pytanie o pieniądze.

Źródło: Capgemini, World Quality Report 2025.

Nasza perspektywa

Stanowisko Quality Island jest proste: metryki pieniężne przed technicznymi. Wskaźniki techniczne są Wam potrzebne do sterowania pracą zespołu, ale do Waszego zarządu powinny wychodzić trzy liczby z tego artykułu, zawsze z trendem i zawsze z przypisanym kosztem. Z naszych ponad 450 000 napisanych testów automatycznych widzimy, że automatyzacja zwraca się tam, gdzie ktoś najpierw policzył koszt regresji i defektów produkcyjnych, a nie tam, gdzie była celem samym w sobie.

Ten sam wzorzec działa w różnych skalach. W projekcie dla Autono, firmy z branży automotive i car rental, liczba błędów krytycznych w procesach rezerwacji spadła o 55 procent, a system pozostał stabilny przy obciążeniu większym o 120 procent w sezonie wakacyjnym. Dla PKO BP prowadziliśmy z kolei pracę u podstaw: strategię jakości oprogramowania dla całej organizacji, audyt istniejących procesów QA oraz szkolenia i warsztaty dla zespołów.

Jeśli wolicie zacząć od kompetencji zespołu, zajrzyjcie do kalendarza szkoleń Quality Island, a po rozmowy o pomiarze jakości na żywo przyjedźcie na konferencję Testing Ground. Szkoliliśmy już ponad 2 500 specjalistów i widzimy jedną prawidłowość: zespoły, które raz policzyły koszt wydania, nie wracają do raportowania samego pokrycia.

Źródło: opracowanie własne Quality Island.

Powiązane na Strefie QA

• Regresja przed releasem: ile kosztuje dzień opóźnienia wydania
• Jak mierzyć produktywność zespołu QA?
• Jak obniżyć koszty utrzymania oprogramowania dzięki lepszemu QA

Źródła:

• PractiTest, State of Testing Report, 2024. Stąd wzięliśmy dane o 50 procentach organizacji bez pomiaru kosztu defektów na produkcji oraz o miarach zastępczych.
• Capgemini, World Quality Report, 2025. Stąd pochodzą dane o wdrożeniach generatywnej AI w inżynierii jakości i wzroście produktywności o 19 procent.
• ITIC, Hourly Cost of Downtime Survey, 2024. Stąd wzięliśmy koszty godziny przestoju w średnich i dużych przedsiębiorstwach.
• CISQ, The Cost of Poor Software Quality in the US: A 2022 Report, 2022. Stąd pochodzi koszt złej jakości oprogramowania w USA i wartość skumulowanego długu technicznego.
• DORA, Google Cloud, przewodnik po metrykach dostarczania oprogramowania, 2026. Stąd wzięliśmy definicje pięciu metryk dostarczania oprogramowania.