Hogyan javítsd a regressziós teszteléseid eredményességét 30%-kal?
A cél az, hogy biztosítsuk az alkalmazás minőségét a lehető legjobb regressziós lefedettséggel, és minél kevesebb teszt futtatásával. Úgy látszik mintha lehetetlen lenne egyszerre az időn és a minőségen is nyerni? Lássuk hogy képes növelni 30%-kal a hatáselemzés a tesztelés hatékonyságát.
Regressziós tesztelés
Sokszor fejfájást okoz nekem. A regressziós tesztelés fontos része az átfogó tesztelési erőfeszítéseknek minden egyes szoftver kiadásnál. Szükség van ezekre a tesztekre, mert olyan problémákat észlelnek, amelyek észrevétlenül előbukkannak. Ugyanakkor ők is gyakran átszaladnak a hibák felett, amelyeket a telepítés után találunk meg, amikor már a hibák kijavításának becsült költsége 10-szer nagyobb (diagnosztika, javítás, tesztelés, telepítés, üzleti hatás, stb.).
A regressziós tesztelés hatékonyságához az szükséges hogy:
- Minden szoftverkiadásnál csökkentsük a hibázás kockázatát, és válasszuk ki a megfelelő teszteseteket, hogy melyek fussanak a regresszióra szentelt időkeretben.
- Legyünk fogékonyak az üzleti igényekre a gyorsabb és kisebb kiadásoknál. Ez persze megköveteli a gyorsabb és hatékonyabb regressziós tesztelést. Képesnek kell lennünk arra, hogy minden egyes verzió kiadásnál a tartalomhoz mérten hatékonyan tervezzük meg a regressziós teszt kampányainkat.
- Megfelelő mennyiségű erőforrással tervezzünk.
Mennyi regressziós teszt kell?
A legtöbb projektnél – még a kisebbeknél is – bebizonyítható, hogy regressziós tesztelés nélkül, akkor a tesztelési feladatok könnyen kezelhetetlenné válnak. Az alábbi ábra illusztrálja azt, amikor minden egyénileg létrejött tesztet minden verziónál hozzáadunk a futtatandó teszteset halmazunkhoz.

