Ahhoz, hogy megmutassuk a közösségi tesztelés előnyeit és hátrányait, vagyis megtaláljuk a helyét a mindennapi üzleti gyakorlatban, először vegyük górcső alá, hogyan működik a „hagyományos" szoftvertesztelés, amin itt az alkalmazott, hivatásos szoftvertesztelők munkáját értjük!
Tesztelők a vízesés alján
A tesztelés legalapvetőbb célja, hogy a termékfejlesztés minél korábbi fázisában fényt derítsen a hibákra, hogy azok minél alacsonyabb költségen javíthatók legyenek. Szoftverek, különösen komplex rendszerek esetében a gyakorlatban nem létezik hibamentes állapot, ezért a feladat a minőség mérése és meghatározott szintre emelése. Ez kiegészülhet a felhasználó kockázatainak becslésével és kezelésével. A tesztelés tehát a minőségbiztosítási folyamat része, hiszen egy elvárásnak való megfelelésről van itt szó. A problémát az jelenti már első körben is, hogy kinek milyen elvárásának kell megfelelni.
A fejlesztők természetesen egy specifikációnak való minél teljesebb megfelelést értik ezen. Viszont érthető módon mindez a felhasználókat teljes mértékben hidegen hagyja. A hibásan specifikált fejlesztéseket éppúgy minőségi hiányosságnak érzékelik, mint az azoktól való eltéréseket. Ebből következik, hogy egy szoftver minősége már a specifikációnál jelentősen meghatározott. Ennek ellenére a terméktervezést sokszor nem értik bele a fejlesztés folyamatába. A piacon általában azok a fejlesztővállalatok a sikeresek, amelyek ügyféllel a középpontban közelítenek a minőséghez, és nagy hangsúlyt fektetnek a felhasználói igények feltérképezésére és specifikálására. A következő minőségi értelmezési szint a tulajdonosi értelmezés - utóbbinak profitelvárásai vannak. Leegyszerűsítve, a tulajdonosok számára a termék azon tulajdonságai jelentik a minőséget, amiért a vevő magasabb árat hajlandó fizetni.
A hagyományos szoftvertesztelésen belül is van egy tradicionális vonal, amely kizárólag az elkészült szoftvert vizsgálja. A fejlesztők ilyenkor az elkészült terméket és annak funkcionális, valamint technikai specifikációját átadják a tesztelő csapatnak, amely elkészíti a tesztelési tervezetet, majd végig is viszi azt. A talált hibákat visszacsatolják a fejlesztőknek, akik nekiállnak kijavítani azokat, majd a folyamat kezdődik elölről. Ez a megközelítés viszonylag kevés tesztelőt igényel, viszont nem kedvez a gyors fejlesztéseknek, főleg dinamikusan változó specifikáció esetén, amit piacra készülő (nem egyedi fejlesztésű) szoftver esetében a turbulens piaci környezet generál.
Tesztelés az első pillanattól
Ennél újabb, rohamosan terjedő fejlesztési metódus az agilis fejlesztési modell, amely a sikeres japán gyártók lean, folyamatalapú megközelítését igyekszik a korábban túlzottan projekt szemléletű szoftverfejlesztésbe implementálni. A különbség nagyjából ahhoz hasonlítható, amikor az emberiség a manufakturális termék-előállításról áttért a gyártásra.
Az agilis modellekben a tesztelők napi szinten együttműködnek a fejlesztőkkel a teljes folyamat legkorábbi fázisától kezdve. Ez azt jelenti, hogy sokkal több fejlesztési időt kell tervezni, hiszen - látszólag feleslegesen - a szoftver minden porcikáját rengetegszer fogják tesztelni, miközben tudják, hogy mind a kód, mind a specifikáció még sokat fog változni. Összességében mégis gyorsabb és rugalmasabb fejlesztést kapunk, ahol a problémák még a keletkezésük idején és helyén napvilágra kerülnek és javítják őket. A megközelítés főleg az alapvető, koncepcionális, architekturális hibák esetében jelent hatalmas előnyt a tradicionális tesztelési folyamatokhoz képest. Az agilis módszer szerinti tesztelés filozófiája hasonló a TQM-éhez vagy a lean menedzsmenthez - ezek azt állítják, hogy a minőséget nem lehet a gyártás végén „beleellenőrizni" a termékbe, hanem a gyártás folyamatát kell úgy alakítani, hogy az minőséget adjon. Az agilis tesztelő napi szinten kalákában dolgozik a termék egyazon részén a fejlesztővel, tulajdonképpen egyenrangú társaként, egy másik szemléletet adva a folyamatba, így a problémák vagy hibás elgondolások akár már az ötlet fázisban kiszűrődhetnek.
Mivel a tesztelők már a termék igen korai, sőt embrionális fázisában is tesztelik az elkészült kódrészeket, nem tudnak olyan egyszerűen megfogalmazott elvek alapján dolgozni, hogy megfelel-e valami a specifikációnak vagy nem. Főleg, hogy a specifikáció az agilis fejlesztésben a fejlesztéssel együtt fokozatosan lesz egyre pontosabb és részletesebb. Ezért a tesztelők különböző szintű és részletességű teszteket használnak. Általában ezeket:
- Unit teszt. A készülő szoftveregységek első körös tesztelése abból a célból, hogy a fejlesztésnek biztos, jó minőségű alapot szolgáltassanak. Mivel a tesztelt egységek (unitok) funkcionálisan nehezen értelmezhetők, ezért a unit tesztesetek definiálásához nagymértékben szükséges a fejlesztők tevékeny hozzájárulása. Az együttműködés talán itt a legszorosabb fejlesztő és tesztelő között.
- Modul (integrációs) teszt. Ebben a fázisban a szoftverelemek modulokká állnak össze, amelyek már jól értelmezhető funkciókat valósítanak meg. Mivel ekkor még nincs felhasználói felület (GUI), ezért itt szintén a programozási nyelvet jól ismerő tesztelők kerülnek előtérbe, akik saját scriptjeiket és parancsaikat használják. A tesztelésnek ez a fázisa a legjobban automatizálható, hiszen csak egy jól körülhatárolható rendszerünk van bemenetekkel és kimenetekkel. Ezen a szinten kell foglalkozni a modulok együttműködési képességével is, amely az interface specifikáció ismeretében tesztelhető.
- Rendszerteszt. A szoftver tesztelése a normál felhasználói interfészeken keresztül. Ez az a fázis, amikor a specifikációnak való megfelelést első ízben vizsgálják a teljes termékre. Jellemzően jól automatizálható.
- Elfogadási teszt. Az a fázis, amikor a megrendelő átveszi a terméket. Itt a tesztesetek valós felhasználást szimulálnak, és azokat a megrendelő bevonásával készítik el. Egyedi fejlesztés esetén a megrendelő a jövőbeli felhasználó, amíg piacra szánt termék esetén ez a termékmenedzser vagy a marketing.
A közösség színre lép
Ha ezekhez a szoftvertesztelési módszerkhez és szintekhez hasonlítjuk a közösségi tesztelést, akkor a következő alapvető megállapításokat kell tennünk:
Hátrányok
- A közösség tesztelői nem képesek unit- és modulteszteket végezni, vagyis agilis fejlesztésekbe csak korlátozottan vonhatók be. Még akkor is, ha gyakran adunk ki korai szoftververziókat is.
- Nem tesztelési tervezet szerint haladnak, ezért nem lehetünk biztosak a teljes körű - tesztelésben.
Előnyök
- A közösségi tesztelők elvileg ingyen dolgoznak nekünk. A gyakorlatban van némi költsége a közösségi infrastruktúrának, de ha a közösség kellő méretű, akkor ez bőven megtérül.
- Közösségi tesztelőink akár több tízszer vagy százszor többen lehetnek, mint a belső csapat.
- A közösségi tesztelők általában felhasználók is egyben, így olyan szemmel képesek tesztelni a terméket, ahogy a belső tesztelők sosem lesznek képesek.
Mindezek alapján kimondhatjuk, hogy a közösségi tesztelés nem helyettesítheti a belső tesztelői kapacitást, de jól kiegészítheti azt. Ez a kijelentés azonban nem fejezi ki teljes mértékben a közösség jelentőségét, amely méreténél és összetételénél fogva iszonyatos versenyelőnyt biztosíthat a fejlesztőcégek számára. Azt adják ugyanis a cégek számára, amiben azok leginkább szegények: információt a felhasználói igényekről, elvárásokról, szokásokról. A közösségi tesztelő szemében a nem megfelelői működés éppolyan hiba, mint egy hiányzó funkció. Az ő tesztelésükből tehát nemcsak a hibákat, de az elvárásokat is meg lehet ismerni.
És miről beszéltünk a cikk legelején? Egy jó specifikáció már fél siker!
A közösség segítségével rajta tarthatjuk ujjunkat a piac ütőerén, és idejekorán azonosíthatjuk azokat a felhasználói igényeket, amelyek a jövőben elvárásokként jelentkeznek majd. Egy jól menedzselt felhasználói közösséggel tulajdonképp beemeljük a felhasználót az értékteremtési láncba, hiszen az ő segítségével fogjuk specifikálni termékeinket.
A szerző a BalaBit marketingvezetője
