Dlaczego sprint review to za późno na łapanie bugów

Sprint review. Zespół prezentuje klientowi efekty dwutygodniowej pracy. PM klika przez nowe funkcjonalności. Klient kiwa głową. I nagle — „poczekaj, co to jest? Dlaczego ten formularz nie waliduje numeru telefonu?". Albo: „To powinno pokazywać cenę brutto, nie netto". Albo po prostu: biały ekran po kliknięciu Zapisz.

Bug na sprint review to nie jest incydent. To objaw systemowy. Oznacza, że defekt przetrwał cały sprint — od momentu implementacji, przez testowanie, aż do prezentacji. I każdy dzień, który przeleżał w kodzie, powiększył koszt jego naprawy.

Niespodzianka na sprint review

Scenariusz jest zawsze podobny. Feature został zaimplementowany w dniach 2-5 sprintu. Tester przetestował go w dniach 6-8 — i znalazł buga. Ale albo nie zdążył zaraportować (bo raportowanie zajmuje 10-15 minut, a kolejny feature czekał), albo zaraportował, ale developer nie zdążył naprawić (bo bug trafił do niego w dniu 8 z 10). Albo — co jeszcze gorsze — tester znalazł buga, ale zaraportował go na Slacku, i bug po prostu zginął.

Na review wychodzi to, czego nie naprawiono. Klient widzi. I reaguje jednym z trzech sposobów: zdenerwowaniem, rozczarowaniem, albo cichą utratą zaufania. Żaden z nich nie jest dobry dla relacji.

Dlaczego bugi przeżywają do końca sprintu

W typowym dwutygodniowym sprincie testowanie zaczyna się w połowie — bo dopiero wtedy pierwsze feature'y są gotowe do testu. To zostawia testerowi 4-5 dni na testowanie, raportowanie i weryfikację napraw. W teorii wystarczy. W praktyce — rzadko.

Problem leży w oknie czasowym między znalezieniem buga a jego naprawą. Jeśli tester znajdzie buga w dniu 6, a raportowanie zajmie 15 minut, developer dostanie ticket najwcześniej w dniu 6 po południu. Naprawa w dniu 7 lub 8. Retest w dniu 8 lub 9. Ale co, jeśli tester w dniach 7-9 dostaje nowe feature'y do testowania i nie ma czasu na retesty? Bug przechodzi do review nienaprawiony.

Capers Jones w „Applied Software Measurement" (McGraw-Hill, 2008) dokumentuje, że skuteczność usuwania defektów (defect removal efficiency, DRE) w projektach korzystających z Agile wynosi średnio 85%. Oznacza to, że statystycznie 15% znalezionych bugów nie zostaje naprawionych w sprincie. Przy 20 bugach na sprint to 3 bugi, które „przeżywają" do review lub dalej.

Krzywa Boehma: koszt późnego wykrywania

Barry Boehm w „Software Engineering Economics" (Prentice Hall, 1981) opisał zjawisko, które stało się jednym z fundamentów inżynierii oprogramowania: koszt naprawy defektu rośnie wielokrotnie z każdą fazą, w której pozostaje niewykryty. NIST w raporcie „The Economic Impacts of Inadequate Infrastructure for Software Testing" (2002) potwierdził te obserwacje na danych z przemysłu.

Bug znaleziony w dniu 6 i naprawiony w dniu 7 kosztuje 1-2 godziny pracy (developer + retest). Ten sam bug znaleziony na sprint review w dniu 10 trafia do backlogu, czeka na następny sprint, wymaga ponownego kontekstu od developera, który już pracuje nad czymś innym. Koszt: 4-8 godzin. Plus opóźnienie release'u. Plus niezadowolony klient.

Shift left: przesuwanie wykrywania bugów wcześniej

Koncepcja „shift left" — przesuwania aktywności testowych wcześniej w cyklu — jest szeroko dokumentowana w literaturze. Raport DORA „Accelerate: State of DevOps Report" (2023) wskazuje, że zespoły o wysokiej wydajności integrują testowanie wcześnie i często, zamiast odkładać je na koniec sprintu.

Ale „shift left" wymaga jednego warunku: tester musi być w stanie szybko zaraportować buga, żeby developer mógł go naprawić jeszcze tego samego dnia. Jeśli raportowanie zajmuje 10-15 minut, a tester testuje 4 feature'y dziennie i znajduje w nich łącznie 4-6 bugów, to samo raportowanie pochłania 40-90 minut. Dodaj do tego ponad 23 minuty na powrót do kontekstu po każdym przerwaniu (Gloria Mark, „Attention Span", 2023) — i tester nie ma czasu na wczesne raportowanie, bo sam proces jest zbyt wolny.

Co to oznacza dla Twojego software house'u

Cykl „raport w minutę → naprawa tego samego dnia → retest następnego ranka" zamyka pętlę feedbacku wewnątrz sprintu. Bug nie przechodzi do review. Nie trafia do backlogu. Nie opóźnia release'u. Klient na demo widzi działający produkt, nie listę znanych problemów.

Voice2Bug umożliwia ten cykl. Tester znajduje buga, mówi co widzi, robi screena — poniżej minuty. Raport trafia do Jiry natychmiast, z kompletem danych do reprodukcji. Developer widzi ticket z URL-em, krokami, screenshotem i danymi technicznymi. Nie musi dopytywać. Naprawia. Tester weryfikuje następnego ranka — bo nie potrzebuje czasu na przełączanie kontekstu, żeby wrócić do tego samego buga.

Efekt na poziomie sprintu: więcej bugów naprawionych i zweryfikowanych przed dniem 10. Mniej niespodzianek na review. Mniej bugów w backlogu. Szybsze release'y. I klient, który na demo widzi gotowy produkt — nie prototyp z zastrzeżeniami.