Hogy kell megtervezni egy regressziós teszt stratégiát?
Ajánlott beletenni a tesztelési stratégiába a regressziós tesztelés egyedi megközelítését, hogy korlátozni tudjuk a manuális tesztek számát. Ami alapvetően két típusú tesztet jelent:
- A főbb funkciókhoz kapcsolódó tesztesetek, követelmények és kockázatok szerinti prioritással.
- Olyan funkciókhoz kapcsolódó tesztesetek, amelyek bizonyíthatóan kevésbé erősek (ahol a funkcionalitásban hibát találtak és/vagy a korábbi release-nél valamelyik regressziós tesztben volt hiba).
Mindazonáltal, ha ezek a kritériumok nagyban csökkentik a tesztesetek számát, akkor nem lesznek alkalmasak minden egyes szoftver release-hez. Eljuthatunk odáig, hogy folyamatosan ugyanazon teszteset sorozatot hajtjuk végre, aminek gyakran az az eredménye, hogy a regressziónk felületes lesz és nem találjuk meg vele az alapvető hibákat. Hogy lehetne ezt jobban csinálni?
Teszt automatizálás
Úgy látszik, hogy az automatizált tesztelés a Szent Grál: Hajtsuk végre az összes tesztet minden egyes verzión, egy korlátozott időkereten belül. A nagyobb teszteset darabszám jobb funkcionális lefedettséghez és ezáltal jobb minőséghez is vezet.
A valóság egy kicsivel másabb. A platformunkon készült statisztikák szerint 80%-a a projekteknek nem tartalmaz automatizált funkcionális tesztelést, 15%-uk korlátozott automatizált tesztelésre fókuszál és mindössze 5% használ intenzív automatizált stratégiát.
Miért olyan kevés az automatizált tesztelés? Az ügyfelek szerint nem mindig gyorsabb és olcsóbb automatizálni, mivel a tesztek létrehozása és karbantartása jelentős terhet jelent. A tesztautomatizálás jó választás lehet, de csakis akkor ha jól megközelítve van felépítve.
Hatékonyság elemzés a szoftvertesztelés optimalizálására
Miért kell hatékonyság elemzés?
Amikor az alkalmazás új verzióját kiadják, amibe belekerültek a javítások, módosítások és új funkciók, a fejlesztő csapatok változtatnak az alkalmazás kódján. Ezek a változtatások kihathatnak a már működő funkciókra is.
Kapcsolódnak a tesztek a módosításokhoz?
A mi kutatásaink – együttműködve számos kutatási központtal – kimutatták, hogy a valószínűsége annak, hogy megtaláljunk egy hibát egy speciális teszttel, közvetlenül a kódmódosításhoz kapcsolódik, amin ezt a tesztet futtatni fogjuk.
A hatékonyság elemzés célja tehát az, hogy kapcsolatot teremtsen a kódbeli változások és a tesztek között. Ez az elemzés lehetetlen eszköz nélkül, a jelenlegi eszközök adnak némi technikai segítséget, de teszteset szinten már nem adnak eredményt.
Hogy ezt a hiányosságot megszüntessük, a Kalistick kifejlesztett egy “Teszt pontozás“-t. Minden kiadott alkalmazásverzión minden teszteset pontozva lett a lefedett módosítások számossága alapján. Ez a pontszám három egyedi technikán alapszik:
- A teszteset lábnyoma. Amikor egy tesztelő végrehajt egy tesztet, a Kalistick rendszer automatikusan lejegyzi az összes futtatott kódot, ami az alkalmazásban lefutott a teszt során. Ez a „lábnyom” biztosítja a kapcsolatot a teszteset és a kód között; ez egy tudásbázisban tárolódik.
- Változás érzékelés. A Kalistick szkennere minden egyes verziónál érzékeli és elemzi a változásokat azáltal, hogy összehasonlítja az eredményeket az előzőkkel.
- A Kalistick motorja elemzi a teszteset lábnyomokat, hogy felmérje a módosítások hatását és kiszámolja a teszt pontszámokat.
Az elv a következő: amint egy teszt lefut, a rendszer eltárolja. Minden jövőbeli verziónál pontozva és vizsgálva lesz, szükséges-e újból végrehajtani.
Az ügyfelek a saját tesztelési eszközeiken pontoznak mint a HP Quality Center, HP ALM, TestLink, XStudio, ReferTest, stb. A Kalistick plug-in-jei zökkenőmentesen integrálhatóak, tehát a tesztcsapatok biztosra vehetik, hogy teszt kampányaik hatékonysága nőni fog.
Eredmények
Ez a tesztelés hatékonyságát 30%-kal növelheti, ami két tengelyen mérhető: minőség, és idő. Bemutatok két esetet, hogy láthassuk az előnyöket:
- Az ügyfél végrehajtja a szokásos teszt sorozatát, majd kiválaszt 10 tesztesetet futtatásra, a Kalistick pontozást alkalmazva.
- A másik ügyfél úgy méri a minőséget minden egyes alkalmazásverzión, hogy megszámolja a hibák számát az éles környezetben amiket a termékben talál 3 hónappal a kiadás után. Az első Kalistick-kel tesztelt kiadásnál, a hibák száma 50%-kal kevesebb, ami több tízezer dollár megtakarítást hozott.
Az alábbi linkeken letölthető egy segítség “30, a kulcsszám a teszt hatékonyságáért” és a terméklapot “Intelligens Tesztlefedettség” ami rávilágít a kulcsfontosságú szolgáltatásokra.
Forrás: http://blog.kalistick.com/tools/improving-regression-testing-effectiveness/
Szerző: Marc Rambert
A szerző

-
Marc Rambert a Kalistick (www.kalistick.com) társ- alapítója.
Néhány Svéd- országban és Dániában töltött év után visszatért Franciaországba, és a Kalistick társalapítójaként megalkotott egy egyedi tesztelést javító szoftvert.
Az IT világában szerzett tapasztalatának hála átlátja a szoftverfejlesztés és tesztelési eljárás egészét, és kimondottan érdekelt az agilis tesztelésben.
Az innovatív ötleteinek köszönhetően Kalistick számtalan díjat kapott az évek során. Szereti az innovációt, és szívesen megosztja ötleteit. Ha te is így teszel, kövesd twitter-en: @MarcRambert