02. gyakorlat
Az agilis fejlesztésről¶
Az agilis fejlesztésről általánosan¶
Az alapszintű Tesztelői Tanúsítvány (Certified Tester Foundation Level (CTFL)) a 4.0 verziótól kezdve az agilitás, az agilis fejlesztésekhez kapcsolódó tesztelési feladatokat is magába foglalja.
Az agilis fejlesztési módszertanok olyan gyakorlatok, munkaszervezési módszerek, amelyek az agilis értékek mentén iterációkban zajlanak. Az egyes iterációk során mind a fejlesztés, mind a tesztelés megvalósul, ezek a tevékenységek párhuzamosan zajlanak. Az agilis módszertanok alkalmazásával a fejlesztők folyamatosan tartják a kapcsolatot a megrendelővel, ezért gyorsabban érkezik visszacsatolás a fejlesztett funkcionalitással kapcsolatban, valamint az ügyfelek által bejelentett változásokra is gyorsabban reagál a fejlesztői csapat. Az elterjedtebb agilis módszertanok közé tartozik a Scrum, az Extreme Programming (XP), a Crystal módszertan, a DSDM (Dynamic Software Development Method), az FDD (Feature Driven Development), a Kanban, és a Lean szoftverfejlesztés.
Miért van szükség az agilis módszertanokra?
Korábban az egész életünk működése lassabb, kiszámíthatóbb volt, és ez stabilabb elvárásokat, követelményeket eredményezett egy szoftverrel szemben. Volt idő átgondolni, tervezni, és a terveket követve fejleszteni. A korai fejlesztési módszertanok (például a vízesés modell) a klasszikus mérnöki szemlélet mentén alakultak ki, amelyben a hosszútávú tervezés, a tartós és megbízható termék létrehozása állt a középpontban, változásokra viszonylag ritkán került sor. Manapság a követelmények gyorsan változnak, ugyanakkor a felhasználók is hamarabb szeretnének működő szoftverhez jutni tekintettel arra, hogy a kiélezett verseny erre kényszeríti őket. Ma már egy fejlesztésre sokszor fél év, vagy annál kevesebb idő áll rendelkezésre. Ha elfogadható minőségű terméket szeretnénk, akkor ahhoz a szükséges erőforrásokat, időt, valamint a megfelelően részletezett specifikációkat a fejlesztők rendelkezésére kell bocsátani. Ha ezek a feltételek nincsenek meg, akkor annak következményeként komoly technikai adósságokkal kell szembesülnünk. Ezeknek a problémáknak együttes komplex kezelésére a hagyományos fejlesztési módszertanok nem adnak kielégítő választ, ezért olyan fejlesztési módszerek kidolgozására volt szükség, amelyek képesek az említett kihívásokat hatékonyan kezelni.
Az agilis fejlesztés tehát kiszorítja a korábbi módszereket?
Nem egészen. Egyrészt vannak olyan fejlesztési projektek, ahol a követelmények stabilak, lassan vagy egyáltalán nem változnak. Ilyen projektek jellemzően műszaki fejlesztések, biztonságkritikus alkalmazások, ahol az átgondolt és alaposan megtervezett lépéseknek továbbra is kiemelt szerepük van. Ezekhez a projektekhez továbbra is a vízesés modellt, vagy valamely más mérnöki szemléleten alapuló fejlesztési modellt alkalmazzák keretrendszerként. Az agilis fejlesztések jellemzően az üzleti és ügyviteli szoftverek világában terjedtek el, ugyanis ezekben a körökben a piac, vagy éppen a jogszabályi környezet gyors és folyamatos változásai nem teszik lehetővé a precíz és állandó követelmények kialakítását. Ugyanakkor meg kell azt is említeni, hogy az agilis fejlesztési módszertanok napjainkban a műszaki fejlesztésekben is teret nyertek. Ebben a körben elsősorban a piacra kerülés, a piaci előny megszerzése, vagy megtartása adja az indokot.
Az agilitás alapelvei, amelyről bővebben ezen a linken olvashatsz:
- működő szoftver szállítása minél gyakrabban,
- a követelmények változtathatósága,
- fejlesztők és szakértők együttműködése,
- csapatközpontúság,
- motivált csapat,
- személyes kommunikáció,
- a csapatműködés fejlesztése,
- fenntartható fejlesztés,
- rendszeres tervezés és minőségi kód szállítása,
- egyszerűség.
Az agilis szó arra utal, hogy a fejlesztés változásbarát, azaz elfogadja, hogy a követelményekben változások lehetnek. Az üzleti szoftverek fejlesztésében ez a szempont alapvető, ugyanis például jogszabályváltozás miatt is gyakran változhatnak a követelmények. Az agilis módszertanok lényegében arra fókuszálnak, hogy a teljes fejlesztési folyamatot olyan kisebb egységekre bontsák fel, amelyek önmagukban már képesek az ügyfél számára értéket szállítani, ugyanakkor változás esetén a lehető legkevesebb munka vesszen kárba.
A tesztelés helye az agilis fejlesztésben¶
A tesztelés világában az agilitás a csapatközpontú megközelítésben nyilvánul meg. A tesztelő egyik fontos készségeként lépett elő az a követelmény, hogy hatékonyan tudjon csapatban dolgozni, és alkotó módon tudjon hozzájárulni a csapat céljainak megvalósításához. A teljes csapatmegközelítés – egy gyakorlat az eXtrém Programozásból (XP) – erre a készségre épül. A teljes csapatmegközelítés lényege, hogy a csapat tagjai együttesen és külön külön is felelősek a termék minőségéért, illetőleg nincs személyre szabott dedikált szerepkör egy adott csapaton belül, hanem aki rendelkezik a megfelelő kompetenciákkal, az bármilyen feladatot elvégezhet.
A tesztelők szorosan együttműködnek a többi csapattaggal és az üzleti oldal képviselőivel, ami segítséget ad a tesztstratégiák kidolgozásában és az elvárásoknak megfelelő elfogadási tesztek létrehozásában.
Mivel az agilis fejlesztés feltételezi a változást, ezért a nem túl részletes dokumentáció és a széleskörű automatizálás preferált, amely utóbbi segít a regressziós tesztelés hatékonyságának növelésében.
Regressziós tesztelés
A regressziós tesztelés egy olyan tesztelési típus, amely arra szolgál, hogy ellenőrizze, hogy a szoftverben végrehajtott kódváltoztatás nem befolyásolta hátrányosan a meglévő funkciókat. Ennek célja, hogy biztosítsa, hogy a termék új funkciókkal, hibajavításokkal vagy a meglévő funkció bármilyen változtatásával jól működjön. A regressziós tesztelés elengedhetetlen a szoftverminőség fenntartásához, mivel segít az új kódmódosítások mellékhatásainak azonosításában és a meglévő funkcionális tesztek zavartalan működésének biztosításában. Ezt a tesztet például új funkciók bevezetésekor, változások után vagy hibajavítások után alkalmazzák.
A tesztelés szempontjai tekintve meg kell említeni a tesztelés irányából történő, azaz a tesztvezérelt szoftverfejlesztés szerepének növekedését. Ezek a fejlesztési megközelítések az iteratív modellekre épülnek és jól illeszlednek az agilis fejlesztés kereteibe.
- Tesztvezérelt fejlesztés (Test Driven Development - TDD): A módszer lényege, hogy a kódolási folymatot az átfogó tervek helyett tesztesetek irányítják. A fejlesztés során először a teszteket írják meg, majd ezt követi a kód, amelynek meg kell felelni a tesztesetekben megfogalmazott elvárásoknak.
- Elfogadási teszt által vezérelt fejlesztés (Acceptance Test Driven Development - ATDD): Egy olyan tesztvezérelt fejlesztési módszer, ahol a teszteket az elfogadási feltételekből (acceptance criteria) származtatják.
- Viselkedésvezérelt fejlesztés (Behaviour Driven Development - BDD): A módszer alkalmazásával olyan teszteseteket írnak, amely az alkalmazás elvárt viselkedését fejezi ki egyszerű formában, természetes nyelven, és így könnyen érthető az érdekelt felek számára – általában a "Given/When/Then" formát használva.
Felhasználói történetek (User stories)¶
Az agilis fejlesztési módszertanokban, különösen a Scrum esetében az egyes fejlesztési feladatokat önálló felhasználói történetekre, user storykra bontják. A user storykat minden esetben a megrendelő szemszögéből fogalmazzák meg. Általában egyszerű, egy inkremensként fejleszthető feladatot tartalmaznak. A felhasználói történetek formális szerkezettel rendelkeznek:
- As a [end user role], I want [the desire] so that [the rationale].
- A felhasználói történetből kiindulva a fejlesztési feladatot munkafeladatok szintjére (task) bontjuk le.
- Elfogadási feltételek (acceptance criteria) azok a feltételek (követelmények), amelyeket a fejlesztett funkcionalitásnak teljesítenie kell annak érdekében, hogy azt a Product Owner (PO) elfogadja és a fejlesztés eredményét átvegye. Az elfogadási feltételek a felhasználói történetekhez kapcsolódnak, de külön is megfogalmazhatók. Lényegében követelmények listájaként lehet rájuk tekinteni.
Product Owner
Az agilis fejlesztési módszertanokban a Product Owner (PO) képviseli az üzleti oldalt. Az ő szerepe a kapcsolattartás az üzlettel, az üzleti követelmények epic formájában történő megfogalmazása, annak finomítása felhasználói történetek szintjére. Az egyes fejlesztési ciklusok részére az egyes feladatokat (backlog) az üzleti oldali követelmények alapján priorizálja. A Product Owner feladata az egyes inkrementumok üzleti oldali ellenőrzése és átvétele.
A felhasználói történetek tehát olyan funkciókat reprezentálnak, ami a rendszer vagy szoftver felhasználójának lesz értékes. Ugyan a fentiek alapján azt mondtuk, hogy a Product Owner felelőssége a felhasználói történetek megírása, a valóságban ez a csapattal együtt végzett közös kreatív tevékenység.
Kritikus szempontok (3C)
A felhasználói történetek megírása, illetőleg az üzleti követelmények felhasználói történetekre való felbontása során az alábbi pontokban megfogalmazott szempontokat kell figyelembe venni:
- Kártya (Card) - a felhasználói történeteket egy tényleges kártyára (fizikai kártya vagy bejegyzés egy elektronikus táblán) írják fel.
- Beszélgetés (Conversation) - a felhasználói történet készítése során a szoftver várt funkcionalitását be kell mutatni (lehet szóban vagy dokumentáltan).
- Megerősítés (Confirmation) - az elfogadási feltételekben kerülnek rögzítésre.
Egy felhasználói történet elfogadási feltételei azok a feltételek, amelyeknek a felhasználói történet megvalósítása során teljesülniük kell ahhoz, hogy a teljesítést az érdekelt felek elfogadják. Az elfogadási feltételeket tekinthetjük tesztfeltételeknek, amelyeket a teszteknek ki kell elégíteniük, vagyis a teszteseteket az elfogadási feltételekből származtatják (Acceptance Test Driven Development ATDD). A teszteket manuálisan és automatizált módon is végrehajthatják. Az elfogadási kritériumok általában funkcionálisak, azonban figyelni kell arra is, hogy a nemfunkcionális követelményekről és az azokhoz kapcsolódó tesztesetekről se feledkezzünk meg. A tesztesetek definiálása során arra kell törekedni, hogy azokat minden érintett egyformán értelmezze.
A felhasználói történetek a projekthez kapcsolódó epicekből (az epic olyan komplex projektfeladat, amely az üzleti követelmények összességét tartalmazza) származnak, és az egy fejlesztési ciklusban (például sprint során a SCRUM-ban) megoldandó feladatokat tartalmazzák. Mikor a feladattervezés történik, a csapatnak becslést kell adni a feladat komplexitására, illetőleg a fejlesztéshez szükséges ráfordításokra. A becslés eredménye egy olyan mérőszám, amely tükrözi a feladat megoldásához szükséges erőfeszítés mértékét és a csapattagok számára ugyanazt jelenti. Nincs konkrét definíciója, minden csapatnál más és más a jelentése. Legegyszerűbb esetben a fejlesztésre fordított időt jelenti, viszont ahogy a csapat tapasztalata nő, a mérőszám egyre inkább egy absztrakt jelentéssel fog bírni.
Miért nem jó mérőszám a szükséges idő?
Azért, mert a csapattagok eltérő tapasztalattal, ismerettel és készségekkel rendelkeznek. Ugyanazt a feladatot valaki gyorsabban tudja megoldani, mint más, egy másik feladat esetében meg fordított a helyzet. A gyakorlatban a csapatok szinte mindig az időből indulnak ki, de ahogy a tapasztalat nő, úgy a mérőszám is inkább egy absztrakt komplexitást fog jelenteni, amelyben a csapattagok egyetértenek, bár nem biztos hogy pontosan meg tudják fogalmazni mi is van mögötte.
Becslések megadása a projektmunka feladataihoz
Ahogy ezt általában minden agilis csapat teszi kezdetben, a kurzusban összeállt csapatok is alkalmazhatják a szükséges időt, mint a szükséges ráfordítás mértékét.
A komplexitás becsléséről érdekes és hasznos információk találhatók ezen a blogon.
Adjunk becslést a következő feladatra!
Felhasználói történet: Könyvtári tagként szeretném a könyveket online megújítani, hogy hosszabb ideig megőrizhessem őket anélkül, hogy a könyvtárba kellene mennem.
Elfogadási kritérium: A rendszernek lehetőséget kell adnia arra, hogy a könyvtári tag olyan könyvet újítson meg, amely nem késedelmes, és amelyet nem foglalt le időközben egy másik tag. A megújítás után az esedékességi időnek meg kell hosszabbodnia.
Tételezzük fel, hogy a könyvtári rendszer fejlesztői vagyunk, de nem minden modulját ismerjük kielégítően (azaz a feladat része, hogy az érintett modulok szerkezetét és működését megismerjük).
Planning poker
A technika a Wideband Delphi becslési eljárásból fejlődött ki. A csoport tagjai úgy készítenek becsléseket, hogy a számozott kártyákat képpel lefelé az asztalra dobják, ahelyett, hogy hangosan kimondanák azokat. A kártyákat felfedik, majd megvitatják a becsléseket. A számok ilyen módon történő elrejtésével a csoport elkerülheti a lehorgonyzás kognitív torzítását, amikor az első hangosan kimondott szám precedenst teremt a későbbi becslések számára.
Egy tipikus pakliban a Fibonacci-sorozatot tartalmazó számozott kártyák találhatók, beleértve a nullát is: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89; más paklik hasonló sorrendet használnak, az egyes értékek között meghatározott arányban. A Fibonacci-sorozat használata azért indokolt ahelyett, hogy egyszerűen megdupláznánk minden egyes egymást követő értéket, mert egy feladatot pontosan kétszer akkora erőfeszítésre becsülni, mint egy másik feladatot, félrevezető pontosságú. Egy olyan feladatot, amely körülbelül kétszer akkora erőfeszítéssel jár, mint egy 5-ös, vagy a duplájánál valamivel kevesebbre (8), vagy a duplájánál valamivel többre (13) kell értékelni.
A planning póker online is játszható
Nem feltétlenül kell fizikai formában beszerezni a kártyákat, hogy a becsléshez használjuk a technikát. Számos online, ingyenesen használható lehetőség is rendelkezésre áll. A gyakorlaton használható például a PlanningPokerOnline.
Projektcsapatok összeállítása¶
A gyakorlat központi eleme a csapatmunkában végzett projektfeladat teljesítése. Ehhez a hallgatóknak 4-5 fős csapatokba kell szerveződnie.
Csapatok összeállítása
A gyakorlatvezető irányításával állítsunk össze a gyakorlat hallgatóiból álló 4-5 fős csapatokat. A csapattagok helyezkedjenek el úgy a teremben, hogy a közös munka során a kommunikáció egymás között gördülékeny legyen!
Projektválasztás
A csapatok által választható projektek a CooSpace összevont gyakorlat fórumában találhatók meg. A projektmunkára jelentkezés levélben történik a következő gyakorlatot megelőző nap 8:00:00 -ig. Azt követően a gyakorlaton lesz kijelölve minden csapat számára a tényleges projekt. A projektet tartalmazó repositoryt forkolni kell majd.
Nem mi választunk projektet?
Projektet alapvetően a csapatok választanak, de szeretnénk elkerülni az ütközéseket. Egy projektet egy csapathoz kell rendelni. Ütközés esetén javasolt a csapatoknak maguk között megegyezni a választásban, de végső soron a gyakorlatvezető dönt.
Hogyan tesztelnéd?¶
Gondolkodtál már azon mi a tesztelés célja? Az egyszerű és egyébként adekvát válasz az, hogy hibákat keresünk a szoftverben. Nem próbáljuk meg igazolni, hogy a szoftver hibamentes, ugyanis ez nem lehetséges. A szoftverek kreatív emberi tevékenység eredményeképpen jönnek létre, az ember pedig esendő és sokszor hibázik, téved. Ezek az emberi tévedések hibákat (bugokat) eredményeznek a szoftverben, amely hibák a szoftver működésének meghibásodásához vezethetnek. A teszteléssel feltárt hibák hozzásegítenek a szoftver minőségének növekedéséhez (amennyiben a hibák javításra kerülnek), ezáltal a meghibásodások valószínűségének csökkentéséhez.
A tesztelés alapelvei¶
-
A tesztelés a szoftverhibák meglétét képes kimutatni, és nem a hiányukat.
-
Kimerítő tesztelés lehetetlen, ezért priorizálni kell a teszteket és meg kell határozni a kilépési feltételeket. Alkalmazható mindezek mellett a kockázatalapú tesztelés, amelyben a magas kockázatú tesztesetek meghatározásával adjuk meg a prioritási sorrendet.
Mit jelent a kimerítő tesztelés?
Ez a tesztelési fajta minden lehetséges futást kipróbál, de gyakorlatban általában nem kivitelezhető, mivel idő- és erőforrásigényes. A kimerítő tesztelés során a programot minden lehetséges szcenárióban és minden lehetséges inputra, beállításra tesztelik.
-
A tesztelést minél korábban el kell kezdeni. A folyamat korai szakaszában eltávolított hibák nem okoznak későbbi hibákat a származtatott munkatermékekben. A minőség költsége csökken, mivel a szoftverfejlesztési életciklus későbbi szakaszaiban kevesebb meghibásodás következik be.
-
A hibák fürtökben fordulnak elő a modulokban, nem egyenletesen (Pareto-elv: a problémák kb. 80%-a a modulok kb. 20%-ában található).
Pareto elv
A Pareto elv valójában azt mondja ki, hogy a jelenségek 80%-a az okok mindössze 20%-ára vezethető vissza. Ez a megállapítás a minőségügy területére is igaz, amely szerint a bekövetkező problémák 80%-át az elkövetett hibák 20%-a okozza. Részletesebben lásd a Wikipédia cikkét a Pareto elvről.
-
Rovarirtó jelenség: ugyanannak a tesztnek a futtatása nem fog újabb hibát találni (fejlesztők figyelnek a tesztekre és az érintett hibákat elkerülik). Ebből adódóan folyamatosan frissíteni kell a teszteket. Másképpen úgy is megfogalmazható ez az elv, hogy a tesztek "elkopnak".
-
A tesztelés környezetfüggő. Ez az elv azt mondja ki, hogy nincs egyetlen univerzálisan alkalmazható megközelítése a tesztelési feladatnak, hanem azt mindig az adott környezet sajátosságainak megfelelően kell alakítani.
-
A hibamentesség téveszme, nincs hibamentes szoftver. Tévedés (vagy tévhit) azt várni, hogy a szoftververifikáció biztosítja a rendszer sikerét. Az összes meghatározott követelmény alapos tesztelése és a feltárt hibák kijavítása még mindig produkálhat olyan rendszert, amely nem felel meg a felhasználók igényeinek és elvárásainak, amely nem segíti az ügyfél üzleti céljainak elérését, és a versenytársak rendszereihez képest gyengébb. A verifikáció mellett a validálást is el kell végezni.
Mi a verifikáció?
A verifikáció során azt ellenőrizzük, hogy a szoftver teljesíti-e a specifikációban leírt követelményeket, valamint ezt az elvárható minőségben teszi-e. Arra a kérdésre válaszol, hogy a specifikált terméket jól készítjük-e el.
Mi a validáció?
A validáció során azt ellenőrizzük, hogy az elkészült termék teljesíti-e a megrendelői igényeket. Vagyis arra a kérdésre válaszolunk, hogy tényleg azt a terméket fejlesztjük, amelyet a megrendelő szeretne, tényleg a megrendelő elvárásai szerint működik-e a szoftver.
Feladatok¶
Teszteld a http://www.hrportal.hu/ valamelyik kalkulátorát
Válassz ki egyet az alábbi kalkulátorok közül, és teszteld!
FONTOS!
Biztonsági (security) tesztet NE végezzünk, mert előzetes bejelentés és engedélyek nélkül az törvénybe ütköző cselekmény!
Egyelőre NE olvass tovább!!! Először végezd el az előző feladatot!
Hogyan tesztelted?
- Kerestél valamilyen specifikációt?
- Milyen adatokkal tesztelted?
- Feljegyezted a teszt input-okat?
- Milyen más adatokat rögzítenél?
- Tudnád reprodukálni a tesztet?
- Milyen böngésző(ke)t/oprendszert használtál?
- Válaszidőket megfigyelted?
- Forráskódot néztétek?
- Milyen biztonsági kockázatokat rejthet az alkalmazás?