Caracalla blogja

Kicsit több mint egy éve csaptam fel webes fejlesztőcégnél tesztelőnek, amely agilis módszerekkel dolgozik (előtte is volt közöm a szoftverekhez), és én vagyok a legszeniorabb, a ‘vezető’ tesztelő (a munkaidőm egyharmadában meg projektmenedzsmenttel, projektadminisztrációval foglalkozom). Így talán nem túl meglepő, hogy olyan módszertani kérdések is foglalkoztatnak, amelyek egy nagy, kialakult szervezetben dolgozó tesztelőt többnyire nem.

Az egyik, hogy mi a viszonya az agilis fejlesztésen belül a tesztelésnek az egyéb funkciókkal (BA/architect/dev/sa/customer support).  A waterfallban ugye elég egyértelmű, egy leginkább a gyártásból ismert utólagos minőségellenőrzés, amit a minőségmenedzsment irodalom többnyire a quality control néven szokott ismerni (a különbség az, hogy a gyártásban az elhibázott példány többnyire kuka, vagy akciósan megvehető, mint a hárommagos processzor). Jobb műhelyekben ez kiegészül olyan mérőszámok követésével, amik a kódról már megírásakor mondanak ezt-azt (ciklomatikus komplexitás, valamilyen notation követése régebben, code review, unit testelés pl.), amikor már valóban beszélhetünk minőségbiztosításról, quality assurance-ről.

Ehhez képest az agile iterációkban dolgozik, és ilyen értelemben az utólagos minőségellenőrzés rögtön megkérdőjeleződik, mert ami a funkciónak a vége, az az értelmes szoftvernek még nem, illetve nincs rá garancia, hogy nem . A mindennap release-elhető állapotú kód, az megint ellentmond ennek az utólagos tesztelésnek.

Két igazán komoly problémát látok egy agilis projekten való tesztelésen.

Az egyik a build stabilitás. A gyakori build, változások miatt sokszor lehetetlen azonos kódon végrehajtani a teszteket (ha nem az a greatest-latest, akkor pedig az lesz a válasz a bugokra, hogy a legújabbon is van, és tegyük hozzá, valóban nincs sok értelme egy már nem aktuális verziót tesztelni).

A másik az elvárt állapot dokumentációja, ami a sok iteráció alatt könnyedén elmarad az aktuálistól, esetleg nem is létezik, vagy csak valami megtévesztésre jó, részleges, helyenként elavult formában. Az sem segít, hogy a tipikusan kevés upfront tervezéssel dolgozó agile esetén rendszeresek a meglepetések.

A szakirodalom válasza ezekre többnyire az automatizálás. Buildet, unit, komponens, gui, teszteket automatizálni, 100% coverage-re lőni, stb. Ezek a könyvek többnyire tele is vannak olyan példákkal, miszerint “A 13 fős, 3 BA, 4 fejlesztő, 4 tesztelő és kettő valami menedzserből álló team azzal a problémával szembesült, hogy” - ami gondolom mindenkinek látható, hogy nem reális az itthoni viszonyokra. Arról nem is beszélve, hogy a tesztelők mind kiválóan értenek a fejlesztéshez, sőt, akár az architect munkájának szakmai felügyeletére is felkészültek, és természetesen a fejlesztés TDD alapokon folyik.

Azok alapján, amit én láttam, ez itthon és külföldön is eladhatatlan. Az, hogy átlagosan egy fejlesztőn még másfél embernyi (+menedzsment) overhead legyen, a megrendelőknél, részvényeseknél kiveri a balhét. Outsourcingban más nyeri a megbízást, a belső IT-t meg kiszervezik (paradox módon olyat viszont már láttam, hogy profi tesztelők nélkül üzemeljen egy 5+ fejlesztőgárda, igaz jobbára nem is fejlesztettek semmit, amikor meg igen, akkor az rossz minőségben sikerült). A dolog kevésbé problémás, minél nagyobb a projekt, mert ha relative nem is több, de mégis van egy rendes tesztelői team, ami kisebb projekteken nem jellemző.

Ehhez az is hozzátartozik, hogy a piaci viszonyok között aki elég jó, az ritkán marad tesztelő. Többnyire átáll fejlesztőnek, és főképp architektnek, a fejlesztők vagy bukott mérnökök, vagy kívülről érkezett szerencselovagok (én is ebbe a kategóriába tartozom) ésvagy nem tervezik, hogy sokáig tesztelők maradjanak. Ebből következően elég sok cég szenved a teszteléssel.

Magunk között szólva a megrendelőnek és a részvényesnek azért van igazsága. Nem minden esetben kellene 15 éven át fenntartható, atomstabil rendszer, különösen a webes fejlesztések nagy részében vállalható alacsonyabb minőség is. Más kérdés, hogy nem azonosan skálázódik a minőség meg az automatizálás, és hogy ha a megrendelő számára egy (pár) iteráció tervezett a szoftver életciklusára, akkor nem is éri meg. Különösen jól látható ez az egyébként is érdekes üzleti területet képviselő mobilalkalmazásoknál.

Hogyan lehet mégis biztositani egy viszonylag jó minőséget?

Automatizálni kell, de értelmes helyen. Elsősorban a különböző build/property szerkesztéseknél tud ez nagyon jól jönni. Eközben a cross-browser GUI automatizáció valószinüleg nem térül meg, marad az, hogy valaki manuálisan végignézi több környezetben is szisztematikusan a szoftvert. Azaz ha az ügyfél nem fizeti meg, bizony csak ott érdemes automatizálni, ahol valóban megtérülést hoz.

A másik, ami viszonylag működik tapasztalatom szerint, az a hagyományos quality police szemlélet visszacsempészése. A tesztelő amennyiben elér egy elég komoly domain ismeretet (például a félkész dolgokkal való foglalkozás helyett erre is gyúrhat), és egyben tölthet el viszonylag értelmes mennyiségű időt az elvileg már kész szoftverrel (ami központi agile elvekkel ellentétes), funkcionálisan, vizuálisan, használhatóság szempontjából biztositható egy jó minőség. Ha a fejlesztőkkel közösen sikerül még skálázhatósági és teljesitmenyellenörzéseket is végezni, akkor még tovább emelhető a minőség.

Tökéletes? Nyilván nem. Agilis? Egyes elemeiben.

Ellenben a gyakorlatban alkalmazható, nem pazarló és eredményt lehet vele szállitani.