Pár napja (hete) egy ismerősöm megjegyezte (aki persze nem olvassa a blogot, csak hallott olyanról, aki látott olyat, aki olvassa), hogy amikor szoftverfejlesztőkről írok, akkor kifejezetten a kódolókra gondolok és nem ejtek szót a tesztelőkről. Ennek igazából az az egyetlen oka, hogy én sosem teszteltem, mert mindig olyan szétcsúszott agilis projektekre kerültem, hogy nem volt szükség tesztelésre, mert erre vannak a (l)userek.
Szóval a karrierem során nagyon unit teszteket sem kellett írnom, amikor az előző munkahelyemen hozzájuk nyúltam (mert a -DskipTests-et használhatjuk prodon is, jó úgy), hogy emberbaráti szeretetből rendberakom őket (igazából ennyire nem volt dolgom), elég sok hibát találtam, és elég bunkóak voltak velem a srácok (és nem ez a menj a francba, de azért kösz, hogy megtaláltad módon, hanem tényleg), ezért inkább leálltam és Facebookoztam és nagy ívben leszartam, hogy most mi jó, mi nem jó.
Még az első főnököm mondta nekem, hogy a tesztelés felesleges, jól kell kódot írni, akkor nem lesz probléma. Igen, ez egy csodálatos elmélet, tök jól működik gyakorlatban. Ezért most emelje fel az a fejlesztő kolléga a kezét, aki még nem tett bugot a kódba, ami utána úgy csapta arcon, mint bumeráng a béna vadászt.
Sejtettem 🙂 Azért a legtöbben leteszteljük a saját kódunkat (höhö), de a sajátod sosem tudod jól tesztelni, mert minden esetet, amire gondoltál, azt lefedted kódolás során vagy legalább a specifikációban benne volt (legalább nekem ez a kifogásom, a tiéd mi?). Gondolom mindenkinek ismerős az eset, amikor végre elkészült a kis kódjával, letesztelte, maximálisan meggyőződött a működés helyességéről és erre jön valaki, kattint egyet és az egész rendszer összeomlik. Jobb esetben ez nem customer demón történik (még rosszabb eset, amikor már kiment élesbe), és nem jön érted a TEK miatta. Szóval az elbaszott kódok piaci igények miatt létrejött egy új szakma: a szoftvertesztelés. Maga a tesztelés sok programozót elriaszt már akkor is, ha csak papírra van leírva a szó azzal a felkiáltással, hogy én kódot jöttem írni, nem tesztelni. Számomra ez a tesztelés világ idegen, mások kifejezetten szeretik. Én sosem lennék jó tesztelő, de dolgoztam együtt kiváló tesztelőkkel, és tényleg volt benne valami megnyugtató, hogy elég sok kódhibám elkapták. Másfél év support után azt mondom, hogy amíg sikerül nekünk megfogni a bugot, és nem a customernél borul a rendszer, az sokkal jobb, mint amikor a saját szarod talál vissza hozzád olyan fenyegetéssel, hogy ezen üzlet bukhat.
A szoftvertesztelés a szoftverfejlesztés részfolyamata, de az, hogy a szoftvertesztelő szoftverfejlesztő-e már más kérdés, valamelyik cégnlk szoftverfejlesztők máshol szétválasztják a kettőt. Szerintem ez tök mindegy, de az tény, hogy más ismeretekre, hozzáállásra és gondolkodásmódra van szüksége egy tesztelőnek. Ők a nagyobb rendszert fogják látni, de azt, hogy hogyan működik a rendszer belül azt nem. Nekik azt kell tudniuk, hogy bizonyos tevékenységekre hogyan reagál a rendszer, mi elfogadható működés és mi nem. Ha nem elfogadható annak milyen impactja van. El kell tudniuk magyarázni, hogy mi jó, mi és miért nem jó, és tudniuk kell, hogy mi az elvárt működés. A testcase-eket is létre kell hozni, azért a 21. században kézzel tesztelni már nem menő (és meg is kell őket tervezni, hogy minél átfogóbbak legyenek, ami szintén nem egy triviális feladat). Megvannak a technológia és a tool követelmények, nekik is van processzük (jobb esetben), ezek cégfüggő dolgok. Egy tesztelőnek tudnia kell használni és kicsinálni a rendszert – könnyű feladatnak tűnik, de nem az.
Amikor elkezdek használni egy szoftvert minőséget várok el, egyrészt egy elvárt, jó működést, például azt, hogy az érzékeny adataim biztonságban vannak. Azt hiszem az elmúlt hetek botrányait figyelembe véve már a laikusok is érezhetik, hogy milyen hatalmas balfogások kerülhetnek egy szoftverbe: elgondolkodtam azon, hogy vajon azt a bizonyos e-bérlet rendszert vajon hogy tesztelték, de nagy a valószínűsége, hogy sehogy. Ha a kis fitnesz alkalmazás méri rosszul az általam elégetett kalóriákat, maximum morgok picit, de ha személyes adataimról vagy pénzügyi tranzakciókról van szó, akkor jogosan háborodok fel, és nem fogom használni többet a szoftvert. Azzal tisztában kell lenni, hogy átfogó teszteléssel is maradnak hibák a rendszerben, de talán a buta hibák jó részét sikerül megfogni – szóval legyünk hálásak a fejlesztés alatti kis bugreportokért, mert lehet egy szép seggrepacsitól (TEK-től) óvnak meg minket. 🙂
A kávét a Spar biztosította!
Kommentek
Kommenteléshez kérlek, jelentkezz be: