Regresja przed releasem: ile kosztuje dzień opóźnienia wydania

Regresja przed wydaniem trwa u was pięć dni. Wszyscy to wiedzą, nikt tego nie kwestionuje, bo „tyle trwa przejście przez wszystkie scenariusze”. Pytanie, które rzadko pada na spotkaniu planistycznym, brzmi: ile kosztuje każdy z tych pięciu dni. Nie w godzinach testerów, te są w budżecie. W pieniądzach, których firma nie zarabia, bo funkcja czeka na wydanie, w ryzyku, które rośnie, bo wydanie robi się większe, i w czasie reakcji na awarię, który wydłuża się dokładnie o tyle, ile trwa regresja. Donald Reinertsen, autor klasycznej książki o przepływie w rozwoju produktów, pisał: „jeśli macie policzyć tylko jedną rzecz, policzcie koszt opóźnienia”. Ten artykuł pokazuje, jak to zrobić dla regresji, na publicznych danych i na jednym realnym przypadku, w którym pięć dni zamieniło się w dziesięć godzin.

Regresja jako podatek od każdego wydania

Zacznijmy od mechanizmu, bo bez niego rachunek nie ma sensu. Jeśli pełna regresja trwa pięć dni roboczych, to nie da się wydawać częściej niż raz na tydzień, a w praktyce, po doliczeniu poprawek i ponownych testów, raz na dwa do czterech tygodni. Zespół dostosowuje się do tego rytmu: zmiany czekają na „okno wydania”, paczka rośnie, a im większa paczka, tym więcej rzeczy może się w niej zepsuć i tym trudniej znaleźć, która zmiana zepsuła co. Regresja, która miała chronić przed ryzykiem, staje się przyczyną, dla której ryzyko rośnie.

Raport DORA 2024, oparty na ankiecie około 3 000 osób, opisuje ten mechanizm liczbami. Organizacje z najwyższego klastra wydajności wdrażają na żądanie, mają czas od zmiany w kodzie do produkcji poniżej jednego dnia i odsetek wdrożeń kończących się awarią na poziomie 5 procent. Organizacje z najniższego klastra wdrażają raz na miesiąc do raz na pół roku, czas realizacji zmiany liczą w miesiącach, a awarią kończy się 40 procent ich wdrożeń. Rzadsze wydania nie są bezpieczniejsze. Są osiem razy bardziej awaryjne, właśnie dlatego, że każde niesie więcej zmian naraz.

Pięciodniowa regresja nie wpycha automatycznie do klastra „low”, ale skutecznie blokuje drogę do „high” i „elite”, bo tam czas od zmiany do produkcji liczy się w dniach, a nie da się mieć jednodniowego czasu realizacji, gdy sama regresja trwa pięć. Pisaliśmy już o tym, jak w dużych projektach przestać bać się każdego wdrożenia. Tutaj chodzi o coś innego: o to, ile ten strach kosztuje w złotych.

Trzy koszty opóźnienia, których nie ma w budżecie QA

Godziny testerów są w budżecie i zwykle to jedyny koszt regresji, jaki firma liczy. Trzy pozostałe koszty są większe, ale rozproszone po innych działach, więc nikt ich nie sumuje.

Pierwszy to koszt niewydanej wartości. Funkcja, która ma przynieść przychód albo oszczędność, nie przynosi ich, dopóki nie jest na produkcji. Jeśli regresja wydłuża czas do wydania o tydzień, firma traci tydzień wartości tej funkcji, a przy comiesięcznych oknach wydania średnia zmiana czeka na okno dodatkowo dwa tygodnie. To jest dokładnie koszt opóźnienia w rozumieniu Reinertsena i to jest liczba, którą zna właściciel produktu, nie zespół QA. Wystarczy go zapytać, ile miesięcznie ma przynieść funkcja, i podzielić przez dni.

Drugi to koszt paczki. Rzadkie wydania są większe, a większe wydania częściej kończą się awarią, co pokazuje różnica między 5 a 40 procentami w tabeli wyżej. Koszt awarii wdrożenia to nie tylko koszt jej naprawy. To także czas zespołu, który zamiast rozwijać produkt, szuka, która z trzydziestu zmian w paczce zepsuła koszyk, i koszt wycofania całej paczki, w tym zmian, które były w porządku.

