Skupmy się bardziej na jakości, a mniej na testowaniu: ile kosztuje jakość oprogramowania

Koszt jakości oprogramowania to suma pieniędzy, które firma wydaje na zapobieganie błędom, na ich wykrywanie oraz na skutki błędów, które przeszły dalej. Skupić się bardziej na jakości, a mniej na testowaniu, znaczy przesunąć część tego budżetu z wykrywania na zapobieganie. Testy nadal są potrzebne, ale przestają być jedynym miejscem, w którym organizacja dowiaduje się, że coś poszło źle.

Ten tekst jest dla CTO, Head of QA i osób, które zatwierdzają budżet na jakość. Pokazujemy, ile według dostępnych badań kosztuje słaba jakość, z czego składa się koszt jakości, dlaczego dokładanie testów często go nie obniża, jak policzyć efekt jednej zmiany procesu i co wynika z naszych projektów dla Argos i PKO BP.

Co znaczy skupić się na jakości, a nie na testowaniu?

Testowanie odpowiada na pytanie, czy w produkcie są błędy. Jakość odpowiada na pytanie, dlaczego te błędy w ogóle powstały i co zrobić, żeby powstawało ich mniej. Organizacja skupiona na testowaniu mierzy liczbę przypadków testowych i znalezionych defektów. Organizacja skupiona na jakości mierzy, ile defektów dociera do klienta, ile kosztuje ich naprawa i na którym etapie najczęściej powstają.

To nie jest spór „testerzy kontra reszta zespołu”. W dobrze ułożonym procesie testerzy pracują wcześniej i szerzej: zadają pytania przy wymaganiach, pomagają ustalić kryteria akceptacji, budują automatyzację, która daje szybką informację zwrotną. Kto w takim modelu odpowiada za jakość, rozpisujemy w artykule kto naprawdę odpowiada za jakość oprogramowania.

Ile kosztuje słaba jakość oprogramowania?

Najczęściej cytowane szacunki pochodzą z USA, bo tam powstały największe badania. Raport CISQ „The Cost of Poor Software Quality in the US: A 2022 Report”, którego autorem jest Herb Krasner, szacuje koszt słabej jakości oprogramowania w USA w 2022 roku na co najmniej 2,41 biliona dolarów, a skumulowany dług technologiczny na około 1,52 biliona dolarów. Starszy raport NIST z 2002 roku szacował roczny koszt niewystarczającej infrastruktury testowania na 22,2 do 59,5 miliarda dolarów.

Liczby z USA nie przekładają się wprost na Waszą firmę, ale pokazują proporcje. Najważniejsza z nich dotyczy czasu: w tabeli 5-1 raportu NIST z 2002 roku błąd znaleziony przy wymaganiach kosztuje 1 jednostkę, przy kodowaniu 5, w testach integracyjnych i systemowych 10, w testach beta 15, a po wydaniu 30. NIST zaznacza, że to przykład poglądowy. Kierunek potwierdza jednak każdy, kto naprawiał błąd płatności w szczycie sprzedaży. Szerzej o tym, jak wczesne testowanie przekłada się na oszczędności, piszemy w artykule koszty i oszczędności testowania oprogramowania.

Z czego składa się koszt jakości oprogramowania?

Koszt jakości opisuje się zwykle w czterech kategoriach, znanych z zarządzania jakością w produkcji i opisywanych między innymi w podręczniku zarządzania operacjami na platformie LibreTexts. Dwie pierwsze to koszt zgodności, czyli pieniądze wydane, żeby było dobrze. Dwie kolejne to koszt niezgodności, czyli pieniądze wydane, bo było źle. Poniżej przełożyliśmy je na realia zespołu, który wytwarza oprogramowanie.

Testowanie w tej tabeli należy do kategorii „ocena”. To ważne, bo wiele firm próbuje obniżyć koszty błędów wewnętrznych i zewnętrznych, dokładając wyłącznie ocenę. Tymczasem największa dźwignia leży zwykle w prewencji, która w budżetach jest najmniej widoczna, bo nie ma osobnej pozycji. Gdyby straż pożarna była rozliczana tylko z liczby ugaszonych pożarów, nikt nie dałby jej pieniędzy na przegląd instalacji elektrycznej.

