Jak obniżyć koszty utrzymania oprogramowania dzięki lepszemu QA

Utrzymanie oprogramowania ma jedną cechę, której nie da się polubić: potrafi pożerać budżet w sposób niewidoczny. Na początku wszystko wygląda zdrowo. Zespół dowozi funkcje, backlog puchnie od pomysłów, biznes jest zadowolony. A potem przychodzi rzeczywistość: drobne błędy, które w piątek wieczorem uruchamiają lawinę eskalacji, regresje po niewinnym refactorze, dyżury, hotfixy i to charakterystyczne zmęczenie organizacji, kiedy każdy release zaczyna kojarzyć się z ryzykiem.

Właśnie w tym miejscu QA przestaje być kosztem jakości, a zaczyna być narzędziem do obniżania kosztów utrzymania. I to nie na zasadzie abstrakcyjnego „kiedyś się zwróci”, tylko w bardzo przyziemnych, policzalnych obszarach: mniej incydentów, krótsze diagnozy, mniej regresji, mniej pracy w trybie awaryjnym, mniej wyrwanych z kontekstu godzin zespołu na poprawki, które nie tworzą żadnej nowej wartości.

Usterka nie jest droga dlatego, że istnieje. Jest droga dlatego, że ujawnia się w najgorszym możliwym momencie, w najgorszym możliwym miejscu i angażuje zbyt wiele osób naraz. Kiedy błąd trafia na produkcję, przestaje być problemem jednej osoby i jednego commita. Zaczyna kosztować czas programistów, testerów, wsparcia, product managerów, czasem sprzedaży. Do tego dochodzi koszt reputacyjny, którego nie widać w Jirze, ale widać w churnie.

Gdzie naprawdę ucieka budżet utrzymania

Większość firm liczy koszt utrzymania jako sumę etatów przypisanych do „utrzymania” i faktur za infrastrukturę. To najmniejsza część rachunku. Prawdziwy koszt siedzi w pozycjach, których nikt nie księguje osobno, bo są rozlane po całym zespole. Poniższa tabela zbiera je w jednym miejscu, razem z tym, co w każdej z nich zmienia dobrze ustawione QA.

Skala tego rachunku jest większa, niż podpowiada intuicja. Według raportu CISQ „The Cost of Poor Software Quality in the US” z 2022 roku słaba jakość oprogramowania kosztowała gospodarkę Stanów Zjednoczonych co najmniej 2,41 biliona dolarów. Ten sam raport szacuje narosły tam dług techniczny na około 1,52 biliona dolarów. Z badania Stripe „The Developer Coefficient” z 2018 roku wynika, że programista spędza średnio 17,3 godziny tygodniowo na utrzymaniu, czyli na debugowaniu, refaktoryzacji, poprawkach i walce ze złym kodem. Przy średnim tygodniu pracy 41,1 godziny, który podaje to samo badanie, to ponad 40 procent czasu zespołu. Według tego samego raportu około czterech godzin tygodniowo idzie wyłącznie na zły kod, co Stripe przelicza na blisko 85 miliardów dolarów utraconych rocznie na świecie. Gdyby tak pracowała kuchnia w restauracji, prawie połowa zmiany schodziłaby na zmywanie garnków po wczorajszej kolacji, a goście dalej czekaliby na zupę.

Utrzymanie kosztuje najbardziej wtedy, gdy jakość jest nieprzewidywalna

Wiele firm próbuje obniżać koszty utrzymania przez skracanie procesu, cięcie testów albo dokładanie jeszcze jednego programisty do bugów. To działa jak oszczędzanie na przeglądach auta, bo na razie jeździ. Przez chwilę jest taniej, a potem rachunek przychodzi z odsetkami i zwykle w najmniej dogodnym momencie.

