Jak mierzyć produktywność zespołu QA?

„Ile testów napisaliście w tym sprincie?” To jedno z tych pytań, które na pierwszy rzut oka wydają się rozsądne. W końcu testy to praca QA, więc policzmy testy i będziemy wiedzieć, czy zespół dowozi. Tylko że takie metryki prowadzą donikąd. Mierzą aktywność, a nie efekt. Zajętość, a nie wartość. I nic dziwnego, że zespoły QA mają potem problem z udowodnieniem swojej produktywności, skoro od lat rozlicza się je z działań, a nie z efektów.

Produktywność QA polega na tym, że firma traci mniej pieniędzy na błędach, mniej płaci za gaszenie pożarów i rzadziej przeżywa tygodnie, w których biznes patrzy na IT jak na ludzi od wymówek. Jeśli chcecie mierzyć QA tak, żeby rozumiał to dyrektor finansowy, a nie tylko CTO, musicie odwrócić perspektywę. Nie pytacie „ile zrobiliście”, tylko „co dzięki temu się nie wydarzyło”.

Dlaczego klasyczne KPI QA nie działają, nawet jeśli są „obiektywne”

Klasyczne wskaźniki QA powstały w świecie, w którym testowanie było etapem, a nie ciągłym procesem. Dziś wiele organizacji nadal raportuje testy wykonane, testy napisane, liczbę znalezionych defektów i procent pokrycia. Problem polega na tym, że te metryki są podatne na manipulację bez żadnej złej woli. Wystarczy, że zespół chce wyglądać dobrze. Jeśli mierzycie liczbę testów, zespół zaczyna produkować testy, często takie, które niczego nie bronią. Jeśli mierzycie liczbę błędów, premiujecie drobnicę, bo każdy defekt liczy się tak samo. Jeśli mierzycie pokrycie, wpadacie w „testujemy wszystko po trochu”, zamiast chronić to, co jest krytyczne dla przychodu.

Najprostsza zmiana myślenia brzmi tak: QA jest produktywne wtedy, gdy firma ma mniej kosztownych niespodzianek. To daje trzy warstwy mierzenia. Skuteczność, czyli ile problemów ucieka po wydaniu. Szybkość informacji zwrotnej, czyli jak szybko pipeline daje sygnał „jest bezpiecznie” albo „to zatrzymaj”. Wpływ biznesowy, czyli ile kosztowałoby to, co udało się zatrzymać wcześniej. Poniżej siedem metryk, które składają się na taki model, i da się je wdrożyć bez wielkiego programu, który kończy jako martwy dashboard.

Skuteczność: metryki 1, 2 i 4

Odsetek defektów z produkcji to najbardziej uczciwa metryka skuteczności, bo nie mierzy wysiłku, tylko efekt. Liczycie, ile defektów zostało wykrytych po wdrożeniu w porównaniu do wszystkich wykrytych w danym okresie, konsekwentnie na poziomie sprintu, wydania albo miesiąca. To nie jest metryka do bicia QA po głowie, tylko do diagnozy systemu. Wysoki odsetek może oznaczać złe testy, ale równie dobrze słabe wymagania, brak przeglądu kodu, niestabilne środowiska albo to, że QA dostaje build na koniec i ma udawać, że „zrobiło testy”.

Odsetek wdrożeń kończących się awarią i czas przywracania usługi to dwa z czterech kluczowych wskaźników DORA, obok częstotliwości wdrożeń i czasu od zmiany do produkcji. Jeśli Wasza firma żyje w rytmie CI/CD, nie ma sensu udawać, że QA jest osobnym światem. Produktywność QA jest częścią produktywności dostarczania. Gdy zaczynacie raportować te dwa wskaźniki razem z informacją, które regresje złapaliście przed wdrożeniem, Wasze QA przestaje być opowieścią o testach. Staje się opowieścią o niezawodności.

Ochrona krytycznych ścieżek kończy fetysz pokrycia. Procent pokrycia wygląda genialnie w raporcie i często nie znaczy nic. Sensowniejsze pytanie brzmi: czy krytyczne ścieżki biznesowe są chronione i jak szybko dostajecie sygnał, że nadal są zdrowe. Rejestracja, logowanie, wyszukiwanie, koszyk, płatność, zmiana planu, reset hasła. Nie interesuje Was, czy macie dwanaście tysięcy testów. Interesuje Was, czy te, które macie, stoją tam, gdzie stoi przychód.

Wpływ: metryki 3 i 6

Koszt unikniętych defektów to liczba, którą rozumie dyrektor finansowy, ale tylko wtedy, gdy nie oszukujecie sami siebie. Nie chodzi o wyciąganie z sufitu milionów i robienie z QA zbawcy budżetu. Chodzi o konserwatywne policzenie, ile kosztowałby defekt, który nie trafił do użytkownika. Na start: liczba krytycznych defektów zatrzymanych przed wdrożeniem razy koszt jednostkowy, który jesteście w stanie obronić w rozmowie, na przykład dzień pracy dwóch deweloperów plus wsparcie plus obsługa incydentu. Dojrzalej: podział na klasy wpływu, bo defekt blokujący sprzedaż ma inny koszt niż ten, który boli, ale nie zabija. Jak policzyć ten koszt w pięciu koszykach, opisujemy w tekście o tym, ile naprawdę kosztuje bug w produkcji.

