Hogyan kezelje tesztdokumentációit lean megközelítéssel?

Egy kis történelem

Közel 70 évvel ezelőtt 1947-ben megtalálták az első számítógépes hibát a Mark II Aiken Relay Computer-en a Harvard Egyetemen. Tény, ez egy valódi bogár volt: egy lepke szorult a relék közé. (A számítógépes hibát bug-nak hívjuk, ami bogarat jelent angolul – Ford.) A „bug” kifejezést már korábban is alkalmazták, de miután Grace Hopper naplójában leírta “az első tényleges hiba” kifejezést, annyira népszerűvé vált, hogy még ma is használjuk. Ha van néhány perce, és többet akar tudni a vicces eredettel kapcsolatban, olvassa el az első rögzített számítógépes hibáról szóló cikket.

“Sajnos, a lepke személyazonosságát nem jegyezték fel, bár a technológiai világ fejlődéséhez jelentősen hozzájárult, ám egy bizonyos halhatatlanságot mégis csak elért a sárguló Scotch márkájú szalagnak köszönhetően” – mondta Graham Cluley kutató.

Megdöbbentő példák a legnagyobb szoftverhibákra

Magától értetődik, hogy a szoftver tesztelése sokat jelent a modern világban. Szeretnénk ezt élő példákkal alátámasztani. A tények magukért beszélnek.

1996-ban az Európai Űrügynökség által a francia Guiana Kourou-ból fellőtt pilóta nélküli Ariane 5 rakéta mindössze negyven másodperccel az indítás után felrobbant. Az Ariane 5 fejlesztése közel 8 milliárd dollárba került és 500 millió dolláros műholdat hordozott, amikor felrobbant. A probléma egy egyszerű hiba volt a rakétakontroll rendszerekben. Meg akarták spórolni a szoftvertesztelést, de ez túl drágának bizonyult.

Egy másik hiba kiakasztotta egy ponton a Youtube videó megtekintési számlálóját. Amikor először indították el a YouTube-ot, senki sem gondolta, hogy egy videót valaha kétmilliárdszor, vagy pontosabban, több mint 2.147.483.647 alkalommal néznek meg – a maximális számérték, amelyet egy 32 bites előjeles egész szám (signed integer) tárolhat. A Psy nevű dél-koreai popsztár “Gangnam Style” videójának népszerűsége megdöntötte a rekordot. A Google rögzítette ezt a YouTube-hibát, majd a nézetszámot 64 bites signed integer-re változtatta. Nem volt komoly hiba. Senkit nem öltek meg. Semmi sem robbant fel. Ez inkább kellemetlenség volt. Ennyit említett róla a YouTube egy Google + postban.

A PayPal hibája véletlen quadrilliomossá tett egy embert. 2013-ban Chris Reynolds kapott egy e-mailt a PayPal-fiókjával kapcsolatban, és megdöbbent, hogy ott egy 17 jegyű számlaegyenleget lát. Reynolds úgy döntött, majd később leellenőrizni fiókját, de közben észrevette, hogy a PayPal már korrigálta is a hibát. A CNN beszámolt arról, hogy a PayPal egy nyilatkozatban kijelentette: “Ez nyilvánvalóan hiba, és nagyra értékeljük, hogy Mr. Reynolds megértette ezt.” “Nagyon lelkiismeretes fickó vagyok” – mondta Chris Reynolds. – Először kifizetném az államadósságot, azután megvenném a Phillies-t, ha elfogadható árat kérnének érte.”

Ez csak néhány eset a világ leghíresebb számítógépes hibáiból, amelyek költségekkel járhatnak, amelyek esetenként akár több millió dollárra is rúghatnak, (ha nem cselekednek azonnal). Kellemetlen, nem igaz?

A minőségértékelés szerepe az agilis módszertanban

Sok szoftverfejlesztő csoportban hagyományosan a minőségbiztosítás és a fejlesztés önállóan működik. Legalábbis eddig így volt. A tesztelők ritkán dolgoznak össze, és legtöbbször nem ülnek a szoba ugyanazon részében sem. Ez nem a legjobb megoldás. Annak érdekében, hogy valóban agilis és minőségi termék szülessen, valamint időben elkészüljön, a tesztelőknek és a fejlesztőknek szinkronban kell lenniük, párhuzamosan kell dolgozniuk.