Trzeci to koszt czasu reakcji na incydent. Gdy na produkcji pojawia się krytyczny błąd, poprawka musi przejść regresję albo ją ominąć. Jeśli regresja trwa pięć dni, firma wybiera między pięcioma dniami z błędem na produkcji a poprawką wypuszczoną bez sprawdzenia, co jest dokładnie tym scenariuszem, z którego biorą się kolejne awarie. Według badania ITIC z 2024 roku, na próbie ponad 1 000 firm, godzina przestoju kosztuje ponad 300 tysięcy dolarów w ponad 90 procentach średnich i dużych przedsiębiorstw, a w 41 procentach od miliona do ponad pięciu milionów. Nie każdy błąd krytyczny to pełny przestój, ale w e-commerce błąd w checkoucie jest przestojem przychodu, nawet gdy strona działa.

Rachunek na przykładzie, z jawnymi założeniami

Policzmy to dla hipotetycznej firmy, żeby pokazać metodę. Wszystkie liczby poniżej są założeniami do rachunku, nie danymi z rynku, i każdą trzeba podmienić na własną. Załóżmy sklep internetowy, który wydaje raz na cztery tygodnie, bo pełna regresja trwa pięć dni i nikt nie chce jej robić częściej. W każdym wydaniu jest jedna funkcja, która według właściciela produktu ma przynieść 100 000 zł miesięcznie dodatkowego przychodu, na przykład nowa metoda płatności albo uproszczony koszyk.

Koszt niewydanej wartości: przy oknach co cztery tygodnie gotowa funkcja czeka średnio dwa tygodnie na okno, a potem pięć dni na regresję. Trzy tygodnie opóźnienia przy 100 000 zł miesięcznie to około 75 000 zł niezarobionego przychodu na jedną funkcję. Gdyby regresja trwała dzień, a wydania były cotygodniowe, średnie czekanie spadłoby do około czterech dni, czyli do około 13 000 zł. Różnica: ponad 60 000 zł na każdą funkcję o tej wartości, dwanaście razy w roku.

Koszt paczki: przy wydaniu raz na miesiąc paczka zawiera cztery tygodnie zmian. Jeśli przyjmiemy za DORA, że rzadkie, duże wydania kończą się awarią kilka razy częściej niż małe, to nawet bez wyceny pojedynczej awarii widać, gdzie leży ryzyko. Przy czterech awariach rocznie i dwóch dniach zespołu na każdą, to osiem dni pracy całego zespołu, których nie ma w żadnym budżecie.

Koszt reakcji: jeden krytyczny błąd w checkoucie rocznie, który przy pięciodniowej regresji zostaje na produkcji przez dwa dni robocze, zanim poprawka przejdzie skróconą ścieżkę. Jeśli sklep robi 50 000 zł dziennie, a błąd blokuje 20 procent transakcji, to 20 000 zł straty za każdy dzień. Przy regresji liczonej w godzinach ten sam błąd żyje na produkcji kilka godzin, nie dni.

Ten rachunek celowo nie sumuje się do jednej liczby, bo trzy koszty mają różne źródła i różnych właścicieli w organizacji. Ważne jest coś innego: w każdej z trzech pozycji koszt regresji liczonej w dniach jest wielokrotnie wyższy niż koszt samych godzin testerów, które są jedyną pozycją widoczną w budżecie QA. Właśnie dlatego skrócenie regresji jest jedną z niewielu inwestycji w jakość, którą da się uzasadnić przed CFO bez odwoływania się do „lepszej jakości”, tylko do dni i złotych.

Z pięciu dni do dziesięciu godzin: co się realnie zmieniło

Teraz przypadek, w którym te liczby nie są założeniem. Dla Argos, firmy z branży e-commerce, przeprowadziliśmy automatyzację testów i uporządkowanie procesów QA. Regresja przed wydaniem skróciła się z pięciu dni do dziesięciu godzin. To jest ta zmiana, o której mówi cały ten artykuł: regresja przestała wyznaczać rytm wydań, bo dziesięć godzin mieści się w jednym dniu roboczym z zapasem, więc wydanie można zrobić wtedy, kiedy jest gotowe, a poprawkę krytyczną tego samego dnia.

