„Kill it before it lays eggs!”
A következő néhány hétben, 4 bejegyzésben a tesztelésről fogunk Nektek mesélni. Onnantól, hogy „miért érdemes tesztelni?”, a tesztelési és fejlesztési módszereken át egészen addig, hogy mit lát a megrendelő. Beszélünk majd a tesztpiramisról, az automatizált tesztelésről és a tesztek csoportosításáról is.
Tesztelésről szóló blogsorozatunkat Nagy Szilveszter kollégánk írta.
A tesztelésről – I. rész
1998. tavaszán a Microsoft egyeduralkodó volt a az operációs rendszerek piacán. Épp arra készültek, hogy bemutassák az elsöprő sikert hozó Windows 95 utódját, a Win 98-at. Április 20-án maga Bill Gates sétált a színpadra, hogy élete feltehetően legkellemetlenebb momentumának legyen részese. Történt ugyanis, hogy a szoftver összeomlott. Rögtön a bemutató elején.
Ez azt bizonyítja, hogy még a legnagyobbak is hibáznak, ezért nem győzzük hangsúlyozni a tesztelés fontosságát. Tesztelték vajon a Win 98-at? Bizonyára. Rengetegszer. Azonban legalább eggyel kevesebbszer, mint szükség lett volna rá, vagy a módszer volt hibás.
A szoftverfejlesztőkre hatalmas nyomás nehezedik a szűkös határidőkkel, korlátozott budgetekkel, viszont a tesztelésnek akkor is részét kell képeznie a fejlesztési folyamatnak, ha felesleges kiadásnak tűnik.
Miért tesztelünk?
Egyelőre minden szoftvert emberek fejlesztenek, ami azt jelenti, hogy bizony hibáznak is. Így szinte biztosak lehetünk abban, hogy minden szoftverben van hiba. A kérdés csupán annyi, hogy mi találjuk-e meg először, vagy a megrendelő, esetleg a felhasználó.
Ugyanez a helyzet akkor, ha új funkciókat adunk hozzá egy már meglévő szoftverhez, optimalizáljuk azt, vagy csak refaktoráljuk. Minden változtatás magában rejti a hiba lehetőségét – és ezért bizony tesztelni kell. A tesztelés biztosítja a termék minőségét és megbízhatóságát. Nemcsak a megrendelő felé, hanem kollégáink felé is, mert megfelelően kidolgozott tesztelési mechanizmusok tudatában egy junior is nagyobb magabiztossággal nyúlhat a kódhoz, hiszen a teszt őt is védi saját hibáitól.
A lean szemlélet egyik alapvetése, hogy a lehető leghamarabb kész legyen a Minimum Viable Product (MVP), vagyis a szoftvernek az a verziója, ami már működőképes. Jelentheti-e ez vajon egyben azt is, hogy a kezdeti fázisban nincs szükség a tesztekre sem? Ha elhagyjuk a tesztelést, akkor az ugyan – kis szerencsével – a rövidtávú üzleti céloknak segítségére lehet, azonban kockáztatjuk azt, hogy magunk előtt görgetünk olyan hibákat, melyek a fejlesztés későbbi fázisait rémálommá teszik.
Sokkal nehezebb egy problémát az elején orvosolni, mint később. Ezért gyomlálja ki a Kisherceg is a bolygóján a majomkenyérfákat. “Kill it before it lays eggs!” – tartja a mondás. Jobb akkor elcsípni a problémákat, amíg nem nőnek a fejünkre és kezdenek el sokasodni. Különösen akkor kell figyelni erre, ha a fejlesztés során csapatban, hosszabb projekten dolgozunk. Hiszen előfordulhat, hogy egyes hibák még évekkel később is problémát okoznak, holott az elején teszteléssel könnyen elcsíphetőek lettek volna.
Mit nyerünk a teszteléssel?
A fentiek miatt bátran állíthatjuk, hogy a tesztelés hosszú távon időt és pénzt takarít meg és még a későbbi fejlesztéseket is gyorsabbá teszi. Már a kezdetektől fogva segít átgondolni a feladat megoldását, megkönnyíti a fejlesztők dolgát és az ügyfél is pontosabb dokumentációt kap a folyamat végén. Mindezt természetesen amellett, hogy minimalizájuk a lehetséges hibákat a szoftverben. Figyelem, spoiler: halmozottan igaz ez az automatizált tesztekre.
Következő bejegyzésünkben az automatizált tesztelést fogjuk kivesézni, beszélünk a tesztpiramisról, illetve megnézzük, hogy hogyan érdemes tesztelni.
Látogassatok el rendszeresen a join.stylers.hu oldalra, és kövessetek minket a Facebookon és Instagramon is!
