Példa a teszt stratégiára

A teszt stratégia egy terv (amely létezhet projekt, program, szervezet, vagy akár csoport szinten is), ami leírja, hogyan tudjuk a meglévõ erõforrásokkal a tesztelési célokat hatékonyan teljesíteni. Ha létezik teszt stratégiád, akkor egyszerûen tudod azonosítani a legfontosabb tesztelési folyamatokat. Sõt, világossá teszi a tesztelés fontosságát a megrendelõk, tulajdonosok számára is.

Korábban már beszéltem az eredményes tesztelési stratégia kialakításáról, a web analitikák, értelmezhetõség megvilágításában. Legtöbb olvasóm példákat várt a teszt stratégia dokumentumra, ami nem minden projekt esetében osztható meg.

Ezért megkértem Varsha-t, aki tapasztalt tesztelõként tagja a „Softver Testing Space” közösségnek, hogy készítsen egy példát egy hipotetikus agile projektre. Alább megtalálható az eredmény, a dokumentum, amely remélhetõleg nagy információtartalommal bír.

A kiegészítések dõlten vannak szedve. Abban reménykedek, hogy a példa dokumentum segítséget nyújt majd számodre egy igazán hatékony teszt stratégia létrehozásában. Elõször érdemes megnézni egy videót: http://youtu.be/vm5kGy6URjM, aztán a dokumentumot.

Bevezetés az Agile-ba

Az agile egy iteratív és inkrementális megközelítés a szoftverfejlesztésben, amely a csoporttagok egy kontrollált környezetben történõ erõs kooperációján/együttmûködésén alapul. A magas minõségû alkalmazások általában kis fejlesztõi csoportok együttmûködésének az eredménye, akik a folyamatos fejlesztés és tesztelés elve alapján gyors visszajelzésekkel és változtatásokkal dolgoznak. Az agile ember középpontú, a fejlesztés és a tesztelés integrálva van. Az önszervezõdõ munkacsoportok minden esetben a legjobb megoldásra törekszenek, és a felhasználó kulcsfontosságú szerepet játszik, továbbá a projekt életciklust a végtermék követelményei határozzák meg.

Mi a különbség az agile és a vízesés modell között?

  • Jobb együttmûködés
  • Rövidebb fejlesztési idõ és állandó visszajelzések
  • Elfogadott változtatások
  • Nagyobb rugalmasság
  • Nagyobb fegyelem
  • A cél a minõség, nem csak a sebesség
  • A megrendelõ nagyobb rálátása a munkára
  • A tapasztalatok nagyobb skálája
  • Többet és gyorsabban csinálni
  • Bátorság/kitartás
  • Bizalom a tervezésben

A dokumentum célja

A teszt stratégia dokumentumot azért készítjük el, hogy egy mindenki által érthetõ leírást adjunk a célokról, feladatokról, eszközökrõl és a tesztelés ütemezésérõl. Célunk a magasabb minõség elérése, valamint a projektre fordítandó idõ, többlet energia csökkentése, gyakoribb teljesítés, szorosabb munka a megrendelõ és a csapat között, folyamatos integráció, rövidebb visszajelzési utak és gyakoribb funkció változtatások a minõség érdekében. A teszt stratégia egy kalauz az akadályok leküzdéséhez. A tesztelési munka a követelmények felderítésével kezdõdik és azzal, hogy a felhasználói sztorik segítségével különbözõ nézõpontokból kiderítsük, mit akar a megrendelõ valójában. A tesztelés egy folyamatos és integrált folyamattá válik, ahol minden szereplõ bevonásra kerül.

Irányadó szabályok

  • Szabály Leírás.
  • Megosztott felelõsség: A csapat minden tagja felelõs a minõségért.
  • Adatkezelés: Az adatok ellenõrzése a tesztekben való felhasználás elõtt.
  • Tesztmenedzsment: Tesztesetek, kódok, dokumentumok és adatok ugyanolyan fontosak, mint az éles rendszerben.
  • Automatizálás: Odafigyelés az összes automata tesztre (unit, funkcionális, regressziós, teljesítmény, biztonság).

