Dług technologiczny pożera nawet 40% budżetu IT: gdzie w tym jest testowanie

Dług technologiczny brzmi jak problem architektów i programistów, coś, co dzieje się w kodzie, daleko od rozmów o budżecie. W praktyce jest to jeden z największych, cichych kosztów w budżecie IT, a testowanie ma w nim rolę, o której rzadko się mówi: to regresja i jej koszt decydują, jak szybko dług technologiczny się spłaca albo narasta. Ten artykuł łączy dwie perspektywy, które zwykle żyją w osobnych rozmowach: finansową CTO i operacyjną zespołu QA, i pokazuje, dlaczego rozdzielanie ich jest błędem kosztującym realne pieniądze. Zanim policzymy, ile to kosztuje konkretnie Was, warto rozłożyć na czynniki pierwsze, czym dług technologiczny właściwie jest i skąd biorą się tak rozbieżne szacunki jego kosztu.

Czym jest dług technologiczny i skąd się biorą tak rozbieżne liczby

Termin dług technologiczny wymyślił w 1992 roku Ward Cunningham, jeden z twórców metodyki Agile, żeby wytłumaczyć zarządowi, dlaczego szybkie, niedopracowane rozwiązanie kosztuje więcej później niż od razu porządne. Metafora jest prosta: każdy skrót w kodzie, dokumentacji albo testach to pożyczka. Ktoś ją kiedyś spłaci w postaci dodatkowej pracy, albo organizacja płaci odsetki w postaci wolniejszego rozwoju, większej liczby błędów i coraz trudniejszych zmian. Ponad trzydzieści lat później ta metafora doczekała się czegoś, czego wtedy brakowało: twardych liczb pokazujących, ile te odsetki faktycznie kosztują.

Warto od razu rozróżnić dwa rodzaje długu technologicznego, bo konsekwencje są inne. Dług świadomy to decyzja: zespół wie, że idzie na skrót, zapisuje to gdzieś i wraca do tego później, najczęściej w ramach zaplanowanego sprintu porządkowego. Dług nieświadomy jest groźniejszy, bo nikt go nie zapisał, powstaje po prostu dlatego, że nikt nie sprawdził, co się stanie, kiedy zmiana w jednym miejscu wpłynie na coś zupełnie innego. Testowanie, a konkretnie regresja, jest jedynym mechanizmem, który zamienia dług nieświadomy w świadomy: pokazuje efekty uboczne, zanim staną się produkcyjnym incydentem, więc zespół w ogóle ma szansę podjąć decyzję, zamiast dowiadywać się o długu po fakcie, od klienta albo z alertu na produkcji.

Deloitte w swoim Global Technology Leadership Study z 2026 roku, opartym na ankiecie ponad 660 CIO, CTO, CISO i CDAO z całego świata, szacuje, że dług technologiczny pochłania od 21 do 40% całkowitych wydatków IT. McKinsey w analizie Tech debt: Reclaiming tech equity idzie dalej: 30% ankietowanych CIO twierdzi, że ponad 20% budżetu technologicznego formalnie przeznaczonego na nowe produkty jest w praktyce przekierowywane na obsługę długu, a większość firm przyznaje się do 10 do 20%. Stripe w swoim Developer Coefficient Report policzył to z zupełnie innej strony, licząc godziny, nie złotówki: 42% czasu pracy profesjonalnych deweloperów idzie na zarządzanie długiem technologicznym i poprawianie złego kodu, nie na tworzenie nowych funkcji. Te trzy liczby, mimo że pochodzą z zupełnie różnych metodologii, ankiety wśród CIO, analizy setek systemów i pomiaru czasu pracy deweloperów, opisują ten sam obraz z trzech różnych stron: budżetowej, decyzyjnej i operacyjnej.

Warto zatrzymać się przy samej rozpiętości między 21 a 40%, bo ona sama w sobie jest sygnałem, nie szumem statystycznym. Firmy bliżej dolnego krańca tego przedziału zwykle mają choćby podstawowy proces zarządzania długiem: świadomość, gdzie on siedzi, i jakiś mechanizm priorytetyzacji spłaty. Firmy bliżej górnego krańca, blisko 40%, zwykle nie mają żadnego z tych dwóch elementów, więc dług narasta bez kontroli, aż staje się głównym kosztem utrzymania systemu, przewyższającym koszt rozwoju nowych funkcji. Innymi słowy, to nie branża ani wielkość firmy decyduje, po której stronie tego przedziału się znajdziecie, tylko to, czy w ogóle macie mechanizm, który mierzy i priorytetyzuje spłatę.

Dlaczego testowanie jest tu ważniejsze, niż się wydaje