Zwrot z automatyzacji liczony jak dorosły. Automatyzacja nie jest celem samym w sobie, tylko dźwignią na dwa efekty: szybki sygnał i powtarzalną ochronę krytycznych przepływów bez ręcznego mielenia regresji co tydzień. Liczycie, ile godzin ręcznej regresji zdejmujecie z kalendarza w miesiącu i ile incydentów realnie przestajecie przepuszczać, bo testy stoją w bramce. Jeśli automaty rosną, a produkcja nadal płonie, automaty rosną nie tam, gdzie trzeba. Jak wygląda ta dźwignia, gdy działa, pokazuje klient z e-commerce: regresja przed wydaniem skrócona z 5 dni do 10 godzin, 46 procent mniej błędów krytycznych na produkcji i 72 procent mniej awarii w szczycie.

Źródła: dane potwierdzone przez klienta Quality Island, Argos, e-commerce; Google Testing Blog, „Flaky Tests at Google and How We Mitigate Them”, 2016.

Szybkość: metryki 5 i 7

Czas informacji zwrotnej to metryka, którą wiele zespołów ignoruje, a potem dziwi się, że QA jest „spowalniaczem”. Jeśli regresja wykrywa się po kilku godzinach, w innym kontekście, na innym buildzie i po pięciu kolejnych zmianach, płacicie za przełączanie kontekstu, poprawki i frustrację. Mierzcie medianę od zmiany w kodzie do sygnału „regresja w krytycznej ścieżce” oraz procent przebiegów, które kończą się w czasie akceptowalnym dla zespołu. Nieoczywisty wniosek: czasem najbardziej produktywna rzecz, jaką QA może zrobić, to nie dopisać kolejnych testów, tylko skrócić pipeline, bo wtedy każdy istniejący test zaczyna mieć większą wartość. Siedem sygnałów, że jest za wolny, opisujemy w tekście o tym, po czym poznać, że pipeline testów jest za wolny.

Niestabilność i koszt utrzymania to cichy zabójca produktywności. Są organizacje, które mają dużo automatyzacji i niską produktywność QA. Brzmi jak paradoks, ale ma prostą przyczynę: testy niestabilne i koszt ich utrzymania. Google w tekście o testach niestabilnych w swojej infrastrukturze pokazało, że około 1,5 procent uruchomień dawało wynik niestabilny, a 84 procent przejść z zielonego na czerwone miało udział takiego testu. Jeśli większość alarmów jest fałszywa, zespół traci zaufanie do bramki i zaczyna ją obchodzić. Najprostsza metryka na start: odsetek czerwonych uruchomień, które kończą się jako fałszywy alarm albo problem środowiska, plus czas spędzony na ich wyjaśnianiu.

Dashboard dla zarządu na jednej stronie

Zarząd nie potrzebuje dwudziestu slajdów o tym, że „testy poszły”. Potrzebuje jednej strony, na której widać trend i ryzyko. Do takiej strony dopinacie nie opis działań, tylko decyzje: co robimy w następnym miesiącu, żeby obniżyć ryzyko, i jaki ma być efekt. Na przykład: skracamy czas sygnału dla checkoutu, żeby przestać wykrywać regresje po fakcie, albo redukujemy niestabilność w krytycznej bramce o połowę, bo dziś koszt wyjaśniania jest większy niż wartość alarmów. Dlaczego większość dashboardów jakości tego nie pokazuje, piszemy w tekście o tym, dlaczego dashboard jakości kłamie.

Cztery pułapki w mierzeniu produktywności QA

Podsumowanie

Produktywność QA nie polega na tym, ile włożonej pracy widać w narzędziu, tylko na tym, ile kosztownych problemów udało się uniknąć i jak szybko organizacja dowiaduje się prawdy o jakości. Jeśli zmienicie metryki z aktywności na wpływ, zmieni się rozmowa. QA przestaje być kosztem do uzasadniania, a zaczyna być elementem systemu zarządzania ryzykiem i niezawodnością, czyli czegoś, co zarząd rozumie intuicyjnie, nawet jeśli nie zna różnicy między testem a asercją.

W Quality Island pomagamy zespołom QA zbudować dashboard produktywności, który ma sens dla CTO i CFO. W ramach TestOps i QualityOps ustalamy definicje metryk, dobieramy wskaźniki pod ryzyko i przychód, a potem wdrażamy raportowanie w praktyce, tak żeby po miesiącu było widać trend, a nie tylko liczby. Jeśli chcecie przestać liczyć testy i zacząć liczyć wpływ, zacznijcie od jednej metryki: odsetka defektów, które w ostatnim kwartale uciekły na produkcję. Reszta tabeli wyżej ułoży się wokół niej.