Incidens- és hibamenedzsment

Incidensnek tekinthető minden olyan megfigyelt esemény, amely vizsgálatot indokol, például váratlan alkalmazásviselkedés vagy ellentmondó dokumentum. Nem minden észlelésről derül ki, hogy programhiba: lehet félreértett elvárás, hibás adat vagy eltérő környezet. A hibamenedzsmentben a tényt rögzítjük, majd döntünk a további vizsgálatról, javításról és ellenőrzésről.

Például egy diák sikeres jelentkezést lát, de a foglalás hiányzik a listából. A megfigyelt eltérés biztos; hogy az adatbázis nem mentett, az csak lehetséges ok, amíg a napló és az adatállapot nem igazolja. A jó jegy segít másnak megismételni és értékelni a helyzetet, anélkül hogy bizonyítatlan diagnózist állítana.

Azonosító és rövid, pontos cím; érintett verzió és környezet; kiinduló állapot és bemenet; lépésről lépésre ismételhető művelet; elvárt és tényleges eredmény; képernyőkép vagy naplórészlet, ha releváns és kezelhető; megfigyelt gyakoriság; súlyosság és az üzleti hatás. A felhasználó érzékeny adatait nem másoljuk szükségtelenül a hibajegybe; próbaadatot használunk. A hibajegyhez kapcsolódhat érintett követelmény és teszteset.

A súlyosság a hiba hatását írja le: elveszett foglalás súlyosabb lehet, mint egy elcsúszott címke. A prioritás azt jelzi, milyen gyorsan foglalkozzanak a hibával; ezt a projekt célja, határidő és érintett felhasználók is befolyásolják. A két fogalom gyakran együtt jár, de nem azonos. Ha az eset csak bizonyos adatokkal jelentkezik, ezeket pontosan rögzítjük.

A bejelentett tételt ellenőrzik: újra előidézhető-e, hiányzik-e adat, ismert-e már, és mi a megfelelő besorolás? Elfogadás után felelőshöz kerül a kivizsgálás és javítás; a tesztelő az eredeti esetet megerősítő próbával újraellenőrzi, majd a lehetséges mellékhatásokra regressziós teszteket futtat. Ha a hiba fennáll, a jegy visszakerül vizsgálatra. Lezáráskor a javított verzió és ellenőrzés kapcsolata legyen látható.

Egyes tételek elhalaszthatók, elutasíthatók vagy pontosítást igényelhetnek, de ehhez indoklás kell. Ha a jelentésből hiányzik az elvárt eredmény, nem feltétlenül szabad „nem hiba” címkével lezárni: előbb a követelményt kell tisztázni. A duplikált jegyek összevonhatók a bizonyítékok megtartásával. A folyamat célja a termék és a közös tudás javítása, nem a hibák számának kozmetikázása.

Egy hiba súlyossága a felhasználó és a rendszer szempontjából várható következményt írja le. Egy jelentkezés elvesztése súlyosabb lehet, mint egy vizuális eltérés. A prioritás azt mutatja, melyik javítást kell előbb kezelni a projekt célja és ideje mellett. Egy alacsonyabb súlyosságú, bemutató előtt sokakat érintő címhiba sürgős lehet; egy súlyos, de ritka és csak később megjelenő probléma más ütemezést kaphat.

A besorolást bizonyítékra és döntésre építjük, és az új információk alapján módosíthatjuk. A hibajegyet nem szabad kizárólag egy hangzatos cím miatt kritikusnak vagy mellékesnek minősíteni: szerepeljen benne a tényleges kár, az érintett felhasználók, a megkerülési lehetőség és a hiba reprodukálhatósága.