Történet a teszteset végrehajtásról

Csináltam egy EuroSTAR webináriumot ami a leszállítandó termékrõl szólt, és arról mennyire rossz hatással vannak a termékre a teszteset mérõszámok. Eszembe jutott róla egy történetet, amit most megosztok.

Nagyon általános dolog, hogy a tesztelõ csapatok a teszteset mérõszámok és mértékegységek alapján dolgoznak és ez alapján megy a számonkérés is, illetve ez alapján megy a tervezés és a tesztelési folyamat mérése is. Nagyon félrevezetõ lehet ez a megközelítés.

A leggyakoribb mérõszám, amit használok és látom, hogy a legtöbb szaktársam is ez alapján dolgozik, hogy mennyi tesztesetet futtatok. Klasszikus. Ez a mérõszám legtöbbször a tervezéshez és a munka méréséhez használatos, de nagyon kényes szempont lehet az új szoftverkiadásoknál.

Így megy

Gondoljuk el, hogy van egy 10 tagú tesztcsapat és van összesen 1000 teszteset. Az eddigi becslésünk szerint azt mondhatjuk, hogy minden tesztelõ megcsinál 10 tesztesetet naponta. Ez akkor azt jelenti, hogy az 1000 tesztesetre 10 nap szükséges a csapatnak, ugye?

Tervezését ennyire egyszerûen csináljuk: „10 napot igényel az 1000 teszteset lefuttatása“. Ez történik minden egyes tesztelési projektben. A tesztesetek száma és a becsült tesztfuttatások aránya lesz az elsõdleges faktora a teszt tervezésnek és az ütemezésnek. A mérõszámot a tesztelési munka elõrehaladottságának a mérésére is használhatjuk/használjuk. Az elsõ nap kész lesz 100 tesztesetünk, az ötödik nap pedig 500.

Ha nem jönnek ezek a számok, akkor változtatnunk kell, a csapattagokat túlmunkára kell kérnünk az eredményesség érdekében: pl. Futtassanak 15 teszteset naponta. Esetleg bevonunk még tesztelõket a folyamatba, vagy egyszerûen kiválasztunk olyan teszteseteket, amiket nem futtatunk le.

A probléma

Tisztán látható mi a probléma ezzel a megközelítéssel. Maguk a problémák nincsenek hatással a tervezésre. Egyfelõl az a gondunk, hogy a tesztesetek nem egyformák. Némelyik futtatása órákat is igénybe vehet – vannak olyanok amelyek akár napokat is – de természetesen lesznek olyanok is, amelyeket néhány perc alatt lefuttathatunk.

Másrészrõl az elbizakodottság okozhat fejtörést abban a tekintetben, hogy csak azokat a teszteket kell elvégezni, amelyeket a tesztesetekben látunk. Harmadrészt sokszor azt feltételezzük, hogy minden tesztelõ egy robot és minden nap ugyanolyan tesztelésre képes. Mindenkinek lehet jobb és rosszabb napja, szóval ez a felfogás is hibás. Létezik még egy probléma, hogy a tesztelõ nem tudja megtalálni a hibát, így késlekedés lesz és többletmunkát kell beletenni, hogy végül mégis elkapjuk a hibát.

A történet

A vállalat gigantikus mennyiségû regressziós tesztet végez ahol a tesztesetek a végsõ kiadás elõtti ellenõrzésre szolgálnak. Akár 3000-nél is több teszteset jöhet létre, amely egy hatalmas táblázatban lesz tárolva. Az elvárás az volt, hogy minden tesztelõ naponta 10 tesztesetet futtasson, és a tervek alapján lehetséges, hogy az összes teszteset futtatásra kerül.

Íme, mi történik: Reggel 5:30 magasságában a regressziós tesztcsapat elsõ fele megérkezik és elkezdik futtatni a teszteseteket. Elõször a legegyszerûbb esteteket fogják elõvenni, amelyek futtatása csak néhány percet vesz majd igénybe. Még 50%-kal több tesztesetet is beterveznek, amit majd futtatni akarnak.