Prawdziwy problem leży gdzie indziej: w braku przewidywalności. Jeżeli nie wiecie, czy release jest bezpieczny, zaczynacie się go bać. Jeżeli boicie się wydania, robicie ich mniej, a każda zmiana staje się większa. A im większa zmiana, tym większe ryzyko. W efekcie utrzymanie staje się trybem życia, a nie zestawem czynności po wdrożeniu. Badania DORA od lat pokazują tę samą zależność: zespoły, które wydają często i w małych porcjach, mają jednocześnie niższy odsetek nieudanych zmian i krótszy czas przywracania sprawności. W raporcie DORA 2024 zespoły z najwyższego klastra mają odsetek nieudanych zmian na poziomie 5 procent, z najniższego 40 procent. Częste, małe wydania nie są ryzykiem. Są sposobem na jego ograniczenie.

Dobre QA wprowadza przewidywalność. Nie magicznie, tylko przez to, że buduje zaufanie do procesu dostarczania zmian. Jeśli potraficie szybko odpowiedzieć na pytania: co jest ryzykiem, co sprawdziliśmy, co się zmieniło i jak to się zachowuje w krytycznych ścieżkach, koszty utrzymania zaczynają spadać. Najpierw nie spektakularnie, ale konsekwentnie.

Najdroższa praca w IT to praca awaryjna

Jest coś wyjątkowo kosztownego w pracy „na już”. Kiedy produkcja płonie, włączają się mechanizmy, które są zabójcze dla efektywności. Ludzie przerywają bieżące zadania, przełączają kontekst, komunikacja robi się nerwowa, a decyzje podejmuje się pod presją. Nawet jeśli naprawa jest prosta, całe otoczenie incydentu podbija koszt.

Lepsze QA obniża te koszty przede wszystkim dlatego, że zmniejsza liczbę sytuacji awaryjnych. Ale równie ważne jest to, że kiedy już incydent się zdarzy, bo w realnym świecie zdarzy się zawsze, organizacja jest w stanie szybciej go zrozumieć, odtworzyć i naprawić. Tu wchodzi temat, o którym rzadko mówi się w kontekście QA, a powinno się mówić częściej: testowalność. Jeśli system jest zaprojektowany tak, że da się go łatwo diagnozować, obserwować i odtwarzać problemy, koszty utrzymania spadają same, bo nie płacicie podatku od zgadywania. Dobrze ustawione QA potrafi wymusić tę zmianę jednym pytaniem zadawanym konsekwentnie przy każdej zmianie: jak to przetestujemy i jak to będziemy debugować, jeśli jutro wybuchnie?

Regresje to cichy podatek od każdej zmiany

W większości produktów utrzymanie nie jest drogie dlatego, że system jest skomplikowany. Jest drogie dlatego, że system jest kruchy. Kruchość oznacza, że nawet mała zmiana potrafi zepsuć coś daleko od miejsca, w którym ją wprowadzono. Wtedy organizacja chodzi po polu minowym: niby wie, co zmienia, ale i tak co jakiś czas coś wybucha.

Koszt regresji rzadko kończy się na „poprawiliśmy błąd”. Zaczyna się dopiero wtedy, gdy zespół robi wszystko, żeby taka sytuacja się nie powtórzyła, tylko że bez planu. Dokłada kolejne ręczne scenariusze, kolejne kroki w procesie, kolejne wyjątki w pipeline. To ludzka reakcja na ból, ale biznesowo nieopłacalna. Z czasem release staje się ciężki, wolny i stresujący, a koszty rosną, mimo że przecież tyle testujemy.

Lekarstwem nie jest testowanie wszystkiego. Lekarstwem jest ochrona tego, co naprawdę kosztuje, gdy się zepsuje: płatności, logowanie, rejestracja, wyszukiwanie, finalizacja zamówienia, podstawowe operacje na danych. Tak wyglądał projekt dla Argos, firmy e-commerce, w którym zakres pracy to automatyzacja testów i uporządkowanie procesów QA. Liczby poniżej pochodzą od klienta.

