A tesztterv halott!

Ha a hagyományos teszttervet nem is úgy használjuk, ahogyan kellene, nem szabad elfeledkezni arról, hogy tervezni igenis muszáj! Sokan szabják át a régi módszereket, vagy találnak ki újakat úgy, mint ahogyan a Google tesztszakértője is tette. Érdemes megismerni az ő szemszögéből mindezt.

Jelentette ki James Whitakker, a Google legendás tesztelési szakértője, aki tavaly októberben átértelmezte a tesztterv fogalmát. Egy összejövetelen Whittaker megkérdezte a jelenlévő tesztelőktől: “Hányan írnak közületek tesztterveket?” Körülbelül 80 kéz lendült a magasba. “És hányan foglalkoztok vele egy hét múlva is?” Ekkor már csak 3 kéz volt a magasban. Többek között ezért is kezdtek el a Google-nél egy merőben új, egyszerűbb folyamatot kidolgozni, amivel kiválthatók a hagyományos teszttervek 

No de mi a baj a teszttervvel?

A legtöbb projektnél megfigyelhetőek a következő problémák:

• A tesztterv egy idő után elhanyagolttá válik, nem frissíti senki
• Sokszor ad-hoc módon születik, a projekt elején, amikor még kevés információ áll rendelkezésünkre
• Nehezen átlátható, strukturálatlan
• Kevés “cselekvésre késztető” információ van benne (itt az angol kifejezés beszédesebb, Whittaker “actionable data”-ként említi)

Ezeket a problémákat szerették volna kiküszöbölni a Google munkatársai, akik Whittakerrel együtt egy új tesztelési folyamaton kezdtek el dolgozni. Az új megközelítés végül az ACC (Attributes, Components, Capabilities) nevet kapta. A cél az volt, hogy legyen egy egyszerűen követhető tesztelési folyamat, ami megszünteti a feljebb említett hibákat és egyszerűen, gyorsan megvalósítható. Nem kell órákat dokumentálni, de ugyanakkor folyamatosan fejlődjön, keletkezzen benne újabb és újabb érték. Valamint szintén igényként fogalmazták meg, hogy a kockázat alapú tesztelést segítse. Legyen egy grafikus felület, amin jól látszik, melyek a szoftver, legkockázatosabb részei.

Mit mond erre a Google?

A rövidítés, mint már korábban írtam, az Attributes, Components, Capabilities szavakból áll. A Google szerint az említett három fogalmat kell jól átgondolnunk és ezek alá rendeljük a tesztjeinket. Nézzük A rövidítés, mint már korábban írtam, az Attributes, Components, Capabilities szavakból áll. A Google szerint az említett három fogalmat kell jól átgondolnunk és ezek alá rendeljük a tesztjeinket. Nézzük, hogy hogyan!

