Život brouka začíná téměř vždy okamžikem, kdy jej tester objeví. Každá chyba by měla být zaevidována. K tomu se používají nejrůznější bugtrackingové nástroje (o těch zase někdy jindy). Zaevidování chyby znamená, že se co nejpřesněji popíše chování aplikace a způsob, jakým bylo tohoto chování dosaženo.

Každá chyba by měla být označena závažností. Ta říká, jak velký dopad má tato chyba na funkčnost aplikace. Jsou chyby méně závažné až kosmetické, které mohou spočívat například v překlepech v názvech položek. Existují chyby natolik závažné, že brání v používání aplikace. Podle této závažnosti se následně stanoví priority při opravách.

Jakmile je chyba zaevidovaná, začíná její životní pouť. Ta vede obvykle přes analytika, vývojáře zpátky k testerovi. Bug lifecycle může být navrhnut naprosto jakkoli. Záleží přitom na použitém bugtrackingovém nástroji (především na možnosti jeho přizpůsobení), na použité metodice a také na složitosti projektu.

Ideální je si bug lifecycle nakreslit, pak se jednotlivé kroky lépe chápou. Takže pro ilustraci toto je bug lifecycle používaný v Bugzille(což je program správu chyba, ale o tom někdy později).

No ale konkrétně. Pokud vezmu toto schéma jako vzor (bez snahy popsat způsob, jak je v reálu používáno), můžu jednotlivým procesům přiřadit obvyklé role.

Začínám u stavu NEW. Do tohoto stavu se chyba dostane ihned po svém zadání. Rolí, která má tedy právo chybu do tohoto stavu dostat, je tester.

Následuje stav ASSIGNED. Ten znamená, že tuto chybu má přiřazenu konkrétní vývojář, který je zodpovědný za její vyřešení. Do tohoto stavu se chyba dostane buď tak, že samotný vývojář má právo si chybu přiřadit (tedy převezme ji k vyřešení), nebo existuje další role (například test manager, nebo analytik), jejímž úkolem je rozdělovat nalezené chyby mezi vývojáře. Druhá varianta je ideální u větších projektů. Tam se jednak předpokládá větší počet chyb a navíc je u velkých projektů obvyklá specializace vývojářů na konkrétní oblast v aplikaci. Tento krok se navíc používá i pro filtraci chyb. Může se stát (a stává se to často), že nalezená chyba ve skutečnosti chybou není. V tu chvíli může být v rámci cyklu přesunuta přímo do stavu RESOLVED, bez toho, že by se jí některý z vývojářů věnoval. To ale samozřejmě přepokládá, že člověk v roli, která chyby rozděluje a filtruje, je schopen toto posouzení provést.

Dalším stavem je tedy RESOLVED. Ten říká, že chyba byla vyřešena. Do tohoto stavu chybu přesouvá vývojář, který řešení provedl. Jak už bylo řečeno, může se stát, že nahlášená chyba chybou není. Aby se odlišilo, zda vývojář chybu opravil, nebo zda jen zjistil, že se jedná o chybu při testování (případně sice zvláštní nicméně správné chování aplikace - to je překvapině častý stav), zavádí se na chybu ještě atribut, který říká, jakým způsobem byla chyba vyřešena. Požívá se například FIX, pro opravené chyby, DUPLICATE, pro chyby, které byly již zadány a jsou tedy řešeny v rámci jiného lifecyclu, nebo třeba WON'T FIX, například pro chyby, které popisují standardní chování aplikace, a podobně. Vhodné je i slovní komentář ze strany vývojáře.

V tuto chvíli se na scénu opět vrací tester. Jeho úkolem je opravenou chybu přetestovat a rozhodnout, zda byla opravena správně. Při re-testu chyby je přesunuta do stavu VERIFIED. Po ověření opravy může být přesunuta do stavu CLOSED. To v případě, že byla opravena správně a již se v aplikaci nevyskytuje. Naopak pokud se chyba objevuje i po opravě, pak se převede do stavu REOPEN. A znovu následuje přiřazení chyby vývojáři. Takto se může chyba vracet mnohokrát.

Tohle je jen jeden způsob, jak vykládat uvedené schéma. V reálu může být použito jinak. Každopádně v reálném vývoji se používají obvykle složitější schémata, která jsou ale postavena na stejné logice. Vždy je důležitá správná struktura stavů a operací, které k nim vedou. Velice důležité je správné navržení přístupovách práv k jednotlivým operacím.