Dlaczego więcej testów nie poprawia jakości?

Dokładanie testów pomaga do pewnego momentu, potem zaczyna przynosić coraz mniej. Powodów jest kilka i wszystkie widzimy w audytach, które prowadzimy w zespołach klientów.

• Testy nie naprawią złego wymagania. Jeśli wymaganie mówi coś innego, niż chciał biznes, test przejdzie na zielono, a klient i tak będzie niezadowolony.
• Duża regresja spowalnia wydania. Każdy nowy test ręczny wydłuża cykl. Zespół zaczyna wydawać rzadziej i większymi paczkami, a duże paczki niosą więcej ryzyka.
• Testy bez analizy przyczyn powtarzają ten sam błąd. Defekt znaleziony, naprawiony i zamknięty wróci w innym module, jeśli nikt nie zapyta, dlaczego powstał.
• Liczba testów jest złą metryką. Tysiąc testów, które sprawdzają to samo, daje mniej informacji niż sto dobrze dobranych. Jak wybrać metryki, które mówią coś o jakości, opisujemy w tekście jak mierzyć jakość oprogramowania.

Nie znaczy to, że testów ma być mniej. Znaczy, że każda złotówka dołożona do oceny powinna mieć uzasadnienie w ryzyku, a część budżetu powinna trafić do prewencji. To podejście ma swoją nazwę, shift left, i opisujemy je krok po kroku w artykule shift left testing: zalety, wady i wdrożenie.

Gdzie budować jakość: wymagania, projekt, kod?

Jakość buduje się na trzech etapach, zanim ktokolwiek uruchomi pierwszy test systemowy.

Wymagania. Jedna z najtańszych praktyk prewencji to Three Amigos. Agile Alliance opisuje ją jako spojrzenie na fragment pracy z trzech perspektyw: biznesu („jaki problem rozwiązujemy?”), wytwarzania („jak zbudujemy rozwiązanie?”) i testowania („a co, jeśli…?”). Według słownika Agile Alliance termin w tym znaczeniu spopularyzował George Dinwiddie w 2009 roku. Trzy osoby, kilkanaście minut przy każdej historyjce przed jej startem, a w efekcie kryteria akceptacji, które da się sprawdzić. Formalną wersję tej praktyki ćwiczycie na szkoleniu Behavior Driven Development (BDD) w praktyce.

Projekt. Architektura dzielona na moduły z jasnymi interfejsami jest łatwiejsza do przetestowania i tańsza w zmianach. Pomagają w tym zasady SOLID. Warto nazywać je poprawnie: to nie wzorzec projektowy, tylko pięć zasad projektowania klas, które Robert C. Martin opisuje jako „principles of class design”: pojedyncza odpowiedzialność, otwarte i zamknięte, podstawienie Liskov, segregacja interfejsów i odwrócenie zależności. Wzorce projektowe, takie jak strategia czy fabryka, to osobna kategoria rozwiązań.

Kod. Code review, analiza statyczna w potoku CI i testy jednostkowe pisane razem z kodem łapią błędy w momencie, w którym ich naprawa kosztuje najmniej. Jeśli rozważacie podejście test first, zacznijcie od artykułu 5 kroków do wdrożenia Test Driven Development.

Jak policzyć efekt jednej zmiany procesu?

Zarząd nie kupi hasła „jakość od początku”. Kupi rachunek. Najprościej policzyć efekt jednej zmiany, porównując dwa okresy o podobnej liczbie wydań. Poniżej sposób liczenia dla wprowadzenia Three Amigos przy refinemencie. Liczby w przykładzie są umowne i służą tylko pokazaniu metody, podstawcie własne z systemu zgłoszeń.

Ten sam schemat działa dla analizy statycznej, przeglądów kodu albo przeniesienia części testów do potoku CI. Kluczowe są dwie rzeczy: kategoria przyczyny w każdym zgłoszeniu defektu i jeden właściciel pomiaru. Bez nich rozmowa o jakości z zarządem zostaje na poziomie wrażeń.

Co pokazują projekty Argos i PKO BP?

W projekcie dla Argos z branży e-commerce zakres obejmował automatyzację testów i uporządkowanie procesów QA, czyli jednocześnie ocenę i prewencję. Efekty, potwierdzone przez klienta, widać w czterech liczbach.

