articles

Szuts_Bela_580px
Forrás: FrontEndART

Agilisan? Manuálisan? Automatizálva? – avagy manapság hogyan érdemes a szoftvereket tesztelni

Hatalmas a káosz a fejekben. Nem egyértelmű, hogy ki, mit és hogyan teszteljen a sprintekben és a sprinteken kívül. Kell-e tesztelő, és ha igen, akkor milyen kompetenciái legyenek? Avagy csak egy cross-functional scrum teamre van szükségünk a kívánatos minőség eléréséhez?

Az elmúlt pár év alatt – feladatomból adódóan – rengeteg magyar cég szoftverfejlesztési és tesztelési gyakorlatába volt szerencsém belelátni. Mivel szoftverminőség-biztosítási termékeink fő célcsoportját pont ezek a vállalkozások adják, illetve az értékesítési csatornák esetén mi a direkt célzott megkereséseket részesítjük előnyben, így akarva-akaratlanul is megismerünk jó és rossz gyakorlatokat – mondta el lapunknak Szűts Béla, a FrontEndART értékesítési vezetője. Különösen igaz ez a manapság oly divatos, néha már-már csak buzzwordként is használt agilis fejlesztés terén, főleg ha az agilitáshoz kapcsolódó teszteléseket is figyelembe vesszük.

A fejlesztés módszertana, a fejlesztésre szánt erőforrások nagysága, valamint a határidők alapvetően befolyásolják a tesztelés módját – nyilatkozta Hegedűs György, a FrontEndART CTO-ja. Az utóbbi évek során előtérbe került automatikus tesztelési megoldások, és a robbanásszerű automatizálási szemlélet mellett, napjainkban ismét egyre gyakrabban felmerül, kell-e manuális tesztelői támogatás a projektekhez? Mennyire hatékony megoldás a manuális tesztelés az automatikus regressziós teszteléssel szemben?

Hegedűs György cégvezető, CTO
Hegedűs György cégvezető, CTO
 

Igazodva a trendekhez, manapság a szoftverfejlesztő cégek jelentős része átállt a sprint alapú fejlesztésre és tesztelésre, ahol a tesztelők legfőbb feladata az automatikus tesztrendszerek fejlesztése és karbantartása. A fejlesztők akár naponta több verzióval is előállnak, így a már működő funkciók hatékonyabb tesztelése érdekében a tesztelők úgynevezett automatikus regressziós tesztszkripteket fejlesztenek. Ezek kiválóan alkalmasak a korábban lefejlesztett funkcionalitások helyességének ellenőrzésére, viszont úgy tűnik, az új funkciók vizsgálata terén nem tudják felvenni a versenyt egy gyakorlott, tapasztalati alapon dolgozó tesztelővel szemben.

Az automata tesztrendszerekről

A probléma alaposabb megértéséhez nézzük meg, hogyan is működnek az automata teszt rendszerek! Vannak szoftverfejlesztő cégek, ahol csak alkalomszerűen, van, ahol minden éjjel, és van, ahol néhány óránként készül egy központi build a fejlesztés alatt álló rendszerből. (Ha ez minden éjszaka lefut, nightly buildnek hívjuk) Az aktuális verzió készítését ideális esetben egy úgynevezett continuous integration eszköz vezérli – mint például a hazánkban is egyre népszerűbb open source Jenkins – aminek segítségével egy teljesen automatizált QA folyamatot lehet kiépíteni a forráskód elemzésétől a fordításon át az automatikus tesztrendszerek lefuttatásáig és kiértékeléséig. A forráskód elemzéséhez kiválóan alkalmasak az open source Sonar, SourceMeter vagy a professzionalistáknál a QualtyGate eszközök, amelyek segítségével a kódolási hibák könnyen és gyorsan javíthatóak, ezzel is csökkentve a futás közben bekövetkező meghibásodások kockázatát. A már elkészített és tesztkörnyezetben rendelkezésre álló friss verzió teszteléséhez érdemes automatikus tesztszkripteket lefuttatni, például a szintén ingyenes Selenium testing framework integrálásával. Szerencsés, ha ezt kiegészítjük egy olyan tesztlefedettség-mérővel is, amely az automata tesztek futási idejét nem befolyásolja (pl. TestNavigator). Így a regressziós tesztjeink nemcsak azt fogják megmutatni, hogy a fejlesztés folyamán mely, már működő funkciókat sikerült elrontanunk, de azt is megtudhatjuk, hogy a tesztelésünk mennyire hatékony. Mérhetjük, a kódnak hány százalékát tudjuk lefedni ezekkel a szkriptekkel, illetve melyek azok a részek, amelyeket ily módon még nem sikerült elérnünk. Az így kialakított automatizált workflow segítségével nagyszámú tesztet tudunk lefuttatni a kívánt rendszerességgel, emberi erőforrások igénybe vétele nélkül.

 

Érdemes szót ejteni a karbantartási és fejlesztési költségekről is. Mi úgy látjuk, hogy az automata rendszerekbe fektetett tőke a legtöbb esetben nem térül meg, ha a megtérülés alatt a megtalált hibák, és ezen hibák éles rendszerbe való észlelésének költségét értjük. Ezzel szemben a rendszert ismerő, expert tesztelő által végzett manuális, felderítő jellegű tesztelés jóval több, frissen bekerült hibát tud viszonylag kis költséggel megtalálni. Hosszú távú fejlesztési projektek esetén lehet kifizetődő automatizált megoldásokat alkalmazni, de érdemes alaposan megfontolni, hogy mikor és mennyi erőforrást áldozunk ezeknek a rendszereknek a fejlesztésére. Ami eleinte csak „néhány szkript” kifejlesztésének tűnik, az a későbbiek során akár az eredeti fejlesztési költségek többszörösébe is kerülhet, igazítva a szkripteket a változó (megrendelői) igényekhez és a fejlesztett rendszerben történő, a tesztrendszert is érintő átalakításokhoz. Ha módunkban áll és még a projektünk elején tartunk, érdemes a minőségbiztosítási folyamatunkat manuális tesztelők bevonásával és ésszerűbb automatizálással hatékonyabbá, és ami talán még fontosabb, költséghatékonnyá tenni.

Összefoglalva tapasztalatainkat azt mondhatjuk, hogy a szélsőséges megoldások sohasem hatékonyak. Meg kell találnunk az egészséges arányt a manuális tesztelés és az automatizálás között – nyilatkozta Szűts Béla. Nyilván a rendszeres regressziós tesztelést nem érdemes manuálisan végeznünk, de nem szabad túl sok erőforrást fordítanunk az automatizálásra sem, mert a karbantartási költségek utána túlzóak lesznek még a legjobb objektum ID alapú szkriptek esetén is. Akár automatizálni szeretnénk, akár a manuális tesztelésnek szavazunk nagyobb bizalmat, érdemes szakértők segítségét kérnünk a rendszerünk kialakításához, hogy majd meg tudjuk találni az adottságainknak leginkább megfelelő arányokat.