Fejlesztőknek > Bugtrack szabályok

A fejlesztési igényeket tesztelőink és ügyfeleink a http://bugtrack.netgral.com címen elérhető rendszerben tartjuk karban. A bugtrack rendszerbe az developer@netgral.com címen lehet hozzáférést igényelni. A szerződött távmunkás fejlesztőink automatikusan kapnak hozzáférést ehhez a rendszerhez.

A bugtrack -ben az egyes hibák - feladatok Projektekhez vannak rendelve, és különböző státusszal rendelkezhetnek.

Új hibák felvitelénél ügyelni kell arra, hogy a meghatározás - leírás alapján a hiba könnyen megtalálható legyen. A hiba neve legyen lehetőleg rövid, de hosszú listában böngészve is legyen érthető és azonosítható. Az URL mezőt érdemes kitölteni webes rendszerek esetén, mert így a kérdéses oldal azonnal megtalálható. A hiba leírásánál érdemes minden fontosnak ítélt körülményet megemlíteni (milyen felhasználóval léptem be, mire kattintottam, mit írt ki, ... stb)

Egy hibának több fontos paramétere is van a szöveges leíráson túl:

• Prioritás - a P1 a legsürgősebb, a P5 a legkevésbé sürgős. Ez határozza meg, hogy milyen sorrendben célszerű a hibákat javítani.
• Súlyosság - azt határozza meg, hogy a tesztelő mennyire itélte súlyosnak az adott hibát. A következő szintjei léteznek:
  • blocker - a hiba lehetetlenné teszi - blokkolja a tesztelést. Akkor használjuk ha egy alkalmazás vagy modul vagy funkció egyáltalán nem érhető el.
  • critical - olyan kritikus hibáknál alkalmazzuk, melyek nagyon veszélyesek lehetnek biztonságtechnikai vagy adatvédelmi szempontból, esetleg egy program lefagy (webes alkalmazásoknál ritkán fordul elő) Pl. egy számlázó program nem vált számlaszámot új számla generálásakor, vagy egy rendszer jelszó nélkül is elérhetővé tesz kritikus adatokat...
  • major - súlyos hibát jelöl, az alkalmazás funkcionalitásában súlyos hiányosságok tapasztalhatóak
  • normal - egy átlagos, a többi súlyozásba nem egyértelműen tartozó hiba
  • minor - kisebb hiba, ami speciális úton, szándékosan reprodukálható csak, a munkát nem feltétlenül zavarja
  • trivial - kozmetikai probléma, mint pl. egy félregépelés, rosszul formázott szöveg vagy egy félrecsúszott gomb
  • enchancement - új funkció igénylése, akkor használjuk ha egy rendszerbe új lehetőségeket, modulokat, funkciókat szeretnénk fejleszteni
• Státusz - ez a paraméter mutatja meg, hogy a hiba, "életciklusának" mely szakaszában jár. A legfontosabb státuszok:
  • NEW - minden új hiba a NEW státusszal kezdi el bugtrack létét
  • ASSIGNED - ha egy fejlesztő elvállal egy hibajavítást és a project manager jóváhagyja (lásd később), akkor a saját azonosítójához rendeli az adott hibát, így a többi fejlesztő láthatja hogy ez a hiba már "foglalt"
  • RESOLVED - FIXED - a hiba javítva lett, és a fejlesztő feltöltötte a teszt helyre, vagy a verzió követő rendszerbe, tesztelésre vár
  • RESOLVED - CLOSED - a hiba javítása tesztelve lett és le lett zárva, a megoldást elfogadtuk
  • REOPENED - a javítás tesztelve lett, és hiányosnak ítéltetett, újra meg lett nyitva. Mások is elvállalhatják a hiba javítását, ilyen szempontból megegyezik a NEW státusszal, ASSIGNED státuszra vár.
  • RESOLVED - INVALID - a jelzett hiba nem hiba!
  • RESOLVED - WONTFIX - a jelzett hiba valamilyen oknál fogva nem lesz sohasem javítva
  • RESOLVED - DUPLICATE - a hiba már fenn van más néven a rendszerben
  • RESOLVED - WORKSFORME - a hiba leírása nem elégséges annak reprodukálásához, ezért további információig ez a státusza

Minden státusz módosításról és megjegyzésről az érintettek email értesítést kapnak. A jelenlegi szabályaink szerint minden fejlesztő akinek hozzáférése van a bugtrack rendszerhez, böngészheti a nyitott hibákat, és ha talál egyet amit érzése szerint hatékonyan javítani tud, akkor:

1. az adott hibánál a megjegyzés mezőbe beírja hogy hány óra alatt oldaná meg a feladatot. (Kivételt jelentenek a P1 prioritású feladatok, melyeket jóváhagyás nélkül el lehet kezdeni javítani, és a project managerrel utólag kell egyeztetni a ráfordított órák számáról. )

2. Az óra becslés megjegyzésről a project manager értesítést kap, és ha megfelelőnek találja, akkor ugyanitt megjegyzés mezőben megrendeli a fejlesztést. Amíg nem rendeli meg, és a hiba nincs ASSIGNED státuszban, más is írhat - alacsonyabb - óra becslést, egészen addig, amíg meg nem lesz rendelve az adott fejlesztés

3. A távmunkások kifizetésének alapja az elfogadott, letesztelt - tehát RESOLVED - CLOSED státuszban lévő hibáknál becsült óra lesz minden hónap végén.

A fejlesztői környezet készen áll. Ismerkedjünk meg néhány fejlesztési alapelvvel. Fejlesztési alapelvek!