A tesztpiramis és a kódlenyomat

Hogyan tudjuk növelni a tesztelésünk hatékonyságát? Például úgy, hogy releváns teszteket választunk egy-egy funkcióra, folyamatra, ezáltal csökkentjük a felesleges tesztek futtatásával járó időveszteséget.

Talán ismeritek a híres tesztpiramist, melyet Mike Cohn (http://en.wikipedia.org/wiki/Mike_Cohn), a Scrum Alliance (http://www.scrumalliance.org/) egyik alapítója alkotott meg. A piramist számtalanszor használták és módosították. Most rajtam a sor, hogy feltöltsem a piramist!

A tesztpiramis

Azok számára, akiknek új a tesztpiramis (vagy csak elfelejtették), az elv a következő: az alsó sornak kell leginkább automatizálva lennie: ez adja a legjobb befektetési megtérülést, mivel a fejlesztők könnyedén írnak egységteszteket, melyektől azonnali visszajelzést kapnak (1. ábra). Minél inkább automatizált az egységteszt, annál erősebb lesz az alap.

A középső sort már sokkal nehezebb automatizálni, mint az alapot, és az itt lévő tesztek a piacramutató tesztekre fókuszálnak. Ezek a funkcionális tesztek adják meg az „A megfelelő dolgot építjük?” kérdésre a választ. Ez fogja biztosítani, hogy a funkcionalitás megfelel az elvárásoknak.

A legfelső sor lesz a legkevésbé automatizált, mivel ezen a szinten jórészt UI-tesztelés folyik, melyeknek költséges a megírása vagy karbantartása, és gyakorta szorulnak emberi felügyeletre (például vizuális szempontból).

Ami a piramisból hiányzik

Úgy gondolom, hogy a piramis igen hasznos, és a tesztcsapatok hatékonyabbak lehetnek ezt az elvet követve. Ám valami hiányzik…

Ebben a többrétegű rendszerben a teszteket különböző emberek végzik, és mindegyik teszt más természetű. Ez egy újabb problémát hoz fel: nincs egy aggregált elképzelés ezekről a tesztekről. Például nehéz átlátni az egész elfogadási és GUI-tesztek halmazát.

Ennek okán a csapatok „tesztelési lyukakat” hagyhatnak az alkalmazásban: a szoftver olyan részei, melyeken semmilyen tesztet sem végeztek, így a tesztelés során ezeken a részeken nagyobb eséllyel csúsznak át a hibák a hálón (2. ábra)

Ugyanakkor szinte lehetetlen 100%-os tesztelési lefedettséget elérni a szoftvernél. Hogyan kezeljük tehát ezeket a „tesztelési lyukakat”, hogy eldönthessük, milyen további tesztek szükségesek? Két megoldást ajánlunk erre:

1.    Regressziós kockázatok figyelése

A lényeg az, hogy összevesd a tesztelésre váró szoftver jelenlegi verzióját a korábbi verzióval. Ez az összehasonlítás segít, hogy megtaláld azokat a változásokat, ahol magas a regressziós kockázat. Összevetve ezt az információt a tesztlefedettséggel, egyértelműen rámutat azon regressziós hibákra, melyek kimaradtak a tesztelésből.
Mivel egy kép többet ér minden szónál, hadd mutassam be ezt az elvet a 3. ábrán.

2.    Üzleti szemlélet hozzáadása

De még a teszt nélküli változásokra figyelve is túl nagy falat lehet az egész, ha nincs meg a kellő mennyiségű automatizált teszt. Éppen ezért ajánljuk az üzleti szemlélet hozzáadását: áss a mélyére, hogy megértsd a funkciók vagy a szoftver funkcionális részei általi változásokat. Így a megfelelő fontossági sorrend érdekében tudsz további teszteket biztosítani ott, ahol a hibákat el kell kerülni.

Rendben, de mit teszünk akkor, ha nincs kellő számú automatizált tesztünk? 

Ugorjunk a piramis csúcsára. Ez az a pont, ahol több manuális tesztre van szükséged, ha kevés az automatikus teszt. Egy ilyen szituációban nem lesz elég időd minden alkalommal az összes manuális teszt végrehajtására. Ki kell választanod a lényeges teszteket, a fontosságuknak és az alsóbb szinteken kimaradt teszteknek megfelelően végrehajtani azokat.

A változások, a lefedettség és az üzleti szemlélet egyesítésével nemcsak jobban fogod tudni beosztani a tesztelésre szánt időt az automatizált és manuális tesztek kiegyensúlyozásával, de még a lényeges tesztekre is jobban figyelhetsz (elkerülve ezáltal a felesleges teszteket), és biztosíthatod a kockázatok lefedését az alkalmazásban.

Tesztlenyomat hozzáadása

A tesztelés során a Kalistick’s agent (http://www.kalistick.com/) képes rögzíteni az összes végrehajtott utat az alkalmazásban. Ez nem a felvételről/visszajátszásról szól, hanem a tesztesetek összekapcsolásáról, és úgy írni a kódot, hogy ha az adott verzióban változások történnek, akkor a releváns tesztesetekkel lefedhetőek és azonosíthatóak a regressziós kockázatok.
És mint el tudod képzelni, ez a technológia önfejlesztő. Minél több tesztet futtatsz, annál jobban ráérez a szoftver, és képes lesz sokkal hatékonyabb regressziós tesztstratégiák kidolgozására (http://www.kalistick.com/how-to-increase-software-test-efficiency.html).

A technológia célja kettős:

• Növelni a teszt hatékonyságát releváns tesztek kiválasztásával a tesztsorozatra, és elkerülni az időveszteséget a felesleges tesztekkel, melyek nem tesztelik a megváltozott modulokat.
• Biztosítja, hogy minden kockázat le van fedve, még bizonyos közvetett változások (általában regressziós) általi közvetett kockázatok is.

Tanulság

Az utadon, mely a piramis egyes szintjein lévő automatizált és manuális tesztek egyensúlya felé vezet, ez a technológia segíteni fog a szoftvertesztelési hatékonyságod növelésében.

Forrás: http://testingcircus.web.officelive.com/Documents/Testing-Circus-Vol3-Edition1-January-2012.pdf
Szerző: Marc Rambert