Efekty po stronie biznesu, potwierdzone przez klienta: liczba awarii w okresach szczytowych spadła o 72 procent, liczba błędów krytycznych na produkcji o 46 procent, a konwersja wzrosła o 12 procent dzięki stabilności checkoutu i płatności. Warto zwrócić uwagę na kolejność przyczyn. Konwersja nie wzrosła dlatego, że testy były lepsze. Wzrosła dlatego, że checkout przestał się psuć w szczycie, a przestał się psuć dlatego, że wydania stały się mniejsze i częstsze, a każde było sprawdzone w całości w ciągu jednego dnia, nie tygodnia.

Uczciwie: nie każdy projekt kończy się takimi liczbami i nie każda regresja da się skrócić do dziesięciu godzin. Ale mechanizm jest ten sam w każdej firmie, która wydaje oprogramowanie: dopóki regresja trwa dni, jest podatkiem od każdego wydania, i firma płaci go trzy razy, w niewydanej wartości, w paczce i w czasie reakcji. Decyzja, co naprawdę opłaca się zautomatyzować, a co nie, powinna zaczynać się od tego rachunku, nie od listy narzędzi.

Jak policzyć to u siebie w jeden tydzień

Nie potrzebujecie konsultanta, żeby zrobić pierwszy rachunek. Potrzebujecie pięciu liczb, z których każda jest w firmie, tylko w innym dziale.

Źródło: opracowanie własne Quality Island.

Z tych pięciu liczb powstaje tabela taka jak wyżej, tylko z waszymi kwotami w ostatniej kolumnie. Jeśli suma w kolumnie „regresja w dniach” jest wyższa niż roczny koszt automatyzacji regresji, decyzja jest policzona. Jeśli nie jest, też dobrze: wiecie, że regresja nie jest waszym najdroższym problemem i możecie szukać gdzie indziej, na przykład w tym, jak zgrać dev i QA w jednym sprincie.

Nasza perspektywa

W Quality Island automatyzacja testów, w tym regresji, jest naszą podstawową usługą, a ponad 450 000 testów automatycznych napisanych w projektach dla ponad 100 firm nauczyło nas jednego: regresja rzadko jest długa dlatego, że produkt jest duży. Jest długa dlatego, że nikt nigdy nie policzył, ile kosztuje każdy jej dzień, więc nikt nie miał argumentu, żeby ją skrócić. Argument „testerzy będą mieli mniej pracy” nie przekonuje zarządu. Argument „funkcja warta 100 000 zł miesięcznie czeka trzy tygodnie na wydanie” przekonuje.

Drugi wniosek: skrócenie regresji nie polega na zautomatyzowaniu wszystkich scenariuszy. W większości projektów, w których regresja trwa dni, jedna trzecia scenariuszy jest martwa, jedna trzecia sprawdza to samo w różnych wariantach, a dopiero ostatnia trzecia chroni coś, na czym firmie zależy. Uporządkowanie procesu, czyli decyzja, co w ogóle wchodzi do regresji, daje zwykle pierwszą połowę skrócenia, zanim ktokolwiek napisze pierwszy test automatyczny. W projekcie dla Argos zakres obejmował właśnie obie rzeczy naraz: automatyzację i uporządkowanie procesów QA, i to jest kolejność, którą polecamy.

Trzeci wniosek dotyczy tego, kto powinien zrobić rachunek z tego artykułu. Nie zespół QA sam, bo trzy z pięciu liczb ma ktoś inny. Najlepiej działa, gdy Head of QA przynosi na spotkanie zarządu pustą tabelę i prosi o wypełnienie ostatniej kolumny. Na blogu Quality Island opisaliśmy, jak przełożyć wyniki QA na język, który rozumie CFO, i koszt dnia opóźnienia jest w tym języku najprostszym zdaniem.

Powiązane na Strefie QA

• Testy regresyjne w dużych projektach: jak przestać bać się każdego wdrożenia
• Automatyzacja testów: co się naprawdę opłaca automatyzować, a co nie
• DEV i QA w jednym sprincie bez chaosu

Źródła:

• DORA, Accelerate State of DevOps Report 2024
• ITIC, 2024 Hourly Cost of Downtime Survey
• Donald G. Reinertsen, The Principles of Product Development Flow, omówienie koncepcji kosztu opóźnienia (DX)
• Automatyzacja testów, Quality Island