Követelmény stratégia

  • Mindig a legfontosabb elemek implementálásával kezdjünk. Minden elem, feladat priorizálása és kiosztása a termékfelelõs feladata.
  • Minden feladat vagy munkafolyamat bármikor újraütemezhetõ.
  • Egy bonyolultabb modul minden esetben magasabb prioritást élvez, mint egy egyszerûbb.

Minõségi és tesztelési célok

TulajdonságLeírásMérés és célFontosság
PontosságA tulajdonságok és funkciók a definíció szerint mûködjenek, úgy ahogy a követelmény szól. 100% készültség a következõ:
  • Kritikus hibák száma = 0
  • Súlyos hibák száma = 0
  • Csekély hibák száma < 5
  • Triviális hibák száma < 10
Kell
IntegrációKépes legyen megelõzni az illetéktelen belépéseket, az adatvesztést, vírusok ellen nyújtson védelmet, a felvett adatok helyességét ellenõrizze.
  • HTTPS-en vagy biztonságos kapcsolaton keresztül lehessen hozzáférni.
  • Felhasználói jelszavak és session tokenek titkosítva legyenek.
Kell
KarbantartásEgyszerû legyen az új funkciók beépítése, a hibák javítása és az újabb verziók kezelése.
  • Kód duplikáció < 5%
  • Komplexitás < 8
  • Unit Teszt-lefedettég > 80%
  • Metódusok hossza < 20 sor
Kell
Rendelkezésre állásA rendelkezésre állás az elvártnak megfelelõ legyen.Rendelkezésre állás 99.99% a log szerintLehet
ÁtjárhatóságEgyszerû legyen a rendszerek közötti kommunikáció.
Több böngészõvel is jól mûködjön.
A következõ böngészõ verziókon fusson:
  • IE >= 9.0
  • Firefox >= 18.0
  • Safari >= 5.0
  • Chrome >= 11.0
Kell
TeljesítményNagyobb terheltség esetén legyen lehetõség a rendszer kapacitásának növelésére.
  • Alkalmazás teljesítmény index > 0.9
  • Válaszidõ < 200ms
  • Sikeres üzenetek száma > 100 pm
Lehet

A tesztelés területe (üzleti és technológiai szempontból is)

Terület: Azonosítani kell, hogy mit tartalmazzon a tesztelés az adott projekten. Nézzük meg mi az új, mi változott és mi a javított az elõzõ verzióhoz képest.

  • (Automatizált) unit tesztelés
  • Kód analízis (statikus és dinamikus)
  • Integrációs tesztelés
  • (Automatizált) tulajdonság és funkció tesztelés
  • Adatkonverzió tesztelése
  • Rendszerteszt
  • (Automatizált) biztonsági tesztelés
  • A környezet tesztelése
  • (Automatizált) performancia tesztelés
  • (Automatizált) regressziós tesztelés
  • Elfogadási tesztek
Nem feladatunk: Annak az azonosítása, hogy mit nem tartalmaz a tesztelés az adott projekten.

Tesztelési típusok

Tesztelési típusDefinícióTeszt eszköz
Unit tesztAz egyes implementációk elemeinek elszigetelt teszteléseXunit test tools (Nunit, Junit), Mock eszközök
Kód analízisKód elemzés és átnézésStatikus eszköz:
Java – Checkstyle, Findbugs, Jtest, AgileJ Structure .Net – FxCop, stypeCop, CodeRush

Dinamikus eszköz:
Avalanche, DynInst, BoundsChecker.
Integrációs tesztAzon hardver- és szoftverelemek kombinációinak a tesztelése, amelyek megjelenhetnek az éles mûködésben.Vector Cast C/C++
Funkcionális teszt Az integrált hardver- és szoftverelemek tesztelése, hogy ellenõrizzük a rendszer egyezi-e a követelményekben leírtakkal:
  • Követelmények 100%-os lefedettsége
  • A fõ folyamatok 100%-os lefedettsége
  • A fõ veszélyek 100%-os lefedettsége
  • Mûködési esetek
  • Mûködési kézikönyvek tesztelés