Dla decydenta najciekawsza jest trzecia liczba. Wzrost konwersji o 12 procent nie wynika z testów jako takich, tylko z tego, że checkout i płatności przestały zawodzić w momentach, w których klienci najchętniej kupują. To przykład kosztu błędów zewnętrznych zamienionego w przychód. Pełny opis przebiegu znajdziecie w case study jak skrócić testy regresyjne z 5 dni do 10 godzin.

W PKO BP praca zaczęła się od strony prewencji. Zakres obejmował audyt istniejących procesów QA, opracowanie i wdrożenie strategii jakości oprogramowania dla całej organizacji oraz szkolenia i warsztaty dla zespołów QA. Ten projekt opisujemy zakresem prac, a nie liczbami. Ważny jest kierunek: w sektorze regulowanym jakość zaczyna się od strategii i jasnych zasad, a nie od dokładania kolejnych testerów. Szczegóły opisujemy w artykule audyt QA w sektorze regulowanym: case PKO BP.

Od czego zacząć jako CTO albo Head of QA?

Z naszego doświadczenia przeniesienie akcentu z testowania na jakość zajmuje kilka kwartałów, ale pierwsze dane macie po kilku tygodniach. Proponujemy pięć kroków.

1. Policzcie dzisiejszy koszt błędów zewnętrznych. Hotfixy, incydenty, godziny supportu, utracona sprzedaż. Nawet przybliżona liczba zmienia rozmowę o budżecie.
2. Dodajcie przyczynę do każdego zgłoszenia defektu. Wymaganie, projekt, kod, środowisko, dane, konfiguracja. Po miesiącu zobaczycie, gdzie powstaje najwięcej błędów.
3. Wybierzcie jedną praktykę prewencji na największe źródło. Three Amigos dla wymagań, przeglądy i analiza statyczna dla kodu, zasady SOLID i przeglądy architektury dla projektu.
4. Przytnijcie regresję do ryzyka. Automatyzujcie ścieżki krytyczne, usuwajcie testy, które sprawdzają to samo.
5. Zróbcie niezależny przegląd procesu. Spojrzenie z zewnątrz szybciej wskazuje miejsca, w których zespół przyzwyczaił się do strat. Zakres i koszty takiego przeglądu opisujemy w artykule audyt procesów QA: zakres, przebieg, koszty.

Jeśli chcecie ułożyć jakość w całej firmie, a nie w jednym zespole, pomagamy w ramach strategii jakości oprogramowania, a kadrę zarządzającą i liderów szkolimy na szkoleniu zarządzanie jakością w całej organizacji. Więcej o tym, jak lepsze QA obniża koszt utrzymania systemów, przeczytacie na portalu Strefa QA w tekście jak obniżyć koszty utrzymania oprogramowania dzięki lepszemu QA.

Powiązane na blogu Quality Island

• Kto naprawdę odpowiada za jakość oprogramowania?
• Koszty i oszczędności testowania oprogramowania
• Shift left testing: co to jest, zalety, wady i jak wdrożyć
• Jak mierzyć jakość oprogramowania: od opinii do twardych metryk
• Ile kosztują testy oprogramowania: cennik i czynniki ceny

Pełna lista źródeł

• CISQ, Herb Krasner, The Cost of Poor Software Quality in the US: A 2022 Report, 2022. Stąd 2,41 biliona dolarów i 1,52 biliona dolarów długu technologicznego.
• NIST, The Economic Impacts of Inadequate Infrastructure for Software Testing, 2002. Stąd szacunek 22,2 do 59,5 miliarda dolarów, podział 60 do 40 procent i tabela 5-1 z kosztem naprawy według etapu.
• LibreTexts, Introduction to Operations Management, 5.3: Cost of Quality, podręcznik otwarty. Stąd cztery kategorie kosztu jakości.
• Agile Alliance, Glossary: Three Amigos. Stąd definicja praktyki i odniesienie do George’a Dinwiddiego (2009).
• Robert C. Martin, The Principles of OOD. Stąd SOLID jako zasady projektowania klas.
• Dane własne Quality Island, 2026: case study Argos z liczbami potwierdzonymi przez klienta, zakres prac dla PKO BP.