Dobjuk ki a felhasználói sztorikat, miután teljesítettük õket!

Ez egy szemelvény a hamarosan megjelenõ könyvembõl: 50 gyors tipp a felhasználói sztorik minõségének javítására. Ha a gyakorlatban is akarod látni, lesz egy workshop-om errõl: Product Owner Survival Camp

A legtöbb csapat a meglévõ felhasználói sztorikkal és dokumentációkkal szenved. A sztorikhoz az általuk használt elektronikus feladatkövetõ rendszerben hozzákapcsolják a teszteseteket, diagramokkat, vagy a specifikációkat. Ezek a task-ok a regressziós tesztekhez és a hatásvizsgálatokhoz kellenek majd. A probléma az, hogy ezt a módszert lehetetlen fenntartani egy komplex projektek esetén.

Egy felhasználói sztori a funkcionális szempontok miatt rengetegszer megváltozik, és ugyanaz a funkcionalitás számos sztorit fog érinteni hosszú idõn keresztül. Az egyik sztoriba be fogunk építeni egy új szoftvertulajdonságot, egy másikat majd változtatni fogunk, vagy egyszerûen nem fogunk vele többet dolgozni. Azért, hogy rálássunk a helyzetre, valakinek fel kell fedeznie az összes releváns sztorit és fordított kronológiai sorrendbe kell tenni, hogy felderítsük a potenciális hibalehetõségeket és változásokat. Csak ezután láthatjuk a teljes képet.

A dizájn, a specifikáció és a teszt terv leírja, hogyan mûködik jelenleg a rendszer  nem azt mutatja, hogyan változott az idõk során. A régi sztorik használata az új verziók esetén olyan, mintha egy banki számlatörténetet néznénk, hogy megtudjuk mennyi az egyenlegünk, ahelyett, hogy csak az egyenleget kérdeznénk le. Ez a hibázás melegágya, idõt és energiát igénylõ út az információk összegyûjtésére.

A legtöbbször azért esik a csapat ebbe a hibába, mert ez nem látható elõre. A tesztesetek, specifikációk, felhasználói sztorik a tesztelési munkamenet sajátosságai, de nem sokat mondanak a múltbeli dolgokról. Így ez csak hónapok múlva kezd majd el igazán fájni.

Nagyon jó, ha a sztorikhoz világos ellenõrzõ kritériumok vannak. Ez nem azt jelenti, hogy minden tesztesethez és sztorihoz specifikációk hegye kell, hogy létrejöjjön az örökkévalóságnak.

Válasszuk szét folyamatban lévõkre és elkészültekre, és ebben a két csoportban eltérõen kezeljük a specifikációkat, a teszteket és dizájn dokumentumokat. Dobjuk ki a sztorikat ha készen vagyunk velük, fedjük fel a kártyákat, zárjuk le a hibajegyeket és töröljük a kapcsolódó wiki oldalakat. Ha így dolgozunk, nem fogunk a változások miatt belefulladni a dokumentumok és a változások kezelésébe. Az ide vonatkozó teszteseteket és terveket pedig kapcsoljuk a jelenlegi projekthez funkcionális szempontok szerint.

Mi az elõnye?

Egy adott funkcionális területrõl készült specifikációk és tesztek a jelen szituációt írják le anélkül, hogy belemennénk az egész egység történetébe és változásainak folyamatába. Ez a jövõben a tesztelésnél és az analíziseknél rengeteg idõt fog megtakarítani nekünk. Valamint kevesebb hibázási lehetõséget hordoz magában az információk összegyûjtésénél.

Ha a csapat valamilyen automatikus tesztelést is végez, akkor ezek a tesztek a jelenlegi helyzetre lesznek kifejlesztve és nem a múltbeli változásokra. A specifikációk és tesztek ugyanilyen struktúrában való kezelése megóv minket attól, hogy a csapatok különbözõ alapvetések és források alapján dolgozzanak ugyanazon a feladaton.

Hogyan mûködhet ez?