QTP, Selenium WebDriver, Watir, Canoo webtest, SoapUI Pro
RendszertesztAz egész rendszer tesztje end-to-end folyamatokkal.Selenium, QTP, TestComplete
Biztonsági tesztA titkosított belépés, jelszavak, session-ök ellenõrzése.BFB Tester, CROSS, Flowfinder, Wireshark, WebScarab, Wapiti, X5s, Exploit Me, WebSecurify, N-Stalker
Környezeti tesztMinden ajánlott böngészõ tesztelése.GASP, QEMU, KVM,Xen, PS tools
Teljesítmény tesztTerhelés, skálázhatóság, stabilitás.LoadRunner, JMeter, AgileLoad test, WAPT, LoadUI
Adatkonverzió tesztekAutomatikus és manuális konverziók tesztelése, adatbetöltés az új rendszerbe.DTM, QuerySurge, PICT, Slacker
Regressziós tesztA fontosabb funkciók és a lezárt hibák tesztelése.QTP, Selenium WebDriver
UATA felhasználó eldönti, hogy az adott funkció elfogadható-e vagy sem.Selenium , Watir, iMacros, Agile Acceptance Test Tool

Teszteset tervezés stratégia

  • Specifikáció alapú / Fekete-dobozos technika (ekvivalencia osztályok, határérték ellenõrzés, döntési tábla, állapot traszformáció és használati eset teszt)
  • Struktúra alapú / Fehér-dobozos technika (utasítás lefedettség, döntési lefedettség, feltétel lefedettség, feltételrendszer lefedettség)
  • Tapasztalat alapú tesztelés (Hibatalálgatás és felfedezés)

Teszt környezet stratégia

NévLeírásTesztadatokHasználat
FejlesztõiEz a környezet helyi és specifikus minden egyes fejlesztõi/tesztelõi gépen.Setup szkripten keresztül épül fel.Unit, funkcionális és elfogadási tesztek. Xunit teszt eszközök (Nunit, Junit), Mock eszközök. Forráskód menedzsment, verziókontroll.
IntegrációsA környezet támogatja a folyamatos integrációt a kódváltozás tekintetében és alkalmas a unit és funkcionális tesztelésre is. Továbbá statikus kód alanízisre is lehet használni.Setup szkripten keresztül épül fel.Unit, funkcionális és elfogadási teszt. Statikus kód analízis, folyamatos integrációs eszközök. (Cruise control)
ÁtmenetiA környezet támogatja a felderítõ tesztelést.Manipulált éles adatok.Felderítõ tesztelés
ÉlesÉles környezetAz adatok migráció útján kerülnek be az alkalmazásba.Éles környezetbeli ellenõrzés / tesztelés.

Teszt futtatási stratégia

A tesztelõk a következõ szempontokat tartsák szem elõtt:
  • Az agile tesztelés iteratív.
  • Nincsenek komplett specifikációk a teszteléshez.
  • A tesztelõ legyen flexibilis.
  • A tesztelõk legyenek függetlenek és hatákonyak.
  • Legyenek általános specialisták.
  • A tesztelõk dolgozzanak szorosan együtt a fejlesztõkkel.
  • Az értékes munkán legyen a hangsúly.
  • Rugalmasak legyenek.
  • Fókuszáljunk a mit-re a hogyan helyett.
  • A tesztelõ az agile csapat tagja kell, hogy legyen.
  • Úgy segítsen a csapatnak, ahogy csak tud.
  • Legyen felkészült specialista egy vagy több témában.
  • Rövid visszajelzési idõ.
  • Egyenesen, érthetõen kommunikáljon.
  • A felfedezõ tesztelésen legyen a hangsúly.
  • Határozzuk meg, mit jelent, ha valami kész. Mikor számít valami befejezettnek?
  • Határozzuk meg, mikor lehet folytatni, illetve mikor kell megállni a teszteléssel a szállításoknál. Mely kritériumok szerint haladjanak (idõ, lefedettség, minõség) és hogyan.
