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.

Eredeti cikk:
http://blog.kalistick.com/tools/improving-regression-testing-effectiveness/


Szerző:
Marc Rambert

<< Vissza