Dlaczego przestałem wierzyć w 99.9% pokrycia testami
Przez 7 lat budowania procesów QA w Katowicach i okolicach widziałem dziesiątki raportów świecących na zielono, które nie miały żadnego przełożenia na stabilność systemu. Deweloperzy dumnie pokazywali 99.6% pokrycia kodu, a błędy i tak lądowały na produkcji w każdą środę zaraz po wdrożeniu o 14:00. Ten tekst to moje rozliczenie z mitem idealnych statystyk.
Puste cyfry, które nic nie mówią o bezpieczeństwie
W 2022 roku pracowaliśmy z małym zespołem nad systemem do zarządzania magazynem dla firmy logistycznej. Mieli 96.7% pokrycia testami jednostkowymi, ale ich rurociąg CI/CD trwał 42 minuty. Każda drobna zmiana w kodzie wymuszała uruchomienie tysięcy testów, które sprawdzały, czy proste funkcje faktycznie zwracają tekst. To nie jest inżynieria, to palenie pieniędzy na prąd dla serwerów i marnowanie czasu programistów, którzy czekali na wynik zamiast pisać nowe funkcje.
Problem z dążeniem do pełnego pokrycia polega na tym, że testuje się wszystko bez opamiętania. Pisanie testów dla prostych getterów i setterów tylko po to, żeby wykres w SonarQube był zielony, to błąd. W TyeVals nauczyliśmy się, że lepiej mieć 73% pokrycia, ale skupionego na logice biznesowej, niż martwe 99.4%, które tylko utrudnia wprowadzanie zmian w kodzie. Szczerze: testy manualne to dziś często strata czasu, ale ślepa automatyzacja wszystkiego bywa jeszcze droższa.
Pogoń za 99.9% pokrycia kodu to często najkrótsza droga do tego, by zespół przestał dowozić funkcje na czas.
Testowanie rzeczy oczywistych kontra realne błędy
Zamiast gonić za statystyką, skupiamy się na krytycznych ścieżkach użytkownika. W systemie dla firmy transportowej z Gliwic, którą wspieraliśmy w marcu 2023 roku, ustaliliśmy 3 najważniejsze procesy: dodanie kursu, rozliczenie faktury i podgląd pozycji GPS. Te elementy otrzymały 87% pokrycia testami integracyjnymi. Reszta kodu, jak np. zmiana koloru przycisku w panelu administratora, ma tylko podstawowe testy dymne. Dzięki takiemu podejściu czas wdrożenia poprawki spadł z 2 dni do około 4 godzin.
Większość bugów, które kładą produkcję, nie wynika z braku testu jednostkowego dla pojedynczej klasy. One biorą się z błędnego połączenia usług lub złej konfiguracji bazy danych. Jeśli Twój zespół spędza 12 godzin tygodniowo na utrzymywaniu testów, które rzadko wykrywają błędy, to znaczy, że architektura QA leży. Kod musi zarabiać, a nie sypać błędami wynikającymi z przekombinowanej infrastruktury testowej, która nikomu nie służy.
Kiedy testy stają się kotwicą dla projektu
Utrzymanie ogromnej bazy testów kosztuje konkretne pieniądze. W jednym z projektów, gdzie zespół liczył 6 deweloperów, jeden specjalista spędzał średnio 3 dni w miesiącu tylko na poprawianiu testów, które padły po kosmetycznych zmianach w interfejsie. To prawie 14% jego czasu pracy wyrzucone w błoto. W TyeVals bez zbędnych prezentacji pokazujemy, jak wycinać zbędne testy, żeby proces CI/CD był lekki i dawał informację zwrotną w mniej niż 6 minut.
Prawdziwa wartość QA to pewność, że po wdrożeniu o 14:00 będziesz mógł spokojnie iść do domu, a nie siedzieć nad logami do wieczora. Ustawiamy procesy, które działają same i nie wymagają niańczenia przy każdej zmianie przecinka w kodzie. Z naszych obserwacji u 47 aktywnych klientów wynika, że optymalny poziom pokrycia dla stabilnego biznesu to zazwyczaj okolice 78-83%. Powyżej tego progu koszt dopisania każdego kolejnego testu przewyższa korzyści z jego posiadania.
Dobry test to taki, który chroni portfel klienta, a nie tylko uspokaja sumienie programisty.
Jak mądrze podejść do priorytetów w QA
Zacznij od audytu tego, co faktycznie testujesz. Jeśli masz 156 testów sprawdzających walidację formularza kontaktowego, a tylko 2 testy sprawdzające proces płatności, to masz problem. W TyeVals stosujemy podejście oparte na ryzyku. Analizujemy, gdzie błąd zaboli firmę najbardziej. Dla biura rachunkowego, które obsługuje 83 podmioty gospodarcze, priorytetem było wyliczanie składek ZUS. Tam pokrycie wynosi 91%, bo pomyłka o 2 grosze mogła skutkować karami z urzędu.
Jeżeli chcesz, żeby Twój system był stabilny, przestań patrzeć tylko na procenty w raportach. Zacznij mierzyć czas potrzebny na naprawę błędu i to, jak często błędy wracają po poprawkach. Nasze konsultacje QA skupiają się na tym, by testy były szybkie i niezawodne. Nie obiecujemy cudów, ale po 5 tygodniach pracy z nami większość zespołów skraca czas testów regresji o połowę, zachowując przy tym pełne bezpieczeństwo danych i spokój ducha.