Továbbá, ebben a részben leírhatjuk a futtatandó tesztek lépéseinek típusait. A következõ fontos csoportokat különböztetjük meg:
  • A rendszer felépítésének lépései.
  • Az automata tesztek futtatásának lépései.
  • A referencia adatok környezetbe való betöltésének lépései.
  • A tesztfuttatások és kód mérõszámok elõállításának lépései.

Teszt adat menedzsment stratégia

Ez a fejezet a teszt adatok azonosítására és kezelésére használható. Az alábbi irányelveket használhatjuk:
  • Rendszer- és felhasználói elfogadás tesztek – az éles adatok egy részhalmaza használható tesztadatként.
  • Teljesítményteszt és rendelkezésre állási teszt – az éles környezeten lévõ adatmennyiségnek megfelelõ adatot célszerû a teszteknél használni.

Teszt automatizálási stratégia

Válasszunk egy tervezett megközelítést az automata tesztek fejlesztéséhez. Növeljük az automata tesztek minõségét. A következõk figyelembevételével válasszunk teszteseteket az automatizáláshoz:
  • Kockázat
  • Milyen hosszú ideig tart a tesztek manuális futtatása?
  • Mi a költsége az automatizálásnak?
  • Mennyire egyszerû az automatizálás?
  • Hányszor várható a tesztek futtatása?

Test Management

Célszerû a teszt tervet, a teszteseteket és hibákat ugyanabba a rendszerbe rögzíteni. Minden agile eszközt ott kell használni, ahol a tesztesetek, sztorik és teszt tervek vannak tárolva.

Kockázatok

A kockázatokkal és feltételezésekkel a napi stand-upokon kell foglalkozni (a csapattagokkal és a scrum masterrel közösen), melyeket a bejelentést követõen azonnal rögzítünk.

Hibakezelési stratégia

Ideális esetben a hibákat csak akkor kell rögzíteni, ha azok azonnal nem javíthatóak ki. Ilyenkor a reprodukáláshoz pontosan rögzíteni kell a körülményeket és a hiba súlyosságát, hogy az könnyen reprodukálható legyen.

Hiba osztályozás

  • Kritikus: Kritikus hiba az, ami blokkolja az alkalmazás mûködését.
  • Súlyos: A súlyos hiba a mûködésre nincs kihatása, megkerülhetõ, de túlmunkával jár.
  • Csekély: Elenyészõ túlmunkával a mûködést nem befolyásolja.
  • Triviális: Kozmetikai hiba, a mûködést és a kényelmet egyáltalán nem befolyásolja.

Hiba életciklus

  • Hiba azonosítása: Ha a hiba reprodukálható, vegyük fel a hibakezelõ rendszerbe.
  • Hiba priorizáció: A hiba súlyosságától függõen priorizáljuk a backlog-ban.
  • Analízis: Elemzés az elfogadási kritériumok és az implementáció alapján.
  • Megoldás: A változás implementálása és/vagy a hibás tesztek javítása.
  • Ellenõrzés: Futtassuk a tesztet, hogy ellenõrizzük a hiba megoldását és felfedezzük az esetleges regressziót.
  • Lezárás: A hiba lezárása a rendszerben.
Definiáljuk a hibakezelõ alkalmazást!

Megjegyzés: Ez a példa Varsha Tomarral együttmûködve lett kialakítva. Varsha 9 éves tapasztalattal rendelkezik mind a manuális mind az automatikus tesztelésben. Ma a Vinculum Solutions-nál dolgozik, mint szenior tesztvezetõ. A szoftvertesztelés, az automatizálás, a tréningek, a tesztelési módszertanok és a felfedezõ jellegû tesztelés is az érdeklõdési körébe tartoznak.

Forrás: http://inderpsingh.blogspot.hu/2013/03/ExampleTestStrategy.html#more

Szerző:
Inder P. Singh

<< Vissza