Dług technologiczny rzadko powstaje w jednym momencie. Narasta, gdy zespół świadomie idzie na skróty pod presją terminu, obiecując sobie, że posprząta to później. Problem w tym, że „później” wymaga pewności, że sprzątanie nie zepsuje niczego innego, a tej pewności dostarcza tylko dobra regresja. Zespół bez solidnych testów regresyjnych nie ma odwagi ruszyć starego kodu, więc dług technologiczny nie tyle rośnie, co zamraża się w miejscu, coraz droższy w utrzymaniu.

To wyjaśnia liczbę, którą Software Improvement Group liczy per system: przy średnim, w pełni obciążonym koszcie dewelopera na poziomie 150 tysięcy euro rocznie, bezpośredni koszt pracy nad systemem o niskiej jakości utrzymania sięga blisko 870 tysięcy euro rocznie na jeden system. Przy portfolio dziesięciu takich systemów to blisko 9 milionów euro rocznie, w dużej mierze dlatego, że każda zmiana wymaga ostrożnego, ręcznego sprawdzania skutków ubocznych, bo automatyczna regresja jej nie pokrywa. To samo badanie pokazuje też, że systemy o wysokiej jakości utrzymania mają aż o 72% wyższy wskaźnik bezpieczeństwa niż te w najgorszym stanie, co akurat nie powinno dziwić: kod, którego nikt nie odważy się ruszyć, rzadko dostaje też aktualizacje bezpieczeństwa.

Dług technologiczny ma jeszcze jedną, mniej oczywistą konsekwencję: obniża morale zespołu deweloperskiego. Ten sam raport Stripe pokazuje, że 78% deweloperów zgłasza negatywny wpływ pracy nad przestarzałymi systemami na własną motywację. Praca w kodzie, którego nikt nie odważy się dotknąć bez wielogodzinnego, ręcznego sprawdzenia, jest jednym z najczęstszych powodów odejść z zespołów inżynierskich, co dokłada do rachunku koszt rotacji, wcześniej opisanej wyłącznie jako koszt finansowy, teraz także jako koszt talentu. To, co łączy te dwie liczby, przewija się przez cały ten artykuł: bez zaufania do regresji zespół nie ma jak bezpiecznie ruszyć starego kodu, a to zaufanie da się zbudować tylko jednym sposobem, dobrymi testami regresyjnymi. Właśnie temu mechanizmowi warto przyjrzeć się bliżej.

Regresja jako dźwignia: co się zmienia, kiedy zespół jej ufa

Zaufanie do regresji nie jest miękkim pojęciem od dobrego samopoczucia. To konkretna, mierzalna właściwość zestawu testów: jaki procent funkcjonalności pokrywają, jak szybko się wykonują i jak rzadko fałszywie alarmują. Zespół, który ma regresję pokrywającą przypadkowe 30% aplikacji, uruchamianą raz w tygodniu, z testami migającymi na czerwono bez wyraźnego powodu co drugi bieg, nie ma zaufania, nawet jeśli formalnie regresja istnieje. Zespół z regresją pokrywającą krytyczne ścieżki biznesowe, uruchamianą przy każdej istotnej zmianie, ze stabilnymi wynikami, ma zaufanie, a to zaufanie zamienia się bezpośrednio w odwagę do refaktoryzacji.

Dlaczego akurat regresja, a nie na przykład testy jednostkowe albo sam code review? Bo to jedyny poziom testów, który sprawdza system tak, jak go później zobaczy użytkownik, całościowo, po zmianie, nie fragment po fragmencie. Testy jednostkowe potwierdzają, że pojedyncza funkcja robi to, co powinna, w izolacji. Code review potwierdza, że kod jest czytelny i zgodny z konwencją. Żadne z nich nie odpowiada na pytanie, które naprawdę parzy zespół przed wydaniem: czy ta jedna zmiana czegoś nie popsuła gdzie indziej. Na to pytanie odpowiada tylko regresja, i to ona, nie liczba testów jednostkowych, jest tym, co daje zespołowi odwagę do ruszenia starego kodu.

Najlepszym dowodem na ten mechanizm jest nasz własny projekt u klienta Argos, sklepu e-commerce. Zanim zaczęliśmy, regresja przed każdym większym wydaniem trwała pięć dni, więc zespół naturalnie wydawał rzadziej i ostrożniej, odkładając zmiany, które i tak trzeba było kiedyś zrobić. Po uporządkowaniu automatyzacji regresja skróciła się do dziesięciu godzin. To samo wdrożenie dało spadek liczby błędów krytycznych na produkcji o 46%, redukcję awarii w okresach szczytowych o 72% i wzrost konwersji o 12%, bo stabilny checkout i płatności to bezpośrednio więcej dokończonych transakcji. Żadna z tych czterech liczb nie jest efektem magii, tylko tego samego mechanizmu: krótsza, wiarygodna regresja dała zespołowi odwagę, żeby ruszyć kod, którego wcześniej nikt nie chciał dotykać.