Attributes Nevezzünk meg a rendszerre vonatkozó tulajdonságokat! Ezek melléknevek, amik jól jellemzik a rendszert. Nem mások, mint elvárt tulajdonságok! Pl., ha egy web shopra gondolunk, akkor lehet attribútumunk a “Gyors”, “Felhasználóbarát” vagy a “Biztonságos” szavak egyike. Próbáljuk is ki! Ha ellátogattok a Google Test Analytics oldalára (https://test-analytics.appspot.com), találtok egy demó-felületet, amit bárki kipróbálhat, létrehozhat egy új projektet és természetesen attribútumokat is!

Ott tartottunk, hogy a képzeletbeli web shopunk “Gyors”, “Felhasználó barát” és “Biztonságos”. Ezek tulajdonképpen a szoftverünk karakterisztikái, tulajdonságai, amilyennek szeretnénk látni termékünket. Nyugodtan soroljunk ide nagy szavakat! Amit szívesen lát egy termékmenedzser vagy egy értékesítő is!
 Components
A komponensek a rendszer részei. Eddig semmi újdonság. De állapítsuk meg őket szabadon! Ne csak az architektúra-térképről másoljunk ide részeket! Lehet bármilyen logikai egység, ami csak a rendszerünket alkotja. Például az előbbi koncepciónál maradva, lehet “Adatbázis”, “Applikációs szerver”, “Load Balancer”, de akár “Bevásárló kosár”, “Webes felület” vagy “Nyomtatás” is. Egyszóval főnevek, amelyek a rendszer logikai részei.
 Capabilities
Ahogy középiskolás fizikatanárom sokszor mondta, itt álljunk meg egy polgári szóra! A rendszer képességei jönnek. Az ACC modell szerint, ez az, amit egy komponens tud, azért, hogy kielégítse a rendszer egy attribútumát! Egy ige jellemzi, pl. “A felhasználó bejelentkezik HTTPS protokollon keresztül”. Azaz a “Webes felület” “Biztonságos” igényt akarja kielégíteni! Amikor képességet definiálunk mindig gondolkozzunk el rajta, melyek a tulajdonságok és komponensek metszetei, és belőlük fogalmazzunk meg képességeket! Van egy nagyon hasznos hozadéka: minden komponensre értelmezhetünk egy-egy tulajdonságot. Az előbbi példával élve: definiálhatunk képességet az “Adatbázis” “Biztonságos” párra. Lehet, hogy egyébként eszünkbe sem jutott volna, hiszen eddig csak a “Webes felület” “Biztonságosságát” vizsgáltuk. Egyébként ezt úgy tudjuk megtenni, hogy a Test Analyticsben, rákattintunk a Capabilities részre., és így kapunk egy táblázatot (lásd a Capabilitiesről szóló képen), amely a komponensek valamint a tulajdonságok metszetét jelképezi. Ha egy cellára rákattintunk, akkor létrehozhatunk képességet az adott komponens-tulajdonság párhoz. És megszületik a szoftver egy elvárt képessége!

Risk Overview

Említettem, hogy az ACC remekül támogatja a kockázatalapú tesztelést. Mindezt úgy teszi, hogy grafikusan képes megjeleníteni, melyek a rizikós részek (tulajdonság-komponens párok) a termékünkben. Ha megnézzük a Risk Overview-hoz tartozó ábrát, láthatjuk, hogy különböző színekkel jelzi a tool, mennyire kockázatos egy terület. Figyelembe veszi, hogy mennyire van tesztekkel lefedve, mennyi hiba tartozik egy-egy területhez, sőt eredendően is beállíthatunk egy kockázati mennyiséget. A lényeg: jól áttekinthető grafikus felületet kapunk.

Hogyan kapcsoljuk mindezt össze a tesztjeinkkel, hibáinkkal?

A Google Test Analytics tool célja, hogy segítse az elképzelés bevezetését, támogassa a külső adatforrásokat. Tehát beimportálhatunk saját teszteket egy külső menedzser eszközből, sőt Bug tracker-ből is, amire a Data sources felületet használhatjuk. Lehetőségünk van a betöltött adatok szűrésére, hogy az adott terminológiába helyezhessük tesztjeinket, hibáinkat. Ha a folyamaton végig verekedtük magunkat, az Imported data résznél sorakoznak az adataink. Az importált tesztek ábráján jól látható, hogy az egyes teszteket hozzá tudjuk rendelni bármely entitáshoz: Attribútumhoz, Komponenshez vagy Képességhez. Sőt, a beimportált hibák is megjelennek a Bugs felületen. Ezenkívül, ha egy terület (Attribútum, Komponens pár) sok hibát tartalmaz, a Risk Overview felületen “pirosabb” a terület, jelezve, még van mit javítani azon a részen.
 Ha most végiggondoljuk mindazt, amit eddig olvastunk, rájövünk, hogy nem egy mindent megváltó módszerről van szó, ugyanakkor kétségtelen, hogy a fenti problémákra valóban megoldást nyújt. Ami a legfontosabb: folyamatosan hozzáadott értékeket termel, és tényleg hasznos információkkal segíti a tesztelői munkát.

Zárszó

Azt, hogy mennyire lesz sikeres az ACC, még nehéz megmondani. Egy biztos, a kaliforniai cég olyat tud, amit kevés multicég, egyszerűsíteni a folyamatokon, a hatékonyság érdekében.

Források

https://code.google.com/p/test-analytics/wiki/AccExplained

http://googletesting.blogspot.hu/2011/10/google-test-analytics-now-in-open.html

Szerző: Tóth Árpád