Źródło: wyniki projektu Quality Island dla Argos (e-commerce), liczby potwierdzone przez klienta.

Zwróćcie uwagę, że trzy z czterech liczb to koszty utrzymania: krótsza regresja to mniej godzin zespołu przy każdym wydaniu, mniej awarii w szczycie to mniej pracy awaryjnej wtedy, gdy jest najdroższa, mniej błędów krytycznych to mniej hotfixów. Czwarta liczba, konwersja, to efekt uboczny stabilności, o którym dział utrzymania zwykle nie myśli, a CFO tak. W projekcie dla Argos oznaczało to regresję skróconą z 5 dni do 10 godzin przy każdym wydaniu, czyli czas, który zespół odzyskuje na rozwój zamiast na sprawdzanie tego samego po raz kolejny.

Pięć dźwigni, które obniżają koszt utrzymania najszybciej

Pierwsza: automatyczny smoke na krytycznych ścieżkach w CI. Kilka minut, kilkanaście scenariuszy, zero tolerancji dla czerwonego. To nie jest pełna regresja, tylko sygnał, że zmiana nie zepsuła tego, co przynosi pieniądze. Jedna dźwignia, która najbardziej zmienia poczucie bezpieczeństwa przy wydaniu.

Druga: przeniesienie automatyzacji niżej. Testy API i kontraktów łamią się rzadziej niż testy UI, bo nie zależą od przesuniętego przycisku. Im więcej pokrycia na niższych poziomach, tym mniej czasu na naprawę testów zamiast produktu.

Trzecia: strategia danych testowych i środowisk. Konta, zestawy danych, reset stanu, izolacja. Bez tego każdy retest trwa dłużej, a testy automatyczne zachowują się losowo i tracą zaufanie.

W naszych projektach automatyzacji niestabilne testy są zwykle pierwszą rzeczą, którą porządkujemy, zanim dopiszemy choćby jeden nowy scenariusz. Z naszego doświadczenia zespół, który przestaje wierzyć w czerwony pipeline, po kilku tygodniach zaczyna go omijać, a wtedy inwestycja w automatyzację przestaje się zwracać. Jeśli chcecie zbudować automatyzację, której Wasz zespół ufa, zobaczcie, jak prowadzimy automatyzację testów w Quality Island. Jeśli wolicie zbudować te kompetencje u siebie, sprawdźcie szkolenie z automatyzacji testów w Playwright albo najbliższe terminy w kalendarzu szkoleń.

Czwarta: klasyfikacja defektów według wpływu na biznes. Nie każdy błąd zasługuje na hotfix. Jeśli zespół ma prostą regułę, co blokuje wydanie, a co idzie do backlogu z terminem, znika połowa pracy awaryjnej, która była tylko brakiem decyzji.

Piąta: pytanie o testowalność przy projektowaniu zmiany. Logi w krytycznych punktach, identyfikatory żądań, możliwość odtworzenia stanu. Koszt: kilka minut przy każdej zmianie. Oszczędność: godziny przy każdym incydencie.

Dlaczego cięcie testów podnosi koszt utrzymania zamiast go obniżać

To najbardziej kontrintuicyjna zależność w całym rachunku. Cięcie testów widać w budżecie od razu: mniej godzin, mniej etatów, krótszy czas do wydania. Efekt pojawia się z opóźnieniem jednego do trzech miesięcy i w innej rubryce: więcej incydentów, dłuższe diagnozy, więcej hotfixów, więcej pracy w trybie awaryjnym. Ponieważ oszczędność i koszt siedzą w różnych rubrykach i w różnych miesiącach, nikt ich nie łączy. Zarząd widzi, że QA kosztuje mniej, a dział utrzymania widzi, że ma więcej pracy, i obie strony mają rację. Jedyny sposób, żeby to zobaczyć, to liczyć koszt utrzymania jakości jako jedną pozycję, tak jak w czterech krokach niżej. Wtedy cięcie testów przestaje wyglądać jak oszczędność, bo widać, dokąd przesunęły się pieniądze.

