Do jakiego owada można by porównać defekt? Wiadomo, że Grace Hoper znalazła w komputerze jeden z gatunków niewielkiej ćmy. Ale królestwo bugów na jednym gatunku się nie kończy.

Niektóre są jak muszki owocówki – mnożą się na potęgę.

Inne są upierdliwe jak komary – już myślisz, że masz je z głowy, a tu niespodzianka…

Co niektóre przeobrażają się jak najpiękniejsze motyle i z koszmarka defektu powstaje iskrzący feature. A czasem creeper. Zależy od gatunku.

Są takie, które jak mole – chuj wie, skąd się biorą, a żeby się ich pozbyć trzeba wyrzucić połowę zawartości kuchni, a całość porządnie wysprzątać.

I są szerszenie – wielkie, buczące, wszyscy o nich wiedzą, ale nikt ich nie rusza, bo wiadomo – jak szerszeń upierdzieli… Lepiej nie tykaj, po co ci to.

Bez względu na gatunek, każdy defekt, podobnie jak każdy robal, ma swój cykl życiowy.

Ostrzeżenie dla purystów językowych – czytanie dalszej części może być dla was niebezpieczne. Zawiera wyrazy branżowe, zapożyczenia z języka angielskiego, spolszczone.

Kiedy tester znajduje błąd, zbiera dowody i zakłada zgłoszenie. Defekt otrzymuje status new. Zwykle wpada do jakiegoś wora (backlog) i w zależności od wagi – albo znajdzie szybko swoją drogę, albo trochę się w tym worze pokisi. Jest też taka opcja, że zostanie z wora wywalony (zrejectowany). Powodem może być np. istnienie zgłoszonego wcześniej duplikatu. Lub uznanie, że ta usterka nie będzie z jakiegokolwiek powodu naprawiana. Oczywiście dla testera najgorsza jest sytuacja trzecia – błąd zgłoszony przez pomyłkę. Ale takie też się zdarzają i nie ma co rwać włosów z głowy. Jeśli zgłoszenie nie trafi na warsztat od razu, pewnie zostanie jakoś oznaczone – to do, nice to have czy podobnie – grunt, żeby wiedzieć, że to nic pilnego, nasza gąsieniczka zawija się w kokon i czeka.

Z wora nasz robaczek powinien trafić do osoby odpowiedzialnej za rozwiązanie – zwykle będzie to programista, ale może być też analityk lub architekt. Jego status może przyjąć wartość open. Może też od razu zostać wzięty na tapet i być in progress. Zwykle to oznacza, że jesteśmy na dobrej drodze, no, chyba że dev uzna, że czegoś mu brakuje i wrzuci pendinga.

Owszem, zdarza się wcale nie tak rzadko, że czegoś brakuje – czy to w logach, czy w opisie. Warto sprawdzić, czy defekt nadal występuje, jeśli np. czekał w worze od dawna. Programista może wtedy poprosić o uzupełnienie, często robi to w bezpośredniej komunikacji. Często dla porządku zgłoszenie wraca do testera. Jednak bywa i tak, że w tym momencie zaczyna się defektowy ping-pong. Przepychanie statusów, odbijanie defektu na testera i z powrotem na programistę – no cóż – zwykle jest elementem biurokracji i polityki biurowej.

Ale, ale… odbiegłam od tematu. Załóżmy, że defekt jest dobrze zgłoszony, programista znalazł jego przyczynę i ją poprawił. Jaki dać status takiemu zadaniu? Jest oczywiście kilka opcji do wyboru, ale zwykle spotyka się resolved lub fixed, a tester dowiaduje się, że można przeprowadzić retesty. Jak przejdą – zamykamy zgłoszenie. W przeciwnym wypadku – reopenujemy. Naprawa może być nieudana albo częściowa. Tak czy inaczej – robaczek wraca do programisty i jeszcze raz musi przejść fazę analizowania, poprawiania i weryfikowania. Jak długo można się tak bawić? Bywa, że długo, ale w końcu wszystko zostaje naprawione.

A kiedy już wszystkie znalezione robaczki zostaną usunięte, oprogramowanie wjeżdża na produkcję i pozostaje tylko czekać, aż z głębi wypełźnie tej jeden jedyny czerw, którego wszyscy przegapili.