Koszty i oszczędności testowania oprogramowania: ile naprawdę kosztuje późno wykryty błąd

Koszty testowania oprogramowania to wszystko, co płacicie za sprawdzanie produktu: ludzie, narzędzia, środowiska i czas zespołu. Oszczędności to koszty błędów, których dzięki temu nie ponosicie później: poprawek, ponownych testów, awarii i odejść klientów. W tym tekście pokazujemy, co o relacji jednego do drugiego mówią badania, gdzie popularne liczby są naciągane i jak policzyć zwrot z wczesnych testów na danych z Waszego projektu.

Poprzednia wersja tego artykułu powtarzała, że błąd poprawiony na etapie projektu kosztuje „10 do 100 razy mniej” niż na produkcji. Tę liczbę słyszał każdy, kto był na konferencji o jakości, i prawie nikt nie widział danych, z których pochodzi. Zamiast niej dostajecie tu trzy źródła z metodą, jedno badanie, które ją podważa, i liczby z naszego projektu dla Argos. Jeśli szukacie cennika usług, a nie ekonomii błędów, zajrzyjcie do tekstu ile kosztują testy oprogramowania.

Na co wydajecie pieniądze, gdy testujecie oprogramowanie?

Budżet testów rozkłada się na cztery grupy kosztów i tylko jedna z nich jest dobrze widoczna w arkuszu, czyli wynagrodzenia. Pozostałe trzy chowają się w czasie zespołu developerskiego, w infrastrukturze i w kalendarzu wydań, dlatego firmy regularnie je niedoszacowują.

Narzędzia open source, takie jak Selenium czy Playwright, nie mają licencji, ale nie są darmowe: płacicie za nie czasem na framework, utrzymanie i stabilizację testów. Porównanie własnego zespołu z outsourcingiem na liczbach znajdziecie w artykule koszt zespołu QA: własny zespół czy outsourcing, a w tym tekście zostajemy przy pytaniu, kiedy te wydatki wracają w postaci oszczędności.

Ile kosztuje błąd wykryty późno według badań?

Najczęściej cytowane dane o koszcie późnego błędu pochodzą z raportu amerykańskiego instytutu NIST z 2002 roku. Według raportu NIST Planning Report 02-3 roczny koszt niewystarczającej infrastruktury do testowania oprogramowania w gospodarce USA wynosił 59,5 mld dolarów, z czego 22,2 mld dolarów dało się odzyskać realnymi usprawnieniami. Ten sam raport podaje, że około 60 procent tych kosztów ponosili użytkownicy oprogramowania, a około 40 procent jego producenci.

Raport pokazuje też, jak rośnie koszt poprawki błędu wprowadzonego na etapie wymagań i architektury, gdy zostaje wykryty coraz później. Autorzy wprost oznaczają tabelę 5-1 jako przykład, a nie pomiar z jednego projektu, i warto to powtarzać za każdym razem, gdy ktoś pokazuje ją na slajdzie.

Dla porównania raport NIST cytuje w tabeli 1-5 klasyczne zestawienie Barry’ego Boehma z 1976 roku, w którym poprawka w fazie testów systemowych kosztuje 5Y, a w fazie testów instalacyjnych 15Y, przy 0,2Y na etapie wymagań. W tej samej tabeli dane Baziuka z 1995 roku dla telekomunikacji dochodzą do 880X w utrzymaniu. Rozrzut między źródłami jest ogromny i to jest najważniejsza informacja z całej tabeli: mnożnik zależy od branży i rodzaju produktu.

Skala problemu nie zmalała. Według raportu CISQ z 2022 roku koszt słabej jakości oprogramowania w USA wyniósł co najmniej 2,41 bln dolarów, a skumulowany dług techniczny około 1,52 bln dolarów. Szerzej o tym, jak rozkładać koszt jakości na kategorie, piszemy w artykule ile kosztuje jakość oprogramowania.

Czy mnożnik „100 razy drożej” ma pokrycie w danych?

Mnożnik „100 razy” najczęściej przypisuje się instytutowi IBM Systems Sciences Institute, ale cytowania zwykle kończą się na innych cytowaniach, a nie na opublikowanych danych. Laurent Bossavit w książce The Leprechauns of Software Engineering (Leanpub, 2017) poświęca historii wykresów kosztu defektów cały rozdział 10 i zadaje w nim proste pytanie: gdzie są dane? Odpowiedź bywa niewygodna, bo wiele slajdów kopiuje krzywą, której nikt nie zmierzył w opisanych warunkach.

Co z tego wynika dla Was? Sama poprawka w kodzie, wykryta tydzień później w nowoczesnym pipeline CI, często nie jest dużo droższa. Drogie jest co innego: błąd w wymaganiu, który rozlał się na pięć modułów, błąd w architekturze oraz błąd, który dotarł do użytkowników. W tym ostatnim przypadku płacicie nie programiście, tylko klientom, zespołowi wsparcia i działowi sprzedaży, co dobrze zgadza się z podziałem 60 do 40 z raportu NIST.

Gdzie wczesne testowanie daje realne oszczędności?

Z naszego doświadczenia oszczędności z wczesnego testowania pojawiają się w czterech miejscach i warto je rozdzielić, bo każde mierzy się inaczej. Sylabus ISTQB Certified Tester Foundation Level 4.0 z 2023 roku formułuje to jako trzecią zasadę testowania: wczesne testowanie oszczędza czas i pieniądze, bo defekt usunięty wcześnie nie wywołuje kolejnych defektów w produktach pracy pochodnych.

