Seria: QA Leadership · Artykuł 3 z 9
Był piątkowy wieczór. DDR zespołu wynosił 91%. Regresja przeszła pięknie. Confidence Score: 89% - GO. Release wyszedł. I czterdzieści minut później zaczęły spływać alerty.
Piątek · 18:47 · Produkcja
18:47ALERT: Timeout na połączeniach z zewnętrznym API płatności - 503 dla 34% requestów
18:51DevOps: sprawdzam logi... to nie jest nasz kod. Coś z konfiguracją SSL w nowym środowisku.
19:03QA Lead: ale to nie był bug - w testach wszystko przechodziło.
19:04PM: klient właśnie napisał. Nie może procesować transakcji od 17 minut.
19:22Wycofanie zakończone. Czas przestoju: 35 minut. Certyfikat SSL na produkcji różnił się od staging.
Następnego dnia na retrospektywie padło pytanie: „Jak to możliwe - DDR 91%, a klient nie mógł płacić przez pół godziny?”
Odpowiedź jest prosta i bolesna jednocześnie: bo DDR mierzył tylko bugi w kodzie. A problem był w konfiguracji infrastruktury. I to jest dokładnie ta luka, o której jest ten artykuł.
Klient nie rozróżnia, czy serwis padł przez buga w kodzie, zły certyfikat SSL, czy błędny feature flag. Dla niego - i dla Twojego biznesu - to wszystko jest tym samym: produkcja nie działa.
Escaped Problem - szersza definicja
W poprzednim artykule mówiliśmy o DDR - metryce skuteczności wykrywania defektów. DDR pyta: ile bugów łapiemy zanim trafią na produkcję? Ale ta definicja zakłada, że jedyne problemy to bugi w kodzie aplikacji.
Rzeczywistość jest inna. Escaped Problem to każdy problem odkryty przez klienta lub monitoring po wdrożeniu - niezależnie od źródła. Cztery kategorie, cztery zupełnie różne sposoby powstawania, cztery różne sposoby zapobiegania.
Cztery typy - jeden wspólny skutek
Zanim zaczniesz mierzyć, musisz wiedzieć, co mierzysz. Oto pełna taksonomia escaped problems z typowym udziałem procentowym w organizacjach, z którymi pracowałem.
🐛
Defekty kodu
~55% przypadków
Klasyczny bug - nieprawidłowe zachowanie aplikacji wynikające z błędu w logice programistycznej. To właśnie mierzy DDR z artykułu 2.
Błędna kalkulacja ceny po rabacie
NullPointerException przy edge case
Nieprawidłowa walidacja formularza
⚙️
Problemy infrastruktury
~20% przypadków
Środowisko produkcyjne zachowuje się inaczej niż testowe. Kod jest poprawny - ale nie działa w docelowym kontekście.
Certyfikat SSL różni się od staging
Niewystarczające zasoby serwera pod obciążeniem
Różnica wersji bibliotek między środowiskami
🔗
Awarie integracji
~15% przypadków
Zewnętrzne API, systemy trzecich stron, wewnętrzne mikroserwisy - coś, co działało w testach, nie działa na produkcji ze względu na inny kontekst wywołania.
API płatności zwraca inny format na produkcji
Timeout inny niż na staging
Brakujące uprawnienia w integracji serwisowej
↩️
Regresje po wdrożeniu
~10% przypadków
Funkcja działała przed releasem - po wdrożeniu przestała. Przyczyna: nieoczekiwana interakcja z nowymi zmianami lub zmianami w konfiguracji.
Feature flag nadpisał ustawienia produkcyjne
Cache nie został wyczyszczony po wdrożeniu
Migracja bazy danych zmieniła zachowanie starych rekordów
Suma nie daje 100% - bo kilka procent to sytuacje mieszane, trudne do jednoznacznej klasyfikacji. Proporcje będą różne w Twojej organizacji - ale sama taksonomia jest niemal uniwersalna.
Kod vs infra vs integracja - kluczowe różnice
Każdy typ escaped problem ma inne źródło, inny sygnał ostrzegawczy i inną metodę zapobiegania. Tabela poniżej to Twoja mapa nawigacyjna.
| Typ |
Kto odpowiada |
Gdzie szukać sygnałów |
Jak zapobiegać |
| Kod |
Dev + QA |
Jira, testy automatyczne, code review |
Pokrycie testami, DDR, definicja ukończenia |
| Infra |
DevOps + QA |
Monitoring, diff środowisk, przegląd IaC |
Spójność środowisk, testy infrastructure as code |
| Integracje |
Dev + QA + dostawca |
Logi API, testy kontraktowe, alerting |
Testy kontraktowe, mockowanie danymi zbliżonymi do produkcji |
| Regresje |
QA + DevOps |
Monitoring po wdrożeniu, smoke testy |
Smoke suite po wdrożeniu, canary deployments |
Rozkład typów escaped problems - przykładowy rok
Kod dominuje, ale infra i integracje to łącznie ~35% problemów, często pomijanych w raportach
Q1-Q4
Jak zbierać i kategoryzować - praktyczny przewodnik
Większość zespołów zbiera tylko bugi z Jiry. To jak mierzenie temperatury w jednym pokoju i twierdzenie, że znasz klimat całego budynku. Oto co dodać i jak to połączyć.
Źródła danych
🗂️
Jira / tracker
Defekty kodu zgłaszane przez QA i devów. Pole „środowisko" lub tag „production" pozwala odfiltrować escaped.
obowiązkowe
📡
Monitoring alertów
PagerDuty, Datadog, Grafana. Incydenty produkcyjne z timestampem - źródło infra i integracji.
obowiązkowe
🎧
Zgłoszenia supportu
Freshdesk, Zendesk. Problemy zgłoszone przez klientów, które nigdy nie trafią do Jiry jako bug.
ważne
🔖
Logi po wdrożeniu
Pierwsze 30 minut po wdrożeniu to okno regresji. Splunk, ELK, CloudWatch - logi z tego okna.
ważne
💬
Slack / Teams
Kanał #incidents lub #prod-issues. Tu często lądują problemy zanim ktoś je zaloguje oficjalnie.
uzupełnienie
Proces kategoryzacji - krok po kroku
1
Zbierz wszystkie zdarzenia produkcyjne z tygodnia / sprintu
Jeden log - niezależnie od źródła. Data, krótki opis, czas przestoju lub wpływ na użytkowników. Na tym etapie nie kategoryzujesz - tylko zbierasz.
2
Przypisz typ do każdego zdarzenia
Kod / infra / integracja / regresja. Jedno zdarzenie - jeden typ. Jeśli nie jesteś pewny - wybierz najbardziej prawdopodobny i zaznacz jako „do weryfikacji".
3
Przypisz do release'u
Które wdrożenie sprowadziło problem? Czasem to oczywiste - incydent 30 minut po wdrożeniu. Czasem trzeba spojrzeć na historię zmian. Bez tego kroku stracisz możliwość łączenia escaped problems z konkretnymi releasami (metryka z artykułu 5).
4
Oblicz koszt i zaloguj czas rozwiązania
Czas wykrycia, czas naprawy, kto był zaangażowany. Nawet przybliżenie (DevOps ~3h, Dev ~1h) wystarczy - szczegóły kosztu omawiamy w następnej sekcji.
Lista kontrolna wdrożenia
Sprawdź, które źródła danych masz już podłączone w swoim zespole.
Jira - pole „środowisko" lub tag „production" skonfigurowany
Pozwala filtrować bugi znalezione na produkcji z dokładnością do release'u.
Alerty z monitoringu trafiają do jednego miejsca (Slack / PagerDuty)
Każdy alert produkcyjny powinien zostawiać ślad możliwy do późniejszej analizy.
Zgłoszenia supportu linkowane z Jirą lub logowane osobno
Bez tego tracisz problemy, które klient zgłasza bezpośrednio - często najpoważniejsze.
Historia wdrożeń z dokładnymi datami i godzinami
Niezbędna do przypisania incydentów do konkretnych releasów.
Smoke testy uruchamiane automatycznie po każdym wdrożeniu
Wyłapują regresje w pierwszych minutach - zanim dotrą do klienta.
Tygodniowy przegląd incydentów z klasyfikacją typów
15-minutowy rytuał, który przekształca surowe dane w kategoryzowaną historię.
Koszt
Ile kosztuje każdy typ escaped problem?
Każdy typ escaped problem ma inny profil kosztowy - inny czas wykrycia, inny czas naprawy, innych ludzi angażuje. Poniżej szacunki oparte na medianie z typowych organizacji enterprise. Twoje liczby będą inne - ale proporcje są zaskakująco spójne.
Kod
Defekt kodu aplikacji
Dev: 2-3h analiza + fix
QA: 1h weryfikacja
DevOps: 1h hotfix deploy
PM: 0.5h koordynacja
Najczęstszy typ. Dobrze zdefiniowany proces naprawy. Niższy koszt eskalacji.
5-6h
na incydent
ryzyko: średnie
Infra
Problem infrastruktury / konfiguracji
DevOps: 3-5h diagnoza + fix
Dev: 1h wsparcie
QA: 1h weryfikacja środowisk
PM: 1h + komunikacja z klientem
Często: wycofanie całego release'u
Trudniejszy do zdiagnozowania. Często wymaga wycofania - nie tylko poprawki.
8-12h
na incydent
ryzyko: wysokie
Integracja
Awaria integracji zewnętrznej
Dev: 2-4h diagnoza + obejście
DevOps: 2h konfiguracja
PM: 2-3h komunikacja z dostawcą
Często: naruszenie SLA u zewnętrznego dostawcy
Część problemu po stronie dostawcy. Czas rozwiązania zależy od zewnętrznego SLA.
8-16h
na incydent
ryzyko: krytyczne
Regresja
Regresja po wdrożeniu
QA: 2h identyfikacja zakresu
Dev: 2-3h analiza interakcji
DevOps: 2h wycofanie lub hotfix
Często: wpływ na wiele funkcji jednocześnie
Podstępna - bo „poprzednia wersja działała". Wymaga głębszej analizy przyczyn.
7-10h
na incydent
ryzyko: wysokie
Średni koszt wszystkich typów
~8h
na jeden escaped problem
Najdroższy typ
Integracja
8-16h + zewnętrzne SLA
Najczęstszy typ
Kod
~55% wszystkich przypadków
Dane, które mówią więcej niż jeden licznik
Zamiast jednej liczby „escaped bugs = 12” - dwa wykresy, które dają zupełnie inny poziom wglądu w to, co się naprawdę dzieje.
Escaped problems według typów - trend kwartalny
Kod maleje szybciej - bo jest lepiej testowany. Infra i integracje utrzymują się - wymagają innych działań.
Q1-Q4 2025
Kod
Infra
Integracje
Regresje
Koszt według typów - Q4 2025
Integracje to tylko 15% przypadków - ale pochłaniają nieproporcjonalnie więcej czasu i budżetu
godziny robocze
Jak to prezentować biznesowi
Sama liczba escaped problems przestaje wystarczać, gdy masz rozkład typów i koszt każdego z nich. Oto jak zamienić te dane w narrację.
Zamiast: *„mieliśmy 8 escaped bugów."* Powiedz: *„mieliśmy 8 escaped problems - 5 defektów kodu, 2 problemy konfiguracyjne i 1 awaria integracji. Łączny koszt: ok. 68 godzin. Infra i integracje wymagają osobnej strategii."*
Sprint review
„W tym sprincie mieliśmy 3 escaped problems: 2 defekty kodu i 1 problem konfiguracyjny środowiska. Koszt: ok. 22 godziny. Problem konfiguracyjny był najdroższy - i mamy plan, żeby go nie powtórzyć."
1:1 z EM
„Patrząc na trend - defekty kodu spadają. Ale problemy infra i integracji utrzymują się na stałym poziomie. To wymaga innej interwencji niż więcej testów - potrzebujemy lepszej spójności środowisk i testów kontraktowych."
Zarząd
„W Q4 mieliśmy 8 escaped problems o łącznym koszcie ok. 68 godzin roboczych. Dla porównania - w Q1 było ich 18 za ok. 160 godzin. Największą oszczędność przyniosły testy kontraktowe wdrożone w Q2."
Co zmienia pełna taksonomia
Gdy zaczniesz kategoryzować escaped problems zamiast tylko je liczyć - rozmowa zmienia się fundamentalnie. Przestajesz mówić ile, a zaczynasz mówić co i dlaczego.
4
typy escaped problems do śledzenia
5×
różnica kosztu: kod vs integracja
35%
problemów pomijanych gdy mierzysz tylko bugi w kodzie
15min
tygodniowy przegląd wystarczy do pełnej kategoryzacji
Klient nie zgłasza problemu z etykietą „typ: infrastruktura". Dla niego - i dla Twojego biznesu - liczy się jedno: czy działa. Mierz wszystko, co może przestać działać.
W następnym artykule
Artykuł czwarty dotyczy Issues per Release - metryki dojrzałości kodu, która zmienia rozmowę z Engineering Managerem. Nie pyta, ile bugów znalazłeś - pyta, jak czysty kod dostałeś do testowania.
Spoiler: to jest metryka, która często ujawnia, że problem leży nie po stronie QA, ale po stronie procesu wytwórczego - i daje Ci dane, żeby tę rozmowę prowadzić z pozycji faktów, nie opinii.
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
Escaped Bugs i Problems czytasz teraz
Taksonomia, zbieranie danych, koszt każdego typu, jak raportować
-
04
Jak ta metryka zmienia rozmowę z Engineering Managerem
-
05
Wskazywanie problemów, nie tylko obserwowanie trendów
-
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ć