Követelményspecifikáció a tesztelőkért
Sokan csak kritizálni tudják a specifikációkat. A hiányosságaira vagy a bennük leírt ellentmondásokra hivatkoznak a tesztelők, ha nem lehet belőlük dolgozni. De ha már a specifikációk elkészítésénél be vagyunk vonva a projektbe, miért nem segítjük a többieket egy jobb dokumentum elkészítésében? Egyáltalán tudjuk hogyan kellene ezt tennünk?
A követelmények a tesztelés alapjául szolgálnak. Ezeket a követelményeket elemzik, a tesztelhetőség szempontjából és a tesztelők rendszerint a követelmények összeállításánál is már részt vesznek a folyamatban.
Sajnos a legtöbb tesztelő csak minimális tudással rendelkezik ebben a témában. Milyen minőségű és milyen részletességű és mennyire realisztikus követelményeket kell megfogalmazni a teszteléshez? Mit is jelent a tesztelhetőség? Hogyan tud a tesztelő a követelmények összeállításában igazán segíteni? Egy tesztelőnek tudnia kell ezekre a kérdésekre a választ és tudnia kell részt venni a követelményspecifikáció összeállításában.
Mindig a dokumentációra panaszkodunk: „Nem tudom tesztelni, mert nem világos, nem egyértelmű”, de arra nem tudunk válaszolni, hogy szerintünk milyen a jól használható, illetve tesztelhető követelményspecifikáció.
Mindemellett:
- A kockázatelemzések és a teszt forgatókönyvek a követelményspecifikáción alapulnak.
- A követelményspecifikáció átnézésében részt veszünk, így meg tudjuk mondani, hogy milyen minőségű munka az elfogadható.
- A tesztterv használható, mint követelményspecifikáció.
- Sokszor (általában agilis fejlesztésnél) mi definiáljuk és specifikáljuk a követelményeket.
- Nagy figyelmet fordítsunk rá és legyünk aktív szereplők a követelményspecifikáció összeállításában.
Agile
Az IT világ változik és a legtöbb informatikai vállalkozás legalább a belső fejlesztéseikhez használ valamiféle agile fejlesztési módszertant. Az agile-ban a tesztelők még jobban be vannak vonva a követelmények definiálásába mint eddig, valamint részt vesznek a dokumentációk és a megfelelési kritériumok összeállításában. A felhasználói történetek az egyik legfontosabb rész az agile csapat számára. Az agile-ban a követelmények a felhasználói történetek alapján állnak össze, ezeket kell megvalósítani, majd tesztelni. A felhasználói történetek magukban foglalják a hozzájuk kapcsolódó funkciók definícióját, egyéb nem funkcionális kritériumokat és az elfogadási kritériumokat. A tesztelők részt kell, hogy vegyenek a felhasználói történetek definiálásában és ezen történetek bekövetkezésekor az elfogadási kritériumok összeállításában is.
Folyamatosan képezzük magunkat! Vannak trendek, amelyek azt mondják, hogy a tesztelőknek képben kell lenniük az aktuális feladattal és reagálniuk kell a feléjük érkező kérésekre. A tudásunk és az eszközkészleteink fejlesztésére nagyon nagy szükség lesz a közeli jövőben. Most már nem lesz elég csupán érteni, hogy mit kell tesztelni, illetve rendelkezni egy-két ISTQB vizsgával.
Nem dolgozhatunk mindig a biztonságos, külvilágtól elzárt, független kis tesztcsapatunkban. Az üzlettel és a fejlesztőkkel fogunk ezen túl közösen dolgozni, hogy egy csapatként minőségi termékeket állítsunk elő. Ma már elvárás a tesztelőtől, hogy legyen az adott szakterületen jártas, tudjon követelményeket összeállítani, szkripteket írni és legyen a kommunikációs képessége is magas színvonalú. (1. ábra) Megérthetjük, hogy tesztelőként az egyik elvárás felénk a követelmények összeállításában szerzett tapasztalat. Ennek a tudásnak a megszerzésére rengeteg lehetőség van. Akad, aki megtanulja egy IREB vizsgára felkészítő tanfolyamon, vagy léteznek olyan tanfolyamok, amelyekben gyakornokként lehet ezeket a képességeket elsajátítani. Választhatjuk bármelyiket, amelyik segít a munka elvégzésében.
5 sikerfaktor
Sokéves tapasztalattal a követelményspecifikálásban a hátam mögött, 5 kritikus sikerfaktorra mutatok rá, amelyekbe a tesztelőknek érdemes beleásni magukat:
Követelményjellemzők: A követelményeket a felhasználói esetek, a követelménytípusok és a racionalitás alapján állítjuk össze, tehát több mint egyszerű „azért mert csak” kijelentések listája. A követelményjellemzők a követelmények sajátjai, összekapcsolják a fontos információkat és összefüggéseket a követelményekről. Általában egy úgynevezett „felhasználói történet kártyán” vannak összegyűjtve, amelyek a projektben résztvevők számára hozzáférhetőek. (2. ábra). Ne essünk át a ló túl oldalára, praktikusan csak azokat a jellemzőket definiáljuk, amelyeknek van hozzáadott értékük a projektben.
Elfogadási kritériumok: Az elfogadási kritériumok a követelmények definícióját teszik teljes egésszé. Meg kell tudnunk mondani egy alkalmazásról, hogy megfelel-e az elvárásoknak, mérhetővé kell tennünk az elfogadási kritériumokkal. Mindig sokkal egyszerűbb egy konkrét megfelelési kritériumot definiálni, mint egy mindenki számára teljesen érthető követelményspecifikációt. Lényegében az elfogadási kritériumok a követelmények pontosítására szolgálnak.
Szabályok: A vita arról, hogy milyen a jó követelményspecifikáció, egy véget nem érő vita. Természetesen az adott tartalomtól függ és fontos a döntések meghozatalához. A konkrét és használható szabályok az „elég jó” követelmények definiálását segítik elő. Kommunikáljunk egymással és definiáljunk szabályokat az azonosításra, jegyzetekre, kommentárokra, változásokra, konzisztenciára, nyelvezetre, mennyiségre és minőségre, valamint az egyértelműségre.
Sablonok használata: Ahelyett, hogy újból és újból feltaláljuk a kereket, használjunk sablonokat, amikor funkcionális és nem funkcionális követelményeket definiálunk. Következetességet ad és hozzájárul a minél egyértelműbb követelményspecifikáció összeállításához. Sokkal hatékonyabb a sablonokkal a munka, mostantól használjuk őket!Íme néhány példa:
Az <érintett> tudnom kell <cselekvés> <entitás>
A rakétakilövőnek tudnia kell rakétát indítani.
Az <érintett> képesnek kell lennie <képesség>
A gazdasági osztálynak képesnek kell lennie számlát kiállítani.
A <termék> tudnia kell <funkció> <objektum> minden <egység>
A kávégépnek 10 másodpercenként el kell tudnia készíteni egy kávét.
Követelmények felülvizsgálata: A követelmények felülvizsgálata a legjobb és leghatékonyabb módszer a minőségi eredményhez vezető úton és a hibák feltárásában. Természetesen ez csak akkor igaz, ha jól alkalmazzuk. Itt még jobban igaz a praktikusság és az elmélet közötti jó mérlegelés. A saját magunk által végzett felülvizsgálat, vagy egy harmadik fél által végzett felülvizsgálat között a különbség, hogy más résztvevők más folyamatok és más szempontok alapján hajtják végre. Kezdjük a saját céljainkkal és ehhez definiáljunk felülvizsgálati folyamatokat. Van egy konzultációm az egyetemen „Követelményspecifikálás tesztelőknek” címmel már jó néhány éve, lehet, hogy találkozunk ott hamarosan…
Szerző: Eric Van Veenendaal
A szerző
-
Erik Van Veenendaal
(http://www.erikvanveenendaal.nl) nemzetközi vezető tanácsadó és tréner, valamint világszinten elismert a szoftvertesztelés és minőségbiztosításaterületén.Alapítója az Improve Quality Services BV-nek (www.impoveqs.nl) Háromszor nyerte meg az EUROStar legjobb konzultáció díját. 2007-ben az European Testing Excellence Award díjat is megkapta a tesztelésben végzett professzionális munkájáért. Tesztelőként és tanácsadóként dolgozott számtalan területen több,mint 20 éven keresztül. Számos értekezést és könyvet írt, többek között a praktikus kockázatalapú tesztelésről: A PRISMA megközelítés, ISTQB alapok a szoftvertesztelésben. Ő az egyik
kulcsfejlesztője a TMap tesztelési metodológiának, valamint tagja Követelményspecifikációs Bizottságnak (IREB). Erik óraadóként tanít az eindhoveni egyetemen, elnöke volt a NemzetköziSzoftvertesztelés Minősítő
Bizottságnak (2005-2009), jelenleg pedig aTMMi Foundation tagja.
Kövesd Eriket twitteren:
@ErikVeenendaal
Cikkek
- 2018.05.22MódszertanKövetelményspecifikáció a tesztelőkért
- 2013.11.09MódszertanTMMi szakértővé válni