Tehát a tesztelőknek együtt kell működniük a fejlesztő csapatokkal, hogy teljes mértékben megértsék a szoftver követelményeit és működését. Ez lehetővé tenné számukra, hogy mindig tisztában legyenek a kóddal, a követelményekkel és a termékválasztékkal kapcsolatos változásokkal. Emellett a tesztelőktől érkező visszajelzések felgyorsítják az egész folyamatot, és csökkentik egy alacsony színvonalú termék kiszállításának kockázatát. A tesztelők nem csak hibákat keresnek, hanem hiányzó funkciókat is. Nagyon erős a ráérzésük mindenre. A fő különbség az, hogy agilis fejlesztésben a tesztelési és a fejlesztési fázis egyidejűleg kezdődik. Minden funkciót ahogy elkészül rögtön tesztelnek is, nem várják meg vele a sprint végét, és természetesen nem a projekt végét. Ugyanezen sprint alatt a fejlesztők módosíthatják a funkciókat, és ezeket a változtatásokat közvetlenül egy tesztelőcsapatnak küldhetik át további tesztelés céljából. A vízesés projektekben azonban a tesztelés a fejlesztési szakasz befejezése után kezdődik.

Az agilis tesztelés szorosan kapcsolódik a feltáró teszteléshez, amely az egyéni tesztelő személyes szabadságára és felelősségére helyezi a hangsúlyt.

“A hagyományos vizsgálati módszerekkel ellentétben, ahol a folyamat szakaszos lehet, a felderítő tesztelés inkább egy valós idejű folyamat,” – mondta Michael Kelly a TechTarge-től.

A teszteseteket nem előzetesen hozzák létre, mint a tesztszkripteket, amiket először megterveznek, és később hajtanak végre. Éppen ellenkezőleg, a feltáró vizsgálatok során a tesztelők minimális tervezésben és maximális végrehajtásban vesznek részt. A felderítő tesztelést ad-hoc tesztnek is nevezik. Nem azonos a hanyag, gondatlan munkavégzéssel. Ez egy olyan tesztelési megközelítés, amely lehetővé teszi, hogy a tesztelő merev korlátok nélkül alkalmazhassa képességeit, tesztelői jártasságát. Így a feltáró tesztelés egyidejű tanulás, tervezés és végrehajtás. Ha érdekelt a témában, nézzen meg egy rövid videót James Bach-tól, egy termékeny szoftvertesztelőtől, szerzőtől, oktatótól és tanácsadótól, aki az agilis világban zajló feltáró tesztelésben jártas.

Agilis dokumentáció tesztelés

Tény, hogy a dokumentációkészítés sok tesztelő rémálma. Miért is? Íme egy válasz James Bach-tól:

“Sokak, akiket tanítok, úgy tűnik, nyomás alatt állnak, hogy több dokumentumot hozzanak létre a tesztelési folyamatuk leírásához. Viszont a dokumentálás nem tesztelés. A dokumentálás a tesztelés egyik főnöki őrülete. “

Számos tesztdokumentáció készül hagyományos megközelítésben, amelyet a projekt ideje alatt karban kell tartani. A projekt elején a tesztelőknek kevesebb ideje van a tesztelésre. A végére viszont száz rögzíteni való dolog akad, miközben minden figyelem a tesztelésre irányul.

Egy másik vélemény a kérdéssel kapcsolatban Mike Hodge tollából:

“Mivel egyedül ők tudják, mit tudnak és mit csinálnak, sok kis-és középvállalkozás teszteseteiket formálisan dokumentált, totális időpocsékolásnak tartja.” 

Tehát néhány tesztelő úgy véli, hogy a dokumentáció kidobott idő. Ők azt hiszik, attól tesztelők, hogy elég hangosan kiabálnak. A tesztmérnök feladata a dolgok dokumentálása. Más inkább depressziósnak érzi magát, amikor dokumentálásra kerül sor, mert lassú és terhes feladat. Mit lehet tenni ez ügyben?

Az agilis módszertan megoldást kínál a fentiekre, és a tesztdokumentáció megírását könnyű sétagaloppá változtatja. A program rövid sprintekben dolgozik, és figyel rá, hogy kis lépésekben haladjon a fejlesztés az egyes sprint ciklusokban, figyelembe véve az MVP (Minimum Viable Product=Minimálisan Működőképes Termék) megközelítést. A folyamatos tesztelésre összpontosít. Sprintenként csak néhány új követelmény van. Így összességében kevesebb dokumentáció keletkezik.