To dokładnie ten sam mechanizm, tylko patrzony od strony pieniędzy, stoi za liczbą Software Improvement Group z poprzedniej sekcji: system bez dobrej regresji kosztuje więcej w utrzymaniu, bo każda zmiana wymaga drogiego, ręcznego sprawdzenia skutków ubocznych zamiast tańszego, automatycznego. Dług technologiczny i jakość regresji to w praktyce dwie strony tego samego rachunku, nie dwa osobne tematy dla dwóch osobnych zespołów.

AI przyspiesza dług szybciej, niż rośnie pokrycie testami

Forrester w swoich prognozach technologicznych i bezpieczeństwa szacuje, że u 75% decydentów technologicznych dług osiągnie do końca 2026 roku umiarkowany lub wysoki poziom dotkliwości, w dużej mierze z powodu tempa wdrażania rozwiązań opartych na AI. Mechanizm jest prostszy, niż mogłoby się wydawać. Narzędzia takie jak Cursor, Claude Code czy Copilot potrafią wygenerować w godzinę tyle kodu, ile wcześniej zespół pisał w tydzień. Problem w tym, że tempo pisania testów i przeglądu kodu nie przyspieszyło w tym samym tempie, więc powstaje coraz większa luka między tym, ile kodu trafia do repozytorium, a tym, ile z niego jest realnie sprawdzone.

Ta luka ma konkretną nazwę roboczą w naszych rozmowach z klientami: dług przeglądowy. Kod wygenerowany przez AI często wygląda poprawnie, bo model dobrze naśladuje styl i konwencje projektu, ale poprawny styl to nie to samo co poprawna logika biznesowa. Zespół, który nie inwestuje równolegle w automatyzację testów, w praktyce zwiększa tempo zaciągania długu, nie zmniejsza go, mimo że subiektywnie czuje się bardziej produktywny. To dokładnie ta pułapka, o której mówi czwarta teza w naszej opinii niżej.

W praktyce wygląda to tak: inżynier prosi asystenta AI o dodanie nowej funkcji, dostaje działający kod w kilka minut, wrzuca go do pull requesta, a recenzent, zalany liczbą takich requestów, sprawdza głównie styl i strukturę, bo na dogłębną analizę logiki po prostu nie ma czasu przy takim tempie. Kod trafia na produkcję, działa poprawnie w typowych scenariuszach i wygląda na sukces, dopóki ktoś nie trafi na przypadek brzegowy, którego ani model, ani recenzent nie przewidzieli. Bez regresji, która automatycznie sprawdza te przypadki brzegowe za każdym razem, ten scenariusz powtarza się po cichu, tydzień po tygodniu, aż dług osiągnie poziom, przy którym nikt już nie pamięta, które z tych szybko wygenerowanych fragmentów kodu w ogóle ktoś porządnie przetestował.

Odpowiedzią nie jest zwolnienie tempa generowania kodu, bo to walka z wiatrakami. Odpowiedzią jest to samo, o czym była mowa wyżej: automatyzacja testów, która nadąża za tempem zmian, bo tylko ona potrafi w rozsądnym czasie odpowiedzieć na pytanie, czy kod wygenerowany godzinę temu faktycznie działa tak, jak powinien, zanim trafi na produkcję.

Co z tych liczb wynika naszym zdaniem

Jak to wygląda w praktyce, kiedy sprawdzamy to u klienta

Nie sprzedajemy usługi o nazwie audyt długu technologicznego, bo takiej pozycji nie ma w naszej ofercie. Sprzedajemy audyt QA, ale mechanizm, który tam sprawdzamy, jest dokładnie ten, o którym pisaliśmy wyżej: nie liczymy linii kodu ani nie szacujemy długu w walucie, tylko sprawdzamy, czy zespół ma realne zaufanie do swojej regresji, czy tylko formalny, checklistowy proces, który nikogo nie chroni. Pisaliśmy o tym szerzej w tekście Audyt jakości oprogramowania. Kiedy jakość przestaje być pewnikiem, a zaczyna być ryzykiem.

Zakres tej pracy wygląda różnie w zależności od branży. Dla PKO BP opracowaliśmy i wdrożyliśmy strategię jakości oprogramowania dla całej organizacji razem z audytem istniejących procesów QA i szkoleniami dla zespołów, dokładnie dlatego, że w bankowości dług technologiczny nie jest tylko kosztem, jest też ryzykiem regulacyjnym. Dla ChaosGears, firmy z branży medycznej, budowaliśmy dokumentację testową i odbiorczą razem z procesami automatyzacji, bo tam błąd w regresji nie kończy się reklamacją, tylko realnym ryzykiem dla pacjenta. W obu przypadkach punktem wyjścia było dokładnie to samo pytanie, które opisujemy w kroku pierwszym niżej: ile realnie kosztuje brak zaufania do testów, zanim zaczniemy cokolwiek naprawiać.

