Co traci software house bez metryk QA
TL;DR
Bez metryk QA nie wiesz, czy Twój zespół testowy jest wydajny, czy po prostu zajęty. Podejmujesz decyzje kadrowe i narzędziowe na podstawie przeczuć. Zacznij od jednej metryki — czasu na raport — i dopiero potem rozbudowuj pomiar.
Większość software house'ów w Polsce mierzy velocity developerów, śledzi sprint burndown, liczy story pointy. Ale gdy zapytasz o metryki QA, odpowiedź brzmi: „jakoś to działa". Nie ma danych o czasie raportowania bugów, o wskaźniku ponownych otwarć ticketów, o pokryciu testami na sprint. I to jest problem, bo bez metryk QA nie podejmujesz decyzji — zgadujesz.
Pułapka „jakoś to działa"
Capers Jones w „Applied Software Measurement" (2008) przeanalizował ponad 12 000 projektów IT i stwierdził, że organizacje bez formalnych metryk jakości mają 2-3 razy wyższy wskaźnik defektów na produkcji niż te, które mierzą procesy testowe systematycznie.
To nie znaczy, że musisz mierzyć wszystko. Ale zero metryk oznacza zero widoczności. Nie wiesz, czy tester, który raportuje 5 bugów dziennie, jest nieefektywny — czy po prostu pracuje nad stabilnym modułem. Nie wiesz, czy 30% reopen rate to norma w Twoim zespole, czy katastrofa. Nie wiesz, ile czasu pochłania samo raportowanie — a nie testowanie.
Raport DORA „Accelerate: State of DevOps" (2023) pokazuje jasno: zespoły o wysokiej wydajności (elite performers) mierzą co najmniej 4 kluczowe metryki procesowe. Zespoły o niskiej wydajności mierzą zero lub jedną. Korelacja między pomiarem a wynikami jest jednoznaczna.
5 metryk QA, które powinieneś znać
Nie musisz wdrażać ich wszystkich od razu. Ale powinieneś wiedzieć, że istnieją i co Ci dają.
1. Czas na raport buga. Ile minut zajmuje testerowi stworzenie jednego kompletnego ticketu w Jirze? Średnia rynkowa to 10-15 minut (Capgemini, „World Quality Report 2024"). Jeśli u Ciebie jest więcej — masz problem z procesem lub narzędziami. Jeśli jest mniej — sprawdź, czy raporty są kompletne.
2. Bug reopen rate. Jaki procent ticketów wraca do testera po „naprawieniu"? Branżowy benchmark to 5-10% (Capers Jones, „Software Defect Origins and Removal Methods", 2012). Powyżej 15% — raporty są niekompletne albo fixy są pobieżne.
3. Pokrycie testami na sprint. Ile procent user stories w sprincie ma przynajmniej jeden test case? Nie chodzi o 100% — chodzi o świadomy wybór co testujemy, a co pomijamy.
4. QA throughput. Ile bugów raportuje jeden tester dziennie? To pozwala porównywać obciążenie między osobami i projektami. Bez tej metryki nie widzisz, że jeden tester jest przeciążony, a drugi czeka na build.
5. Czas od znalezienia buga do wdrożenia fixa. Całkowity cykl życia defektu. DORA (2023) pokazuje, że elite performers mają lead time for changes poniżej 1 dnia. Jeśli Twoje bugi czekają tydzień na fix, masz wąskie gardło — ale bez pomiaru nie wiesz gdzie.
Co tracisz bez metryk — konkretne konsekwencje
Brak metryk QA to nie abstrakcyjny problem. To konkretne decyzje, które podejmujesz źle, bo nie masz danych.
Decyzje podejmowane na ślepo:
- Zatrudnianie nowego testera, gdy problem jest w narzędziach — nie w ludziach
- Kupowanie drogiego narzędzia do automatyzacji, gdy wąskie gardło to raportowanie manualne
- Obwinianie QA za opóźnienia sprintu, gdy prawdziwy bloker to czas naprawy bugów przez devów
- Ignorowanie faktu, że 25% bugów wraca jako reopen — bo nikt tego nie liczy
- Niewidzenie, że jeden tester poświęca 3 godziny dziennie na samo pisanie raportów
Stack Overflow Developer Survey (2023) wskazuje, że 62% deweloperów uważa „niejasne wymagania i słabą komunikację" za główne źródło problemów w projektach. Metryki QA nie rozwiążą komunikacji, ale dadzą Ci fakty zamiast opinii. A fakty kończą dyskusje szybciej niż spotkania.
Jak pomiar zmienia decyzje
Oto realny scenariusz. Masz 4 testerów. Wydaje Ci się, że QA „jakoś działa". Potem mierzysz.
Co pokazał pomiar:
- Średni czas na raport: 14 minut (przy 8 bugach dziennie = 112 minut raportowania / osoba / dzień)
- Bug reopen rate: 22% (co piąty ticket wraca)
- Dwa z czterech testerów spędzają ponad 25% dnia na pisaniu raportów, a nie na testowaniu
- Czas od zgłoszenia do fixa: średnio 4,2 dnia (przy czym 1,8 dnia to czekanie na „lepszy opis")
Bez pomiaru myślałbyś, że potrzebujesz piątego testera. Po pomiarze widzisz, że potrzebujesz lepszego procesu raportowania — bo obecni testerzy tracą 25-35% czasu na biurokrację zamiast na testowanie. To jest różnica między wydatkiem 8 000 PLN/miesiąc na nowego pracownika a inwestycją w narzędzie za ułamek tej kwoty.
Zacznij prosto: czas na raport jako pierwsza metryka
Nie musisz wdrażać wszystkich 5 metryk naraz. Zacznij od jednej — czasu na raport buga. To metryka, którą zmierzysz w jeden dzień i która natychmiast pokaże Ci skalę problemu.
Jak zmierzyć czas na raport
Dziś:
- Poproś każdego testera, żeby przez 3 dni mierzył stoperem czas tworzenia każdego ticketu
Za tydzień:
- Policz średnią, medianę i rozstęp (min-max). Pomnóż przez liczbę bugów dziennie
- Zobaczysz ile godzin dziennie Twój zespół poświęca na raportowanie — nie na testowanie
Za miesiąc:
- Dodaj drugą metrykę: reopen rate. Sprawdź ile ticketów wraca po naprawie
- Porównaj wyniki przed i po ewentualnych zmianach w procesie
Co to oznacza dla Twojego software house'u
Metryki QA to nie biurokracja. To narzędzie zarządcze, które pozwala odróżnić „zespół jest zajęty" od „zespół jest produktywny". Bez nich podejmujesz decyzje kadrowe, narzędziowe i procesowe na podstawie przeczuć. A przeczucia kosztują — bo zazwyczaj prowadzą do najdroższego rozwiązania zamiast najtrafniejszego.
Zacznij od czasu na raport. Jeśli wynosi powyżej 10 minut — masz konkretne pole do optymalizacji. Jeśli chcesz wiedzieć ile dokładnie tracisz, wrzuć swoje dane do kalkulatora.
Policz dla swojego zespołu
Wpisz dane zespołu i zobacz ile zaoszczędzisz miesięcznie i rocznie.
Otwórz kalkulator ROI →Źródła
- Capers Jones, „Applied Software Measurement" (2008) — analiza 12 000+ projektów IT i wpływ metryk na wskaźnik defektów.
- Capers Jones, „Software Defect Origins and Removal Methods" (2012) — benchmarki bug reopen rate. Link
- DORA Team, „Accelerate: State of DevOps Report" (2023) — korelacja między pomiarem metryk a wydajnością zespołów. Link
- Capgemini, „World Quality Report 2024" — dane o czasie pracy zespołów QA. Link
- Stack Overflow, „Developer Survey 2023" — dane o problemach w procesach deweloperskich. Link
Powiązane artykuły
Darmowy trial Voice2Bug
Podaj email — dostaniesz 30 dni darmowego dostępu. Zero zobowiązań.
Żadnego spamu. Tylko wartościowe treści z bloga.
Wolisz od razu? Zacznij darmowy trial