Szoftverfejlesztés közben tesztelünk, mert jó. Számomra sok esetben a kódolás során az okoz örömet (flow) amikor elindul a program, elkezd működni, azt csinálja amit én akarok. Olyankor én vagyok az Isten. (Tudom, cseppnyi az én világom, de mégiscsak én teremtettem. Rajzolj nekem egy bárányt!)

Idáig tart az élvezet, és sokszor a hobbiprogramozás esetében itt véget is ér a tesztelés. Ezzel pedig a minőségi szoftver készítés nem csak véget ér, de el sem kezdődött. (OFF: Ez sajnos nagyon gyakran jellemző az OpenSource programok készítőire, és így az OpenSource programokra is, és ezért van sokakban előítélet, hogy ami OpenSource az szár. Pedig nem.)

A profi programot teljes körűen kell tesztelni (amennyire teljes körűen lehet, vagy amennyire teljes körűen érdemes/ erről később esetleg majd másik bejegyzésben). Ez meg már nem olyan élvezetes, nem jön olyan gyakran a flow érzés. Ugyanolyan lapátolós kubikos munka, mint a dokumentáció írás, csak éppen enélkül, mint ahogy dokumentáció nélkül sem megy a dolog.

Mi a teendő?

A szokásos válasz rendkívül egyszerű:

a szár munkát is el kell végezni, tesztelni kell. Főnökök korbácsot elő és addig nincs shipment, release és fizetés, amíg a tesztek nincsenek készen!

A nagy kövér veri a dobot, az őrök korbáccsal járnak a sorok között, a rabok meg eveznek a gályán, és a hajó révbe is ér (vagy elsüllyed). Nem lenne sokkal jobb vitorlázni? Gőzhajó? Netán hatalmas dízel motorok? Atommeghajtású Mary Queen II? Kurszk? Hova is akarunk menni? Azért néha jó a kenu is!

Csattog a korbács és a tesztek készen is lesznek, a programok pedig hibásak maradnak. Miért is? Mert a programozó nem kubikos földásó munkás, és nem is favágó sem pedig nem gályarab. Nem kilométerben gyártja az árkot és nem köbméterben vágja a fát, se a programokat nem milligrammra készíti. A programozó szabad madár, kreatív munkára termett, ha bezárják elpusztul, megszűnik programozó lenni, jobb esetben megszökik.

Az igazi programozó képtelen megbízhatóan tesztelni, legfeljebb ideig, óráig, aztán besokall, és elkezdi rosszul végezni a munkáját. Először csak a tesztelést, aztán a fejlesztést is, és utána rosszabbodik a helyzet: elkezd inni, veri a feleségét, gyerekét, vagy csak más munkahely után néz.

A válasz rendkívül egyszerű:

Legyen a tesztelés is fejlesztői munka.

Szokatlan? Annyira nem. Aki például Java nyelven fejleszt az szinte biztosan ismeri a Unit teszt fogalmát, és a Java-ban ehhez társuló Junit könyvtárat. Minden egyes unit-hoz, programozási egységhez egy, vagy több tesztet írunk, amelyeket minden fordítás után lefuttatunk. Ez egyértelműen a programozó dolga. Sokan azt vallják, hogy a unit teszteket a tervezést követően, és még a unit kódolása előtt kell megírni.

És mi a helyzet a felhasználói tesztekkel? Azokat kézzel kell végigcsinálni? Úgy szokták. De nem lehetne automatizálni?

Terheléses teszt? Beégetési, stabilitási (burn-in) teszt? Ezeket nem is nagyon lehet automatizálás nélkül végrehajtani.

Automatizáljunk minden tesztet!

Valahol a végén persze kell, hogy legyen egy ember (aki már tényleg nem fejlesztő), aki a teszt végső eredményét ellenőrzi. De ne ember legyen, aki leellenőrzi 12,874 darab tesztesetben, hogy klikkentés hatására valóban megváltozott a form harmadik sora, és piros lett a mikulás orra az ikonon ha megnyomtam az „alkohol” gombot, de ha nem, akkor maradt kék. Ezt program is el tudja végezni, olcsóbban, és jobb minőségben. És nem is őrül bele. És több időnk marad bárányt rajzolni.