A szabványosított dokumentumok egységesítéséhez az IEEE (The Institute of Electrical and Electronics Engineers) kifejlesztett 829 szabványt a szoftver- és rendszerteszt-dokumentációhoz.

Ezzel szemben a hagyományos vízeséses típusú projektekben a szoftvertesztelés három fázisú, ezek a következő nyolc dokumentumtípust használják:

• Teszt előkészítés
  • Tesztterv: tesztelési folyamatok megtervezése
  • Teszttervezési specifikáció: tesztelési feladatok eldöntése
  • Teszteset specifikáció: futtatási tesztek létrehozása
  • Tesztelési eljárás: futtatási tesztek működése
  • Tesztelem átviteli jelentés: teszteléshez kiadott elemek
• A tesztfuttatás
  • Tesztnapló: tesztek részleteinek időrendbeli rögzítése
  • Tesztincidens riport: vizsgálandó események rögzítése
• A vizsgálat befejezése
  • Tesztösszesítő jelentés: teszteredmények összefoglalása és értékelése

A hagyományos tesztelés során rengeteg idő megy veszendőbe a részletes vizsgálatok dokumentálásával, amelyek sem nem szükségesek, sem nem hasznosak. Az agilis módszertan lean megközelítést javasol a dokumentáció tesztelésére. Ez azt jelenti, hogy a nehézkes dokumentáció könnyíthető intelligens technikák, például gondolat-térképezés, egysoros jegyzetek, ellenőrző listák és mátrixok segítségével.

Agilis módszertanban is léteznek tesztelési tervek, de ezek nem egyetlen tesztelő által elszigetelten írt hosszú dokumentumok, hanem interaktív beszélgetések, melyeket egy tábla vagy egy gondolat-térképen rögzítenek, hogy a csapat minden tagja értse, mit tesztelnek és mely módszerekkel.

A teszteseteket szintén használhatjuk, de azok könnyűek, és csak annyi információt tartalmaznak, amennyivel egy tapasztalt szakember elvégezheti a tesztet. Az esetek részletes leírást, lépéseket és elvárt eredményt nem tartalmaznak. Ez a módszer nagyon felgyorsítja a megírásukat.

Másrészt, a nehéz tesztesetek írása helyett dönthetünk egy, az összes szükséges kritikus ellenőrzést felsoroló lista mellett. Az ellenőrző listák és az egysoros jegyzetek alkalmazása az ötven lépésből álló tesztforgatókönyvekkel szemben sokkal időtakarékosabb. Az egysoros jegyzet egyetlen szövegsorban írja le a végrehajtandó lépést.

A projekt előrehaladásának méréséhez a tesztmátrixokat gyakran alkalmazzuk a szoftvertesztelésben. A tesztmátrix egy olyan táblázat, amelyben könnyen átlátjuk a tesztlépéseket, és ugyanitt rögzítjük a vizsgálati eredményeket. Más szóval, a projekt során végzett munkánk mérésére szolgál a folyamat javítása és annak ellenőrzése érdekében, és megmutatja, hogy hol vagyunk elmaradva. Megkülönböztetjük a tesztelési folyamatokat és teszttermék-mátrixokat. A tesztelési mátrix tájékoztatást nyújt a tesztelés előkészítésére, végrehajtására, valamint a tesztelés előrehaladására vonatkozóan. A teszttermék-mátrix a termék tesztállapotáról tájékoztat, így értékelhetjük a termék állapotát és minőségi szintjét.

Összefoglalás

A technika ilyen gyors fejlődésénél fontos az ujjunkat az ipar pulzusán tartani, hogy bármely időpontban megértsük, mi a lényeges. Remélem sikerült megvilágítani a témát, és segíteni választ találni a cikk elején feltett kérdésre. Használt már valaha valamilyen lean tesztdokumentációt? Ossza meg velünk az ezzel kapcsolatos tapasztalatait!

Forrás: https://www.utest.com/articles/how-to-keep-your-testing-documentation-lean 
Forrás:https://www.utest.com/articles/how-to-keepyour-testing-documentation-lean
Szerző: Oleksandr Reminnyi