Elõször is azért, mert kérték tõlük, hogy több tesztesetet futtassanak, így jó elõre betáraznak néhány egyszerû teszteset. Ha másért nem hát azért ez a szorgalom, hogy ebédidõben nyugodtan megehessenek egy finom pizzát.

Másodszor, ha nem is kérték õket túlmunkára, nekik már így is több tesztesetük van rögzítve a nevük mellé, mint másoknak, vagyis a vezetõség láthatja, hogy mindent megtesznek a siker érdekében.A második csapat reggel 8-ra jön így nekik maradtak a hosszadalmas tesztesetek. Némelyik tesztesetnek a környezet- és rendszerbeállításai, valamint a futtatása napokat is igénybe vehet. Mindenkinek rögzítenie kell a gigantikus Excelben, hogy adott napon mennyi tesztesetet futtatott, amit a vezetõk naponta ellenõriznek. Az elsõ csoport napi 10-et rögzít, a második csapat 2 vagy 3 esetet.Az elsõ csapat néhány tagja a fennmaradt idõben netezik, pedig ehelyett segíthetne a többieknek a további tesztfuttatásokkal. De õk inkább korábban hazamennek.

Az elsõ csapatból bárki simán kijátszhatja a rendszert, habár azt csinálják amit kértek tõlük, és ez a mérõszámokban is meglátszik.

Nem meglepõ, de a második csapat tagjai egyszerûen nem fogják tudni a tesztesetek összes lépését lefuttatni, így gyakran beállítják ellenõrzöttnek azokat az eseteket, amelyeket le sem futtattak azért, hogy megpróbálják megközelíteni az elvárt napi 10 esetet. Amikor azzal szembesülsz, hogy egyes tesztesetekhez a környezet beállítása akár 1 napig is tarthat, te mit tennél?

A projekt csúszik és többletmunkával is jár a késõbbiekben. Ebben az a veszélyes, hogy mindig ugyanez fog történni. Amikor a teszteset mérõszámokat vesszük a tervezés és a mérés alapjául, akkor gyakorlatilag visszaélésekre és csalásokra hívjuk fel a csapattagokat.

Mi lehet az alternatíva?

Nem kérdés, rengeteg alternatíva létezik, viszont nincs rendszer vagy mérõeszköz, ami alól ne lehetne kibújni, vagy ne lehetne meghamisítani.

Az én ajánlásom az lenne, hogy vigyük közelebb a tesztelést a kódoláshoz azáltal, hogy megnöveljük a viselkedés alapú tesztelést, valamint a unit tesztek számát. Ezt követõen amilyen gyorsan csak lehet hozzunk létre tesztkörnyezeteket.

Ha ez a megoldás mûködik, nincs szükség tesztesetekre (pontosabban számos tesztesetre nem lesz szükség), mert az ellenõrzés sok helyen automatizálható lesz, így a teszteset mérõszámokra sem lesz a továbbiakban szükség.

Az automatizált ellenõrzés az eredmény részét fogja képezni, és felmenti a tesztelõket a termék, vagy alkalmazás felfedezése alól. A tesztesetek (ellenõrzések) sohasem fognak futni (nincs értelme), így a tesztcsapatnak rengeteg ideje szabadul fel.

Természetesen ez a változás nem egyszerû (tudom, mert volt már hozzá szerencsém), de ha kis lépésekkel haladunk elõre, szinten minden tekintetben elérhetõ a változás. Az igazi kérdés az: mennyit vagy hajlandó kísérletezni a tesztelésben, a riportolásban és a projekt menedzsmentben?

A teszteset mérõszám egy csomó csapdát rejteget és alapjában egy rossz iránymutatás. Ha már használjuk legalább annyit tartsunk szem elõtt, hogy kisebb pozitív lépésekkel (apróbb változtatásokkal a tesztelési módszerben, vagy a mérési rendszerben) a tesztelési folyamat minõsége javítható és ez a szemlélet közelebb visz a jobb minõséghez.

Forrás: http://thesocialtester.co.uk/test-case-completion-a-story/
Szerző: Rob Lambert