Dlaczego Twój dashboard jakości kłamie (i jak to naprawić)

Zielone wykresy uspokajają. Pokrycie 90 procent, 98 procent testów zdanych, skracający się czas przebiegu. Na statusie wszystko wygląda dobrze, a jednak po kilku tygodniach znów macie incydent na produkcji, nerwowe telefony z biznesu i pytanie, które wraca jak bumerang: przecież na dashboardzie było zielono, co poszło nie tak? Większość dashboardów jakości nie pokazuje prawdy o ryzyku, tylko iluzję kontroli.

To nie jest kwestia narzędzia. Dashboard nie kłamie dlatego, że jest źle zbudowany technicznie. Kłamie, bo odpowiada na złe pytania. Mierzy aktywność zespołu QA zamiast ochrony tego, na czym firma zarabia. Poniżej pięć najczęstszych kłamstw, które widzimy w firmach, i konkretne sposoby, jak je naprawić bez wymiany narzędzi.

Pięć kłamstw dashboardu w jednej tabeli

Kłamstwo 1: pokrycie 90 procent znaczy, że jesteśmy bezpieczni

Pokrycie jest jedną z najbardziej eksponowanych metryk, bo jest proste i dobrze wygląda. Problem w tym, że pokrycie bez kontekstu ryzyka jest kosmetyką. W praktyce testy „wypełniają” łatwe i niskoryzykowne obszary: profil użytkownika, statyczne widoki, mało istotne warianty. A krytyczne ścieżki biznesowe, takie jak koszyk, płatności i integracje zewnętrzne, zajmują niewielki procent testów, bo są trudniejsze, bardziej zmienne albo wymagają lepszych danych i środowisk.

Naprawa zaczyna się od jednego ruchu: pokrycia ważonego ryzykiem. Nie wszystkie testy ważą tyle samo. Test płatności waży więcej niż test stopki. Weźcie dziesięć krytycznych ścieżek biznesowych, przypiszcie im wagę: wpływ na przychód, liczba użytkowników, koszt awarii. Oznaczcie testy tagami ścieżek i narysujcie drugi wykres: pokrycie na ścieżkach krytycznych, nie pokrycie całego systemu. To zmienia rozmowę z zespołem i z biznesem. Nie dyskutujecie, czy macie dużo testów. Dyskutujecie, czy chronicie najdroższe ryzyka.

Kłamstwo 2: 98 procent zdanych znaczy, że jest stabilnie

Odsetek zdanych testów wygląda świetnie na slajdach, ale potrafi być całkowicie oderwany od rzeczywistości, bo ukrywa niestabilność. Test, który przechodzi po trzecim ponownym uruchomieniu, dalej liczy się jako zdany. Dashboard świeci na zielono, a zespół traci zaufanie do sygnału. Skalę zjawiska pokazało Google w tekście o testach niestabilnych w swojej infrastrukturze: około 1,5 procent uruchomień dawało wynik niestabilny, blisko 16 procent testów miało jakiś poziom niestabilności, a 84 procent przejść z „zdany” na „niezdany” dotyczyło testu niestabilnego. Większość czerwonych wyników była szumem, nie sygnałem.

Źródło: Google Testing Blog, „Flaky Tests at Google and How We Mitigate Them”, 2016.

Naprawa nie polega na podkręceniu odsetka zdanych. Polega na odzyskaniu zaufania do wyniku. Trzy zasady działają w praktyce. Kwarantanna: test niestabilny wypada z krytycznej ścieżki aż do naprawy. Zero ponownych uruchomień w metrykach: ponowne uruchomienie może istnieć jako mechanizm awaryjny, ale metryka liczy wynik pierwszego przebiegu. Artefakty na porażce: logi, zrzut ekranu, wideo, ślad. Bez tego niezdany test jest bezużyteczny. Celem nie jest idealnie zielony dashboard. Celem jest wiarygodny sygnał, na którym da się podjąć decyzję o wydaniu.

Kłamstwo 3: więcej testów znaczy większy postęp

Wzrost liczby testów to jedna z najbardziej zdradliwych metryk produktywności QA. Łatwo ją dowieźć i trudno zakwestionować. Tylko że więcej testów bardzo często oznacza więcej długu utrzymaniowego, a nie więcej jakości. Tysiąc testów niskiej wartości nie chroni tak skutecznie jak dziesięć dobrze dobranych scenariuszy krytycznych. Co gorsza, duży zestaw obniża jakość sygnału: jest wolny, pełen szumu i zaczyna hamować, a nie chronić.

Naprawa zaczyna się od odwagi: usuwać testy. Działa prosty filtr wartości. Każdy test dostaje ocenę: ryzyko i krytyczność ścieżki oraz stabilność sygnału, podzielone przez koszt utrzymania. Jeśli test ma małą wartość, a duży koszt, wypada. Tak samo jak w biznesie: trzymanie nierentownego produktu tylko dlatego, że już go macie, to przepis na stratę. Nie potrzebujecie skomplikowanego modelu. Wystarczy, że każdy test ma opis: jaką ścieżkę chroni, jakie ryzyko pokrywa, jak często się psuje i ile kosztuje w utrzymaniu.

Kłamstwo 4: średni czas 15 minut znaczy szybki pipeline