Vannak csapatok, akik felosztják a teszteket és specifikációkat a folyamatban lévõ és már létezõ funkciókra. Ezáltal lehetõvé teszik az információk különbözõ kezelését. Én gyakran csoportosítom a folyamatban lévõ teszteket elõször a releváns sztorikhoz, utána pedig a funkcionalitáshoz, míg a létezõ funkcionalitásnál elõször a tulajdonságokhoz, azt követõen a funkcionalitáshoz.

Tegyük fel van egy számtalanszor továbbfejlesztett felhasználói sztorink a regisztrációról ami két dolgot tartalmaz, elõször egy Google fiókba történõ belépést, másodszor pedig egy gyors Paypal fizetést. Ennek két különbözõ tesztesetnek kellene lennie és hierarchiába rendezve kellene tárolódnia. Így lehetõségünk nyílna felosztani a munkát a különbözõ munkatársak között  amennyiben a sztori lezárására létezik egy mindenki által elfogadott döntési mód.

A szállítás után én a Google belépést a felhasználók kezelése funkciók közé tenném, míg a Paypal-os teszt részt áttenném a fizetési terület tesztjei közé, és összedolgoznám a korábbi fizetést ellenõrzõ tesztekkel. Ezáltal lehetõségem lenne arra, hogy gyorsan felderítsem, mennyi fizetési mechanizmus mûködik, függetlenül attól, hogy hány sztori volt az adott folyamatban. Egyes csapatok a teszt specifikációkat a funkcionalitás szerint csoportosítják és tag-eket használnak az egyes felhasználói sztorik azonosítására. A tag-ek alapján fogják majd az egyes teszteket a szorikhoz kötni, illetve tag-ek alapján keresnek. Az automata teszteszköz is tag-ek alapján választja ki a futtatandó teszteket. Ez a megoldás kevesebb újra strukturálást igényel, miután kész a sztori, viszont sokkal jobb eszközellátottságot is feltételez.

A tesztelés szempontjából, az elkészült funkció halmaz határozza meg a regressziós teszteket, a folyamatban lévõ halmaz pedig az elfogadási teszteket. A dokumentáltság szempontjából a meglévõ funkciók úgy vannak dokumentálva „ahogy vannak“, míg a fejlesztés alatt állók „ahogy lenniük kellene“.

Ha így kezeljük a teszteket és a specifikációkat akkor a csapatok különbözõ tesztelési folyamatok szerint dolgozhatnak. Például ha egy funkcionális teszt elbukik, akkor riadót fújunk és leállítjuk a kiadást. Másrészrõl, ha egy teszt megbukik a jelenlegi iterációban – ahogy az várható -, tovább folytathatjuk a funkció fejlesztését. Elsõre csak az érdekel, hogy a sztori alatt lévõ tesztek fussanak le.

Néhány teszteszköz nagyon jó az automatizálásra, de nem igazán használható az információk publikálására, riportolásra. Ha ilyen eszközöket használunk, akkor hasznos lehet ha elõsegítjük a vizuális navigációt például egy funkció térképpel. A funkció térkép a funkcionalitás hierarchikus „mind-map“-je, melynek elemei a specifikációkra mutató hyperrlinkekkel vannak ellátva. Ez segít a sztori után eldönteni, hogy a struktúrán belül hová tegyük a teszteket és specifikációkat. Így a projekt teljes ideje alatt konzisztens szerkezettel tudunk dolgozni.

Néhány csapatnak a korábbi, historikus változásokat is karban kell tartaniuk az auditokhoz. Ebben az esetben sokkal elõrébb mutató az, ha a verziókezelõ eszközökben követjük nyomon a munkát, nem pediglen a feladatkezelõben. A verziókezelõ rendszer automatikusan nyilvántartja, hogy ki, mit és mikor változtatott. Ez abban is óriási segítséget nyújt, ha különbözõ ügyfelek részére a rendszer különbözõ változatait kell szállítanunk.

Forrás: http://gojko.net/2014/03/25/throw-user-stories-away-after-they-are-delivered/#more-3289
Szerző: Gojko Adzic