Az a helyzet, hogy mindenki gondol erről valamit – de mindenki valami mást.
Minden teszt adminisztrációs rendszerben van a bugokhoz legalább két mező, általában Priority és Severity néven, amelyekkel elméletileg a hiba súlyosságát, a javítás sürgősségét, valamint az okozott kár nagyságát lehet jelölni. Minden cégnél, minden csapatban van valamilyen definíció arra, hogy ezeknek az értékei, és az értékek kombinációi mit jelentenek: azonnal kell a javítás, sürgősen javítani kell, nagyon fontos, kevésbé sürgős stb.
Ezek a definíciók azonban kissé homályosak, egy idő után összefolyik, hogy a Major és a Critical között mi a különbség. Pontosabban, tapasztalatom szerint mindenki pontosan tudja, hogy mi jelentenek – de mindenki másképp…
A hibát ott követjük el, hogy a definíciókat a saját szempontunkból írjuk meg. Ehelyett arra kellene gondolni, ami a fejlesztők oldalán történik:
- Dobjanak el mindent azonnal, javítsák ki a hibát és küldjenek hotfixet
- Vegyék előre a hiba javítását, és már a következő sprintben, következő buildben szállítsák is le
- Később is ráér a hiba javítása, de az élesítésig legyen készen
- A hibával az éles működés során is együtt tudunk élni
A fenti besorolásokat nevezzük el például úgy, hogy Blocking, Critical, Major, Minor, és a szerződésbe írjuk le a vonatkozó határidőket (pl. két munkanap / következő sprint / élesítés dátuma) és kész is vagyunk. Minden más (pl. a Severity mező használata) csak felesleges bonyolítása a csapat életének.