Tam, gdzie dług jest już duży i rozproszony po wielu systemach, samego audytu nie wystarczy, potrzeba też uporządkowania procesu, który go generuje, czyli tego, co u nas nazywa się TestOps i QualityOps: spięcia testowania, automatyzacji i CI/CD w jeden spójny system, zamiast trzech osobnych wysp, które nie rozmawiają ze sobą.

Zanim zaczniemy cokolwiek naprawiać, pierwszy krok audytu wygląda właśnie tak, jak opisaliśmy w sekcji o skali problemu: nie liczymy długu dla całej organizacji jedną liczbą, tylko system po systemie, bo to tam, w konkretnym, często najstarszym systemie, koncentruje się większość kosztu. Dopiero taka mapa pozwala odpowiedzieć na pytanie, które naprawdę interesuje zarząd: który system spłacić najpierw, żeby zwrot z tej pracy był najszybszy, a nie który system jest teoretycznie najstarszy albo najbrzydszy w kodzie. Dla CTO ten temat jest przede wszystkim pytaniem budżetowym: ile z tegorocznego planu rozwoju faktycznie idzie na spłatę czegoś, czego nikt nie planował. Dla Head of QA to pytanie o mandat: czy zespół testowy ma realny wpływ na to, które systemy dostają priorytet w spłacie długu, czy tylko odhacza checklisty po fakcie. Oba pytania prowadzą do tego samego rachunku, opisanego niżej.

Jak policzyć, ile Wam to kosztuje

Źródło: opracowanie własne Quality Island, metoda stosowana w naszych audytach QA.

Ten sam rachunek warto zrobić osobno dla każdego systemu w portfolio, nie zbiorczo dla całej organizacji. Dług technologiczny rzadko jest rozłożony równomiernie: zwykle jeden lub dwa systemy, często te najstarsze albo te, które przeszły najwięcej zmian właściciela produktu, koncentrują większość kosztu. Audyt, który traktuje cały portfel jako jedną liczbę, ukrywa właśnie te systemy, które najbardziej zasługują na priorytetową interwencję. Dokładnie to zrobiliśmy w Argos: policzyliśmy, ile godzin zespół tracił na ręczną regresję, ile z tych godzin zniknęłoby przy dobrej automatyzacji, i dopiero ta konkretna liczba, nie ogólne przeczucie, uzasadniła budżet na automatyzację.

Najczęściej zadawane pytania o dług technologiczny

Czy dług technologiczny da się całkowicie wyeliminować?

Nie, i to nie jest realny cel. Dług technologiczny w rozsądnej ilości jest naturalnym efektem tempa rozwoju produktu. Celem nie jest zejście do zera, tylko utrzymanie go na poziomie, który nie przekracza możliwości zespołu do bezpiecznej spłaty, mierzonej jakością regresji.

Ile powinna wynosić spłata długu technologicznego w budżecie kwartalnym?

Nie ma jednej uniwersalnej liczby, ale punktem odniesienia są dane z tego artykułu: skoro dług technologiczny pochłania średnio 21 do 40% budżetu IT bez świadomego zarządzania, firmy z dojrzałym procesem trzymają się bliżej dolnej granicy. Konkretną liczbę dla siebie policzycie metodą z sekcji „Jak policzyć, ile Wam to kosztuje” wyżej.

Czy dług technologiczny to to samo co zły kod?

Nie. Zły kod jest jedną z przyczyn długu, ale dług powstaje też świadomie, jako racjonalny kompromis pod presją terminu. Różnica jest praktyczna: zły kod naprawia się refaktoryzacją, dług technologiczny zarządza się priorytetyzacją spłaty, opartą na regresji, która pokazuje, co bezpiecznie można ruszyć.

Od czego zacząć, jeśli nie mamy dziś żadnych danych o własnym długu?

Od jednego pomiaru z sekcji „Jak policzyć, ile Wam to kosztuje”: ile godzin miesięcznie zespół traci na ręczne sprawdzanie skutków ubocznych zmian. Ta jedna liczba, bez żadnych innych danych, już wystarcza, żeby zacząć rozmowę o priorytetach, a przy okazji audytu QA sprawdzamy ją razem z Wami.

Powiązane na blogu Quality Island

• KPI dla zarządu: jak przełożyć wyniki QA na język, który rozumie CFO
• Koszty i oszczędności testowania oprogramowania
• Opłacalność testowania oprogramowania
• Audyt jakości oprogramowania

Pełna lista źródeł

• Deloitte, Global Technology Leadership Study 2026
• McKinsey & Company, Tech debt: Reclaiming tech equity
• Stripe, The Developer Coefficient Report
• Forrester, Technology & Security Predictions
• Software Improvement Group, Cost of Technical Debt