Średnia jest wygodna, ale ukrywa prawdę o wąskich gardłach. Najczęściej kilka najwolniejszych testów, uruchamianych sekwencyjnie na nieoptymalnych środowiskach, robi większość czasu całego przebiegu. Jeśli dashboard pokazuje tylko średnią, nie widzicie, co Was naprawdę spowalnia. Prawdziwa optymalizacja zaczyna się od 95. percentyla, czyli czasu, w którym mieści się 95 procent przebiegów, i od listy pięciu najwolniejszych testów z każdej doby. Do tego dwie liczby: ile testów idzie równolegle, a ile stoi w kolejce, oraz co jest wąskim gardłem, procesor, dysk, sieć czy środowisko.

Często okazuje się, że ten sam zestaw może zejść z kilkunastu minut do kilku bez magicznych narzędzi, tylko przez równoległość, podział zestawu i usunięcie najgorszych przypadków. Po czym poznać, że pipeline jest już za wolny, żeby mieć sens, i jak go skrócić w cztery tygodnie, piszemy w osobnym tekście o za wolnym pipeline testów.

Kłamstwo 5: mniej bugów znaczy większy sukces

Spadek liczby zgłoszonych błędów trafia na slajdy jako dowód poprawy jakości. Może znaczyć kilka rzeczy: poprawę, przesunięcie testów wcześniej w procesie, albo po prostu zmianę zachowania zespołu, czyli mniej zgłaszania, więcej omijania, więcej cichego akceptowania ryzyka. Jedyną metryką, która naprawdę mówi o skuteczności QA, jest odsetek defektów, które uciekły na produkcję, w relacji do wszystkich wykrytych. Ten wskaźnik bezpośrednio łączy QA z ryzykiem biznesowym. Jeśli macie piękny wykres liczby błędów, a produkcja nadal płonie, mierzycie coś, co nie opisuje ryzyka.

Ten sam kierunek podpowiada program badawczy DORA, który zdolność zespołów do dostarczania mierzy czterema wskaźnikami: częstotliwością wdrożeń, czasem od zmiany do produkcji, odsetkiem wdrożeń kończących się awarią i czasem przywracania usługi. Żaden z nich nie liczy testów. Każdy liczy skutek dla użytkownika. Jak rachunek za defekt na produkcji wygląda w pieniądzach, opisujemy w tekście o tym, ile naprawdę kosztuje bug w produkcji.

Jak wygląda dashboard, który mówi prawdę

Dashboard jakości nie jest kolorową choinką. Jest narzędziem do rozmowy o ryzyku. Zamiast kilkunastu metryk technicznych ma kilka wskaźników decyzyjnych i pokazuje nie tylko, co jest, ale dlaczego jest i ile kosztuje. Dzięki temu QA przestaje wyglądać jak koszt, a zaczyna być widziane jako mechanizm ochrony przychodu i stabilności.

Jak wygląda różnica w praktyce, pokazuje klient z e-commerce, dla którego porządkowaliśmy procesy QA i automatyzację regresji. Na starym dashboardzie liczba testów rosła. Na nowym liczyły się skutki: regresja przed wydaniem skróciła się z 5 dni do 10 godzin, liczba błędów krytycznych na produkcji spadła o 46 procent, a awarie w okresach szczytowych o 72 procent. Ta druga tablica przekonała zarząd. Pierwsza uspokajała tylko zespół QA.

Siedem kroków, które naprawdę naprawiają dashboard

Nie potrzebujecie rewolucji ani nowego narzędzia. W większości przypadków wystarczą dwa tygodnie świadomej pracy, pod warunkiem że przestaniecie gonić zielony kolor, a zaczniecie gonić wiarygodny sygnał. Efekt bywa zaskakująco szybki: mniej szumu, szybszy pipeline, większe zaufanie do sygnału i realny spadek regresji na produkcji. A co najważniejsze, przestajecie rozmawiać o jakości na poziomie zielonych wykresów. Zaczynacie rozmawiać o ryzyku, które firma świadomie akceptuje albo świadomie redukuje. Dlaczego raporty QA tak często nie zmieniają decyzji zarządu, piszemy w osobnym tekście o raportach QA, które nic nie zmieniają.

Podsumowanie

Dashboard jakości powinien odpowiadać na dwa pytania, których biznes naprawdę potrzebuje: jakie ryzyko wypuszczamy na produkcję i ile ono kosztuje. Jeśli nie umiecie tego pokazać, nie macie narzędzia do zarządzania jakością. Macie ładną dekorację, która daje złudne poczucie bezpieczeństwa. Dobra wiadomość: da się to naprawić bez rewolucji. Wystarczy przestać liczyć wszystkie testy po równo, rozbić odsetek zdanych na sygnał i szum oraz połączyć dashboard z danymi z produkcji.

W Quality Island pomagamy zespołom QA i liderom IT zamieniać dashboardy z zielonych światełek w realne narzędzia decyzyjne. Robimy to w ramach TestOps i QualityOps: od przeglądu metryk i pipeline’u, przez politykę niestabilności, po widok, który łączy wyniki testów z incydentami z produkcji. Jeśli chcecie sprawdzić, które metryki w Waszej organizacji kłamią, zacznijcie od jednej: policzcie odsetek defektów, które w ostatnim kwartale uciekły na produkcję. Ta liczba powie Wam więcej niż cały obecny dashboard.