Jak policzyć, ile utrzymanie kosztuje Was naprawdę

Zróbcie to raz, na danych z ostatniego kwartału, i wróćcie do tego rachunku po wdrożeniu zmian. Cztery kroki wystarczą.

1. Godziny pracy awaryjnej. Policzcie czas zespołu spędzony na incydentach produkcyjnych: diagnoza, naprawa, komunikacja, retest. Pomnóżcie przez stawkę godzinową. Nie zgadujcie, weźcie trzy ostatnie incydenty i policzcie je od początku do końca.
2. Godziny regresji. Ile osób przez ile dni sprawdza produkt przed każdym wydaniem i ile wydań macie w kwartale. To zwykle największa pojedyncza pozycja.
3. Koszt przesuniętych wydań. Ile razy release przesunął się z powodu błędów i ile wart był każdy dzień poślizgu dla biznesu.
4. Koszt obsługi zgłoszeń klientów związanych z błędami: czas wsparcia, rabaty, utracone odnowienia, jeśli potraficie je przypisać.

Suma z czterech kroków to Wasz realny kwartalny koszt utrzymania jakości. Porównajcie go z kosztem sensownego QA, w wersji, którą naprawdę byście wdrożyli. Jeśli chcecie zobaczyć tę metodę w wersji dla całej organizacji, opisaliśmy ją przy okazji tipping pointu jakości w artykule o tym, dlaczego jakość się nie opłaca, dopóki się nie opłaca.

Co zrobić w pierwszym miesiącu

Nie zaczynajcie od wielkiego programu jakości. Zacznijcie od przeglądu: skąd biorą się incydenty, ile trwa regresja, gdzie zespół traci czas na diagnozę. W Quality Island robimy takie przeglądy jako audyt QA i procesu wydania, bez rewolucji, za to z listą zmian ułożoną według zwrotu: najpierw to, co obniża koszt najszybciej. Często już sam audyt pokazuje, gdzie uciekają godziny, bo nikt wcześniej nie zsumował ich w jednym miejscu.

Powiązane na Strefie QA

• Dlaczego jakość się nie opłaca, dopóki się nie opłaca
• Ile naprawdę kosztuje bug w produkcji, i czemu zaniżasz tę liczbę
• Testy regresyjne w dużych projektach: jak przestać bać się każdego wdrożenia

Źródła:

• DORA (Google Cloud), Accelerate State of DevOps Report, 2024: wzięliśmy porównanie klastrów wydajności dostarczania, czyli odsetek nieudanych zmian 5 procent w najlepszym klastrze wobec 40 procent w najsłabszym.
• CISQ (Consortium for Information & Software Quality), The Cost of Poor Software Quality in the US: A 2022 Report, 2022: wzięliśmy szacunek kosztu słabej jakości oprogramowania w USA (co najmniej 2,41 biliona dolarów) i narosłego długu technicznego (około 1,52 biliona dolarów).
• Stripe, The Developer Coefficient, 2018: wzięliśmy średni czas programisty na utrzymanie (17,3 godziny tygodniowo przy tygodniu pracy 41,1 godziny) i szacunek kosztu złego kodu (blisko 85 miliardów dolarów rocznie).
• Google Testing Blog, John Micco, Flaky Tests at Google and How We Mitigate Them, 2016: wzięliśmy dane o niestabilnych testach (1,5 procent uruchomień, prawie 16 procent testów, 84 procent przejść na czerwone).
• Wyniki projektu Quality Island dla Argos (e-commerce): automatyzacja testów i uporządkowanie procesów QA, liczby potwierdzone przez klienta
• Audyt QA, Quality Island
• Metodyka i praktyka własna Quality Island z audytów procesów QA i wdrożeń automatyzacji