Seria: QA Leadership · Artykuł 4 z 9
Był poniedziałkowy standup. QA Lead miał pod oczami cienie - poprzedni tydzień zajął mu głównie wpisywanie ticketów. Pięćdziesiąt cztery issues w jednym releasie. Pięćdziesiąt cztery.
Poniedziałek · 09:15 · Sprint Planning
EM„Jak idzie testowanie? Zdążymy z releasem w piątek?"
QA„Mam 54 otwarte issues z tego sprintu. Pracuję 10 godzin dziennie. Nie wiem, czy zdążę."
EM„54? To dużo, co się stało?"
QA„Nie wiem co się stało - wiem tylko, że ostatni release miał 18, a ten ma już 54 i jeszcze nie skończyłem."
Dev„Ten release był duży, dużo nowych funkcji..."
QA„Poprzedni też był duży. 18 issues."
EMcisza
Ta rozmowa skończyła się dobrze - bo QA Lead miał dane. Poprzedni release: 18. Bieżący: 54+. Bez tego porównania byłoby tylko: „jest dużo bugów, pracujemy.”
Issues per Release to metryka, która zamienia „jest dużo pracy” w konkretny sygnał. I - co ważniejsze - wskazuje, gdzie leży problem. Nie zawsze w testowaniu.
Czym jest Issues per Release
Issues per Release to liczba wszystkich problemów znalezionych przez QA w trakcie testowania jednego release’u - od momentu przyjęcia kodu do testów, do decyzji o wdrożeniu.
Co liczy się jako „issue”
To jedno z najważniejszych pytań przy wdrażaniu tej metryki. Zbyt wąska definicja - i tracisz połowę sygnału. Zbyt szeroka - i liczba traci interpretację.
🐛
Defekt funkcjonalny
Aplikacja zachowuje się inaczej niż powinna według specyfikacji lub zdrowego rozsądku.
zawsze liczyć
🎨
Problem UX / UI
Elementy działają technicznie, ale są nieczytelne, nieintuicyjne lub niespójne z resztą produktu.
liczyć z etykietą
⚡
Problem wydajnościowy
Czas odpowiedzi, zużycie zasobów, zachowanie pod obciążeniem - poza akceptowanymi progami.
liczyć z etykietą
📋
Niezgodność z wymaganiami
Zaimplementowano coś innego niż było w specyfikacji - celowo lub przez nieporozumienie.
zawsze liczyć
🌍
Problem środowiskowy
Aplikacja działa inaczej na różnych przeglądarkach, urządzeniach lub środowiskach testowych.
liczyć z etykietą
Rekomendacja: licz wszystkie typy, ale taguj każdy z nich. Dzięki temu masz globalną liczbę IPR i możliwość drążenia w szczegóły - np. „20 issues, z czego 14 defektów funkcjonalnych, 4 UX i 2 środowiskowe.”
Kluczowa perspektywa
Issues per Release to NIE jest metryka QA
To jest metryka jakości całego procesu wytwórczego. QA tylko ją mierzy - ale za wynik odpowiada cały zespół. I to jest właśnie to, co sprawia, że ta metryka jest tak cenna w rozmowie z Engineering Managerem.
~50%
Programiści
Jakość kodu, testy jednostkowe, code review, samodzielne testy przed przekazaniem
→ Definition of Done
~20%
Product / Design
Kompletność wymagań, spójność specyfikacji, dostępność projektanta do pytań
→ Jakość backlogu
~20%
Proces zespołu
Przegląd wymagań przed sprintem, Three Amigos, refinement, acceptance criteria
→ Dojrzałość procesu
~10%
QA
Jakość przypadków testowych, pokrycie scenariuszy, środowisko testowe
→ Skuteczność testowania
Gdy IPR rośnie - pierwsza rozmowa nie powinna brzmieć „QA musi testować lepiej". Powinna brzmieć: „co zmieniło się w procesie wytwórczym od ostatniego release'u?"
Trend, który mówi więcej niż jakikolwiek status update
Jeden release to nic. Sześć releasów z wyraźnym kierunkiem - to historia. I to właśnie historia przekonuje Engineering Managera do działania.
Issues per Release - trend przez 6 releasów
Rozkład według typów ujawnia, gdzie leży problem i co wymaga interwencji
v2.1 → v2.6
Defekty funkcjonalne
UX / UI
Wydajność
Niezgodności z wymaganiami
IPR vs DDR - korelacja procesowa
Gdy IPR spada, DDR rośnie. Lepszy kod wchodzący do testów = mniej problemów = więcej złapanych przed produkcją
wzajemna zależność
Issues per Release (szt.)
DDR (%)
Jak czytać wynik
Nie ma jednego „dobrego” IPR - zależy od rozmiaru release’u, złożoności systemu i dojrzałości zespołu. Ale trendy są wymowne zawsze. Poniżej progi orientacyjne dla typowego release’u średniej złożoności.
20+
Sygnał alarmowy
Warto zbadać przyczyny przed kontynuowaniem sprintu. Co zmieniło się w procesie?
12-20
Do poprawy
Wymaga uwagi. Sprawdź, które kategorie dominują i zaproponuj jedno działanie naprawcze.
6-12
Solidny poziom
Dobra praca. Monitoruj trend - czy systematycznie maleje, czy oscyluje?
<6
Dojrzały proces
Świetny wynik. Sprawdź, czy testy wystarczająco głęboko pokrywają krytyczne ścieżki.
Ważne zastrzeżenie: niski IPR przy niskiej liczbie testów nie jest sukcesem - może oznaczać, że QA testuje zbyt płytko. Zawsze zestawiaj IPR z zakresem testów i DDR.
Jak zacząć mierzyć - cztery kroki
Dobra wiadomość: nie potrzebujesz nowych narzędzi. Dane są już w Twoim trackerze - trzeba je tylko odpowiednio zebrać i znakować.
1
Ustal definicję „issue" i zapisz ją w jednym miejscu
Zanim cokolwiek zaczniesz liczyć - ustal z zespołem: co wchodzi do licznika? Defekty funkcjonalne na pewno. Uwagi UX? Problemy wydajnościowe? Niezgodności z wymaganiami?
Zapisz to w Confluence, wiki lub jako komentarz do filtra w Jirze. Spójność definicji jest ważniejsza niż jej doskonałość.
2
Skonfiguruj pole „Fix version" lub tag release'u w Jirze
Każdy issue stworzony podczas testowania powinien mieć przypisany release, którego dotyczy. W Jirze to pole „Fix Version/s" lub własna etykieta release-v2.x.
project = MYAPP AND issuetype in (Bug, Task, Improvement)
AND "Fix Version" = "v2.3"
AND created >= startOfSprint()
ORDER BY created ASC
Ten filtr da Ci wszystkie issues znalezione podczas testowania konkretnego release'u.
3
Dodaj etykiety typów - od pierwszego dnia
Samo „ile" wystarczy na start. Ale „ile i jakiego rodzaju" daje Ci znacznie silniejszy argument w rozmowie z EM i PM. Wprowadź prosty system etykiet: type:functional, type:ux, type:perf, type:requirement.
Tagowanie zajmuje 30 sekund na issue. Zwraca się wielokrotnie przy każdej retrospektywie i rozmowie z biznesem.
4
Odtwórz historię wstecz - minimum 4 ostatnie releasey
Podobnie jak przy DDR - jeden punkt danych to za mało. Retroaktywne policzenie IPR za ostatnie 4-6 releasów zajmie 1-2 godziny i da Ci od razu trend.
Jeśli nie masz etykiet typów za poprzednie releasey - to trudniej, ale nadal warto zrobić globalne liczby. Trend IPR bez rozkładu typów wciąż jest bardzo wymowny.
Interaktywny tracker IPR
Wpisz dane ze swoich ostatnich releasów i od razu zobaczysz trend oraz ocenę każdego z nich.
Tracker Issues per Release
Wpisz liczbę issues dla każdego release'u - tracker wygeneruje ocenę i podsumowanie trendu
Jak ta metryka zmienia dynamikę
Bez danych rozmowa o jakości kodu wchodzącego do testów jest trudna. QA brzmi jak narzekanie, dev brzmi jak obrona. Z IPR w tle - to jest rozmowa o liczbach, nie o emocjach.
✗ Bez danych - rozmowa skończy się w punkcie wyjścia
QA„Znowu dostajemy kod pełen bugów. Nie możemy tak pracować."
EM„Każdy release jest inny, ten był szczególnie duży..."
Dev„Pracowaliśmy pod presją, deadline był napięty..."
QA„Ale to nie jest pierwszy raz..."
EM„Dobra, zobaczymy jak pójdzie następny."
✓ Z danymi - rozmowa prowadzi do konkretnego działania
QA„Mam dane z ostatnich 6 releasów. IPR wynosił: 8, 11, 9, 21, 28, 32. Coś zmieniło się po v2.3 - i od tamtej pory trend jest wyraźnie rosnący."
EM„v2.3... to był ten sprint, kiedy zmieniliśmy skład zespołu i zrezygnowaliśmy z code review dla szybszego dostarczania."
QA„Dokładnie. 80% wzrostu IPR to defekty funkcjonalne. Proponuję jedno działanie: przywrócenie obowiązkowego code review z listą kontrolną dla testowania."
EM„To ma sens. Kiedy możemy to wdrożyć?"
Różnica nie polega na tym, że QA Lead jest bardziej przekonujący. Polega na tym, że przychodzi z faktem, a nie z odczuciem. Trend IPR 8 do 32 przez 6 releasów jest niepodważalny. Opinia „dostajemy coraz gorszy kod” - jest podważalna.
Trzy pułapki przy korzystaniu z IPR
Porównujesz releasey różnej wielkości
Release z 3 funkcjami i release z 12 funkcjami nie są porównywalne bez normalizacji. Rozwiązanie: śledź też IPR na story point lub na funkcję - albo przynajmniej zaznaczaj „duży/mały/średni" przy każdym releasie w danych historycznych.
Niski IPR, bo QA testuje zbyt płytko
IPR 4 może oznaczać doskonały kod - albo testy, które nie wchodzą wystarczająco głęboko. Zawsze zestawiaj IPR z DDR: jeśli IPR spada, a DDR też spada - coś jest nie tak z pokryciem testów. Jeśli IPR spada, a DDR rośnie - masz prawdziwy postęp.
Używasz IPR do oceniania devów, nie procesu
To najgroźniejsza pułapka - i najkrótsza droga do tego, żeby programiści przestali zgłaszać problemy sami, zaczęli je ukrywać i traktowali QA jako wroga. IPR mierzy dojrzałość procesu, nie kompetencje ludzi. Komunikuj to wyraźnie i konsekwentnie przy każdej prezentacji tej metryki.
IPR w rozmowie z biznesem
Sprint Review
„Issues per Release wyniosło 8 - o 40% mniej niż poprzedni sprint. Kod wchodzi do testów coraz czystszy. To dobry sygnał dla całego procesu wytwórczego."
1:1 z EM
„Mam trend IPR z ostatnich 6 releasów - widoczny skok po v2.3. To zbiegło się z rezygnacją z code review. Proponuję konkretne działanie i chcę sprawdzić, czy IPR wróci do poprzedniego poziomu w ciągu dwóch releasów."
Zarząd
„W ciągu ostatnich czterech kwartałów Issues per Release spadło z 24 do 8 - czyli o 66%. Każdy issue to średnio 1,5 godziny pracy QA. To jest 24 godziny zaoszczędzone na jeden release - czas, który przeznaczamy teraz na testy eksploracyjne i automatyzację."
Co daje metryka, której nie ma w QA podręczniku
✓ IPR daje Ci
- Obiektywny miernik jakości kodu wchodzącego do testów
- Wczesny sygnał - zanim escapes trafią na produkcję
- Argument do rozmowy z EM oparty na faktach, nie opinii
- Wskaźnik dojrzałości całego procesu wytwórczego
- Korelację z DDR - pełniejszy obraz zdrowia procesu
✗ IPR nie mówi Ci
- Czy bugi uciekają na produkcję (to Escaped per Release)
- Jak skuteczne jest testowanie (to DDR)
- Czy możesz releasować (to Confidence Score)
- Kto konkretnie popełnia błędy - i nie powinno
QA nie jest fabryką napraw. Issues per Release to metryka, która to udowadnia - i przenosi rozmowę o jakości tam, gdzie powinna się odbywać: na poziom całego procesu wytwórczego.
W następnym artykule
Artykuł piąty dotyczy Escaped Bugs per Release - metryki, która nie pyta, ile bugów masz łącznie, ale które konkretnie releasey były ryzykowne. I jak ten widok pozwala Ci diagnozować przyczyny, a nie tylko obserwować skutki.
Spoiler: skok w jednym releasie to zawsze sygnał do śledztwa. I mamy metodę, jak to śledztwo prowadzić.
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
Issues per Release czytasz teraz
Wdrożenie od zera, związek z procesem wytwórczym, rozmowa z EM
-
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ć