Bejegyzés

Csak az nem hibázik, aki nem dolgozik

Csak az nem hibázik, aki nem dolgozik” tartja a mondás. Szeretnék egy pár gondolatot megosztani arról, hogy miként működik (nálunk) egy-egy új verzió kiadása, milyen lépések előzik meg és követik a kiadást, hogy zajlik a tesztelés. A hibabejelentéseknek még örülök is, hiszen a szoftverünket használják, dolgoznak vele.

Múlt héten megjelent verziónk komoly fejlesztéseket tartalmazott, új adatbázis formátum jelent meg, amelynek segítségével több cég adatai tárolhatóak egy adatbázisban. De sajnos becsúszott két olyan hiba, amely az átlagosnál több hibabejelentést generált. Ezek szerint a hibabejelentő és kezelő technológia is működik!

A hiba azt jelzi, hogy a rendszert használják

A sok hiba alatt konkrétan azt kell érteni, hogy körülbelül 10 telefonhívást kaptunk és a belső rendszerünkben 14 jelzés érkezett a két hibáról. Ez soknak számít, ennél sokkal kevesebb hibát szoktunk generálni havi kiadásainkkal.

Tesztelés

Tesztelésünket külső cég végzi. Előre egyeztetett ütemterv szerint (amitől illik néha eltérni) a havi verziók a kiadás előtt egy minimum 5 napos teszten esnek át. A változásokra fókuszálva a szakértők áttekintik, hogy mi készült el, mi javult meg és néha mi romlott el. Ezekről folyamatosan egyeztetünk és nem ritka, hogy naponta is egynél több tesztverziót adunk át újabb tesztelésre.

A kezdeti “Mindent nézzünk át!” módszer helyett – mivel már maga a szoftver is építkezik, azaz az integrált rendszerbe építőkocka jelleggel kerülnek bele új funkciók, modulok – lassan áttértünk a folyamatos tesztelésre. Már fejlesztési időben lehetőség van arra, hogy az új funkciókat folyamatosan teszteljük. Az inkrementális tesztelésnek hála egy-egy új modul már hetekkel a kiadás előtt át tud esni az első teszteken.

A verziókiadás utáni publikációs események (verziótörténet, blog, hírlevél) már csak hab a tortán. De érezni kell, hogy milyen munka áll ezek mögött.

Akkor mégis mire föl ez a két hiba?

A több céges működés olyan mértékű fejlesztést igényelt, amelyet még soha nem éltek át a fejlesztőink. Soha nem fordult még elő, hogy egy feladatot nap végére nem fejeznek be, azaz a program nem lefordítható. (Úgy bontjuk lépésekre a nagyobb feladatokat is, hogy napon belüli kis részfeladatok keletkezzenek). A több céges fejlesztés során 11 munkanapon keresztül nem volt a program tesztelhető változatban. Az adatbázis és a program felülete annyi belső módosítások esett át, hogy két hétig csak remélni tudtuk, hogy jó úton haladunk. (Azért erősen hittünk magunkban!). Az irónia, hogy az egycéges partnerek ezekből a változásokból nem szabad, hogy bármit is észre vegyenek!

A rendszer a kezdetek kezdetétől egy céges logót kezelt. Ezt sok helyen használtuk fel, például a nyomtatványokon. A több cég bevezetése során külön figyelmet fordítottunk arra, hogy a külön-külön cégek adatai is a helyükön legyenek. Egy dolgot nem vettünk a számításba: a logóbeállító előnézeti képen a program rosszul vizsgálta a céglogót és hibával leállt. Sajnos a tesztelő csapat sem vette ezt észre, helyette több más hibát jeleztek.

De akkor miért is jött elő ez ilyen sok helyen? Mert egy DEMO program telepítése után az első, hogy beállítom a céglogót és megnézem, hogy milyen szép lett. Na, ez nem sikerült sok DEMO letöltőnek.

Hibakeresés folyamatosan

És mi volt a másik hiba?

A Symbol LAB csapat a fekete dobozban ülők csapata. Őket nem érdekli, hogy most Symbol Ügyvitel vagy valamely más, egyedi fejlesztésünk a cél, ők az alaprendszert fejlesztik. Ehhez nem is a szokásos tesztkörnyezetet használják, hanem úgynevezett egység-teszteket (unit test) futtatnak. Egy hiba ezen is át tudott csúszni. A hivatalos neve:

“Osztályhierarchián keresztül betöltött objektum
késleltetett betöltésű mezőinek státusz problémája”

Sok optimalizálási kérdést oldanak meg a LAB-os kollégák, például azt is, hogy csak a termék vonalkódjának megjelenítése miatt ne kelljen betölteni a termék képét, megjegyzését, csatolt dokumentumait.

Amikor egy bizonylatot összerakunk a termékek rendelkezésre állnak (hiszen annak kiválasztásával hozunk létre bizonylat tételeket), de ha később egy bizonylatot újra betöltünk, akkor a nyomtatáshoz a termékeket be kell tölteni. Hogy ez ne kerüljön sok időbe, a LAB megoldotta a késleltetett betöltést. De sajnos az ilyen újranyomtatások esetén rosszul érzékelte a rendszer a megjegyzés mező betöltését. Emiatt nem jelentek meg a tételes megjegyzések és a termék megjegyzések.

Konklúzió

A tesztelőcsapat és mi is levontuk a megfelelő következtetéseket ahhoz, hogy legközelebb még profibban végezhessük el a szoftver kiadást. Megértőek vagyunk azon ügyfeleinkkel szemben is, akik úgy vélik, számukra nem hozott sok újítást az új verzió, cserébe elromlott valami. Cégünk elkötelezett amellett, hogy ezeket a hibákat soron kívül javítsuk. Ahogy Önök is látják, a hosszú hétvégét is részben feláldozva, tesztelő csapatot szombati munkára kérve elkészült a javítás, amely orvosolja a hibákat.

Amikor fejlesztési sebességről beszélünk, mindig eszembe jut az a 2009 szeptemberében történt eset, amikor is egy nagy tengeren túli vállalat termékében fedeztek fel hibát. A hibát jól körülírva juttatták el a céghez és ő ezt megköszönve 2010 Q2-re (azaz kb. 9 hónapra) ígérte a hiba javítását. Ennél a Symbol Tech sokkal rugalmasabb, gyorsabb reagálású és ahogy a bejegyzésből is látszik, beismerjük a hibáinkat.