Seria: QA Leadership · Artykuł 5 z 9
Przegląd kwartalny. Na slajdzie - piękne liczby. Escaped Rate: 1,8%. Trend malejący przez trzy kwartały. Wszyscy zadowoleni. Aż ktoś zapytał: „A który konkretnie release był problemem w Q3?"
PM„Dobry wynik. Ale pamiętam, że w sierpniu był ten incydent z modułem płatności - to był nasz release?"
QAotwiera tabelę per release...
QA„v3.4 - 7 escaped bugów. Pozostałe 7 releasów łącznie: 4."
PM„Czyli jeden release odpowiadał za 64% wszystkich problemów kwartału. I w raporcie nie było o tym ani słowa."
Ogólny Escaped Rate nie kłamie. Po prostu ukrywa. Jeden katastrofalny release rozmywa się w średniej z pozostałych siedmiu. I właśnie dlatego potrzebujesz Escaped Bugs per Release - metryki, która patrzy na każdy release osobno.
Escaped Rate vs Escaped per Release - co każdy z nich widzi
To nie są dwie wersje tej samej metryki. To dwa zupełnie różne poziomy widzenia. I potrzebujesz obu - ale z pełną świadomością, co każdy z nich mówi, a czego nie.
Ogólny Escaped Rate
Rate = Escaped łącznie ÷ (Escaped + Pre-release) × 100%
Mówi: jak skuteczni jesteśmy ogółem
Trend kwartalny, punkt odniesienia branżowy, argument dla zarządu. Dobry do raportowania na wysokim poziomie i porównywania kwartałów.
⚠️ Nie pokazuje, które releasey były ryzykowne. Jeden skok gubi się w średniej.
Escaped per Release
EpR = Escaped bugs przypisane do konkretnego release'u
Mówi: który release był ryzykowny
Diagnoza incydentów, szukanie wzorców, rozmowa z EM o przyczynach. Dobry do identyfikacji problemów i działań prewencyjnych.
✓ Każdy release dostaje własną ocenę. Skok jest widoczny natychmiast.
Ten sam kwartał - dwie zupełnie różne diagnozy
Poniższa tabela pokazuje, jak agregacja ukrywa realny obraz. Ogólny Escaped Rate: 1,8% - wygląda dobrze. Ale po rozbiciu na releasey pojawia się zupełnie inna historia.
| Release | Escaped bugs | EpR | Ocena |
|---|
| v3.1 | 0 | 0.0 | Elitarny |
| v3.2 | 1 | 0.2 | Elitarny |
| v3.3 | 0 | 0.0 | Elitarny |
| v3.4 SKOK | 7 | 2.8 | Alarm |
| v3.5 | 1 | 0.3 | Dobry |
| v3.6 | 0 | 0.0 | Elitarny |
| v3.7 | 1 | 0.2 | Elitarny |
| v3.8 | 1 | 0.3 | Dobry |
| Q3 łącznie | 11 | 1.4 śr. | Ukryta katastrofa |
Ogólny Rate dla całego kwartału: 1,8% - „wygląda dobrze”. A jeden release odpowiadał za 64% problemów.
Ile to jest za dużo - progi
EpR to bliski kuzyn najbardziej rozpoznawalnej metryki stabilności w branży - Change Failure Rate z badań DORA. CFR pyta: jaki procent wdrożeń powoduje problemy na produkcji? EpR pyta: ile konkretnie problemów przyniosło każde wdrożenie? Release z co najmniej jednym escaped bugiem to w nomenklaturze DORA „failed change”.
Warto znać aktualny kontekst: raport DORA 2025 odszedł od klasycznych poziomów Elite/High/Medium/Low na rzecz siedmiu archetypów zespołów, a poprzeczka dla najwyższej wydajności została zaostrzona - najlepsze zespoły utrzymują CFR w przedziale 0-2%, co osiąga tylko ok. 17% organizacji. Określenie „elite” wciąż funkcjonuje w branży jako skrót myślowy - i tak go używam poniżej - ale miej świadomość, że formalnie DORA mówi dziś innym językiem.
Progi dla Escaped Bugs per Release, skalibrowane do tych standardów:
<0.5
Elitarny
Najwyższa wydajność. Zdecydowana większość releasów bez escaped bugs. Sporadyczne pojedyncze incydenty.
0.5-1.5
Dobry
Dojrzały proces. Pojedynczy escaped bug od czasu do czasu, szybko wykryty i naprawiony. Brak wzorca powtarzalności.
1.5-3.0
Wymaga uwagi
Widoczne problemy procesowe. Klient regularnie odczuwa skutki. Potrzebna analiza przyczyn.
>3.0
Sygnał alarmowy
Każdy taki release to incydent wymagający post-mortem. Natychmiastowa interwencja procesowa.
Dla zespołów w środowisku korporacyjnym z regularnymi releasami co 1-2 tygodnie - cel to poniżej 0.5 escaped buga per release. Powyżej 1.5 to sygnał, że coś systemowo nie działa.
Skok, który widać od razu
Wykres Escaped per Release natychmiast ujawnia to, co ogólna statystyka ukrywa. Jeden rzut oka - i wiesz, który release wymaga śledztwa.
Escaped Bugs per Release - widok per release
v3.4 widoczny natychmiast. Ogólna średnia: 1.4 - wyglądałaby niewinnie.
Skok: v3.4 = 2.8
Escaped per Release
Próg elitarny (<0.5)
Próg alarmu (3.0)
Escaped per Release vs ogólny Escaped Rate - ta sama historia
Rate agreguje i wygładza. EpR ujawnia anomalie. Potrzebujesz obu perspektyw.
dwie perspektywy
Escaped per Release (szt.)
Ogólny Escaped Rate (%)
Framework śledztwa
5 pytań, które zadajesz po każdym skoku
Skok sam w sobie nie jest problemem - jest sygnałem. Prawdziwy problem zaczyna się wtedy, gdy skok zostaje odnotowany jako „anomalia" i nikt nie szuka przyczyny. Oto pięć pytań, które zawsze prowadzą do odpowiedzi.
Trzy zasady zanim zaczniesz, zaczerpnięte wprost z kultury SRE. Po pierwsze - śledztwo prowadzimy bez szukania winnych (blameless). Pytamy „jak system pozwolił na ten błąd?", nigdy „kto zawinił?". Zespół, który boi się obwinienia, przestaje mówić prawdę - a bez prawdy nie ma diagnozy. Po drugie - szukamy czynników współtworzących, nie pojedynczej przyczyny źródłowej. Złożone systemy zawodzą przez kilka współdziałających warunków naraz; „jedna przyczyna" to prawie zawsze uproszczenie, które gubi resztę obrazu. Po trzecie - śledztwo przeprowadzamy w ciągu 48 godzin od wykrycia skoku, póki kontekst jest świeży w głowach zespołu.
1
Co było inne w tym releasie względem poprzednich?
Skok rzadko jest przypadkowy. Coś się zmieniło - w kodzie, w procesie, w zespole lub w środowisku. Pierwsze pytanie to zawsze: co było inne?
Nowy moduł lub technologiaZmiana składu zespołuZmiana harmonogramuZewnętrzna integracja
2
Jaki typ bugów dominował - funkcjonalne, konfiguracyjne, integracyjne?
Rozkład typów (z artykułu 3) wskazuje, gdzie szukać przyczyny. Dominacja bugów konfiguracyjnych sugeruje problem środowiskowy, nie jakość kodu.
Kod → proces wytwórczyKonfiguracja → DevOpsIntegracja → architekturaRegresja → testy
3
Czy QA miało wystarczający czas i dostęp do środowiska?
Skok pod presją terminu to nie jest przypadek. Jeśli okno testowe skróciło się o 40% - i 40% więcej bugów wyszło na produkcję - to jest prosta korelacja, którą warto pokazać PM.
Czas testowania vs poprzedni releaseStabilność środowiska testowegoDostępność środowiska stagingOpóźnienia w dostarczeniu kodu
4
Czy bugi były w obszarach pokrytych testami automatycznymi?
Jeśli escaped bugi były w modułach z 90% pokryciem automatycznym - problem leży w jakości testów, nie ich liczbie. Jeśli w obszarach bez pokrycia - to jest sygnał do uzupełnienia.
Mapa pokrycia vs lokalizacja bugówOstatnia aktualizacja testów dla tego modułuNiestabilne testy w tym obszarze
5
Czy widziałeś już podobny skok - i co wtedy pomogło?
Historia EpR to Twój największy zasób. Jeśli skok w v2.8 miał ten sam profil co skok w v3.4 - i wtedy rozwiązał go punkt kontrolny code review - to masz gotowe działanie naprawcze.
Poprzednie skoki w historii EpRCo zrobiono po poprzednim skokuCzy działanie naprawcze zostało utrzymane
Interaktywny detektor skoków
Wpisz wartości Escaped per Release ze swoich ostatnich 6 releasów. Detektor automatycznie oznaczy skoki i podpowie, który release wymaga śledztwa.
Detektor skoków EpR
Wpisz liczbę escaped bugów per release - próg skoku wyznaczany metodą IQR (Tukey): Q3 + 1,5 × IQR
Od diagnozy do zapobiegania - jak używać skoków
Skok zidentyfikowany i zbadany to połowa sukcesu. Druga połowa to zamiana wniosków w działania, które sprawią, że historia się nie powtórzy.
Jak wdrożyć od zera
1
Zbierz historyczne EpR - minimum 6 ostatnich releasów
Przypisz każdy escaped bug (z Jiry, monitoringu, wsparcia) do konkretnego release'u, który go wprowadził - nie do daty wykrycia. To kluczowa różnica. Bug wykryty w tygodniu 3 po releasie wciąż należy do tego release'u.
Nawet przybliżone dane za 2-3 miesiące wstecz dają Ci pierwszy trend i identyfikują historyczne skoki.
2
Wyznacz próg skoku metodą IQR - standardem statystycznym
Branżowy standard wykrywania wartości odstających to metoda Tukeya oparta na rozstępie międzykwartylowym: próg = Q3 + 1,5 × IQR, gdzie Q3 to 75. percentyl, a IQR to różnica między 75. a 25. percentylem Twoich danych EpR. Metoda jest odporna na wpływ samych skoków - w przeciwieństwie do progów opartych na średniej, którą pojedynczy skok potrafi mocno zawyżyć.
Przy małej liczbie releasów (mniej niż 8-10 punktów danych) wynik traktuj orientacyjnie - i aktualizuj próg co kwartał, bo gdy zespół dojrzewa, rozkład się zacieśnia i próg staje się bardziej wymagający.
3
Wprowadź post-mortem bez szukania winnych dla każdego skoku - 30 minut, w ciągu 48h
Nie musi być wielogodzinnym spotkaniem. 30-minutowa retrospektywa z 5 pytaniami z frameworku powyżej - przeprowadzona w ciągu 48 godzin od wykrycia, póki kontekst jest świeży. Zasada nadrzędna: blameless - analizujemy system i proces, nie ludzi. Jeśli potrzebujesz głębszej techniki dochodzenia do przyczyn, klasyczne Five Whys (pytaj „dlaczego", aż dojdziesz do przyczyny systemowej) działa świetnie w tym formacie.
Wynik post-mortem to lista czynników współtworzących plus działania - każde z właścicielem i terminem. Dokument trafia do archiwum zespołu: gdy pojawi się następny skok, zaczynasz od sprawdzenia, czy profil przyczyn jest znany.
4
Oznaczaj releasey „wysokiego ryzyka" z wyprzedzeniem
Po kilku miesiącach danych zaczniesz widzieć wzorce: nowe technologie → ryzyko wyższe. Wdrażanie nowego programisty → ryzyko wyższe. Presja terminu → ryzyko wyższe. Użyj tych wzorców do pre-mortem przed releasem - nie czekaj na skok, żeby zareagować.
Cztery działania prewencyjne - kiedy je stosować
🔍
Pre-mortem przed ryzykownym releasem
Zadaj pytanie: „Co może pójść źle?" przed wdrożeniem, nie po. Szczególnie dla releasów z nowymi integracjami lub zmianami architektury.
Kiedy: przed każdym „dużym" releasem
📋
Lista kontrolna ryzyka release'u
Prosta lista pytań do wypełnienia przed każdym releasem: nowy programista? nowa integracja? skrócone okno testowe? Każde „tak" podnosi kategorię ryzyka.
Kiedy: przy każdym releasie, 5 minut
🐤
Wdrożenie kanarkowe dla wysokiego ryzyka
Releasuj na 5-10% ruchu przed pełnym wdrożeniem. EpR dla tego okna to wczesny sygnał - możesz wycofać, zanim problem dotknie wszystkich klientów.
Kiedy: EpR historycznie > 1.5 dla podobnych releasów
⏱️
Okno monitoringu po wdrożeniu
Pierwsze 2 godziny po wdrożeniu - aktywny monitoring z niższymi progami alertów. Duża część skoków EpR jest wykrywana właśnie w tym oknie.
Kiedy: zawsze, automatycznie
EpR w rozmowie z biznesem
Sprint Review
„Ten release zakończył się 0 escaped bugów - EpR na poziomie elitarnym. Poprzedni v3.4 był skokiem z EpR 2.8. Przeprowadziliśmy post-mortem i wdrożyliśmy punkt kontrolny code review. Wynik widoczny już w tym releasie."
1:1 z EM
„Ogólny Escaped Rate wygląda dobrze - 1.8%. Ale per release widać, że jeden release odpowiadał za 64% problemów kwartału. Mam hipotezę na temat przyczyny i propozycję działania naprawczego."
Zarząd
„Wprowadziliśmy monitoring EpR per release. W Q4 zidentyfikowaliśmy dwa skoki, przeprowadziliśmy post-mortem dla obu i wdrożyliśmy działania naprawcze. Średnia EpR spadła z 1.4 do 0.4 - poziom elitarny. Wszystkie releasey Q4 poniżej progu 0.5."
Co daje EpR, czego nie ma w ogólnym Rate
✓ EpR daje Ci
- Identyfikację konkretnego ryzykownego release'u - nie uśrednioną statystykę
- Punkt wyjścia do śledztwa przyczynowego (5 pytań)
- Wzorce historyczne do przewidywania ryzykownych releasów
- Mierzalny efekt działań naprawczych per release
- Argument w rozmowie z PM o czasie i warunkach testowania
✗ EpR nie zastępuje
- Ogólnego Escaped Rate - do trendu kwartalnego i porównań branżowych
- DDR - do oceny skuteczności procesu testowania
- Issues per Release - do oceny dojrzałości kodu wchodzącego do testów
- Number of Releases - bez kontekstu liczby releasów EpR traci skalę
Skok to nie jest problem - to jest sygnał. Problem zaczyna się wtedy, gdy skok zostaje odnotowany jako „anomalia" i nikt nie szuka przyczyny. EpR daje Ci narzędzie, żeby to zmienić.
W następnym artykule
Artykuł szósty dotyczy Number of Releases - metryki, którą większość zespołów całkowicie ignoruje. A bez niej wszystkie pozostałe metryki tej serii tracą skalę i porównywalność.
Dowiesz się, dlaczego 3 escaped bugi przy 2 releasach to kryzys, a 3 escaped bugi przy 15 releasach to sukces - i jak używać tej metryki jako wspólnego mianownika dla całej serii.
Seria: Metryki QA, które biznes chce słyszeć
- 01
Diagnoza, trzy filary, pięć metryk, model mapowania QA → KPI
- 02
Formuła, progi, dane historyczne, sezonowość, pułapki
- 03
Taksonomia, zbieranie danych, koszt każdego typu, jak raportować
- 04
Wdrożenie od zera, związek z procesem wytwórczym, rozmowa z EM
- 05
Escaped Bugs per Release czytasz teraz
Wykrywanie skoków, framework śledztwa, działania prewencyjne
- 06
Number of Releases - metryka kontekstowa
Dlaczego 3 bugi przy 2 releasach to dramat, a przy 15 to sukces
- 07
Release Confidence Score krok po kroku
Trzy modele obliczania, wdrożenie, przykłady z praktyki
- 08
Storytelling z metrykami - jak budować narrację
Jak zamienić tabelę liczb w argument biznesowy
- 09
3 antywzorce, które niszczą wiarygodność QA
Za dużo metryk, brak kontekstu, żargon - i jak unikać