Najlepiej widać to na projekcie, który znamy od środka. W projekcie dla Argos, sieci e-commerce, zbudowaliśmy automatyzację testów i uporządkowaliśmy procesy QA. Według danych potwierdzonych przez klienta 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, awarii w okresach szczytowych było o 72 procent mniej, a konwersja wzrosła o 12 procent dzięki stabilności checkoutu i płatności.

Zwróćcie uwagę, że żadna z tych liczb nie jest „kosztem poprawki błędu”. To skrócony czas do wydania, mniej incydentów i więcej sprzedaży. Tak wyglądają oszczędności, które zarząd rozumie bez tłumaczenia mnożników. Jak doszliśmy do skrócenia regresji, opisujemy krok po kroku w tekście jak skrócić testy regresyjne z 5 dni do 10 godzin, a samą usługę znajdziecie na stronie automatyzacja testów.

Jak policzyć koszty testowania oprogramowania i zwrot w Waszym projekcie?

Zamiast mnożnika potrzebujecie prostego rachunku na danych, które już macie w Jirze, w CI i w raportach wsparcia. Poniżej wzór, który stosujemy u naszych klientów przy rozmowie o budżecie testów, i przykład na liczbach umownych. Liczby w przykładzie nie pochodzą z żadnego projektu, służą tylko pokazaniu mechaniki: podstawcie własne.

Dwie zasady, które ratują taki rachunek przed zarzutem naciągania. Po pierwsze, spadek incydentów przyjmujcie ostrożnie i weryfikujcie po kwartale na prawdziwych danych. Po drugie, liczcie utrzymanie testów automatycznych, bo bez niego wynik jest zawyżony. Arkusz, który pokazuje zwrot w trzy tygodnie bez kosztów utrzymania, to nie business case, tylko optymizm z formułą. Liczenia zwrotu z testów krok po kroku uczymy na szkoleniu jak mierzyć ROI z procesów testowych, a metryki, które warto zbierać od pierwszego dnia, opisujemy w artykule jak mierzyć jakość oprogramowania.

Kiedy wczesne testy opłacają się mniej, niż obiecują slajdy?

Uczciwy rachunek pokazuje też sytuacje, w których wczesne inwestowanie w testy zwraca się słabo albo wcale. Dobrze je znać, zanim ktoś na zarządzie zapyta, dlaczego automatyzacja prototypu kosztowała więcej niż sam prototyp.

Więcej o tym, kiedy automatyzacja przepala budżet, przeczytacie w tekście o zaletach i wadach automatyzacji testów. Z kolei pełną metodę przesuwania testów na wcześniejsze etapy, krok po kroku, opisuje artykuł shift left testing.

Od czego zacząć w najbliższym sprincie?

Nie musicie przebudowywać całego procesu, żeby zobaczyć pierwszy efekt. Te pięć kroków da się wdrożyć w jednym sprincie i za kwartał porównać z danymi sprzed zmiany.

1. Przegląd wymagań z testerem. Godzina na historyjki przed sprintem, z pytaniem „jak to sprawdzimy?” przy każdym kryterium akceptacji.
2. Pomiar punktu wyjścia. Czas regresji, liczba incydentów produkcyjnych na wydanie i odsetek błędów znalezionych dopiero przez użytkowników.
3. Testy API w CI dla jednej krytycznej ścieżki. Na przykład płatność albo logowanie, uruchamiane przy każdym scaleniu zmian.
4. Lista regresji według ryzyka. Najpierw to, co zarabia pieniądze i co psuło się w ostatnich wydaniach.
5. Przegląd po kwartale. Te same metryki co na starcie, liczone tą samą metodą.

Jeśli wolicie, żeby ktoś z zewnątrz spojrzał na Wasz proces i wskazał, gdzie testy zwrócą się najszybciej, służy do tego audyt QA. Szersze spojrzenie na koszty utrzymania znajdziecie też na portalu Strefa QA, w tekście o tym, jak obniżyć koszty utrzymania oprogramowania dzięki lepszemu QA.

Powiązane na blogu Quality Island

• Ile kosztują testy oprogramowania: cennik i czynniki ceny
• Ile kosztuje jakość oprogramowania
• Shift left testing: co to jest i jak wdrożyć krok po kroku
• Jak skrócić testy regresyjne z 5 dni do 10 godzin: case Argos
• Koszt zespołu QA: własny zespół czy outsourcing?

Pełna lista źródeł

• NIST, The Economic Impacts of Inadequate Infrastructure for Software Testing, Planning Report 02-3, 2002. Tabela ES-4 (59,5 i 22,2 mld dolarów, podział 60 do 40), tabela 1-5 (Boehm 1976, Baziuk 1995), tabela 5-1 (przykład 1X do 30X).
• CISQ, The Cost of Poor Software Quality in the US: A 2022 Report, 2022. Co najmniej 2,41 bln dolarów, dług techniczny około 1,52 bln dolarów.
• T. Menzies, W. Nichols, F. Shull, L. Layman, Are Delayed Issues Harder to Resolve? Revisiting Cost-to-Fix of Defects throughout the Lifecycle, Empirical Software Engineering, 2017 (wersja wydawcy). 171 projektów z lat 2006 do 2014.
• Laurent Bossavit, The Leprechauns of Software Engineering, Leanpub, 2017. Rozdział 10: The cost of defects, an illustrated history.
• ISTQB, Certified Tester Foundation Level, sylabus v4.0, 2023. Zasada 3: wczesne testowanie oszczędza czas i pieniądze.
• Quality Island, dane własne: case study Argos (regresja z 5 dni do 10 godzin, −46% błędów krytycznych, −72% awarii w szczycie, +12% konwersji), stan na 2026.