Cikkjelölt:Specifikáció példa szerint
A példa szerinti specifikáció (SBE) egy együttműködésen alapuló megközelítés a szoftvertermékek követelményeinek és üzletorientált funkcionális tesztjeinek meghatározására a követelmények rögzítése és szemléltetése alapján, absztrakt állítások helyett valósághű példákon keresztül. Alkalmazása az agilis szoftverfejlesztési módszerek, különösen a viselkedésvezérelt fejlesztés keretében történik. Ez a megközelítés különösen sikeres a követelmények és a funkcionális tesztek menedzselésében jelentős területi és szervezeti komplexitású, nagyszabású projekteknél.[1]
A példa szerinti specifikáció más néven példavezérelt fejlesztés, végrehajtható követelmények, átvételi tesztvezérelt fejlesztés (ATDD[2] vagy A-TDD[3]), Agile Acceptance Testing,[4] Test-Driven Requirements (TDR).
Előnyök[szerkesztés]
Az erősen elvont vagy újszerű új fogalmakat konkrét példák nélkül nehéz megérteni. példán keresztül történő specifikáció célja a pontos megértés kialakítása, és jelentősen csökkenti a visszacsatolási hurkokat a szoftverfejlesztésben, ami kevesebb utómunkálathoz, jobb termékminőséghez, a szoftverváltoztatások gyorsabb átfutási idejéhez és a szoftverben részt vevő különböző szerepek tevékenységeinek jobb összehangolásához vezet. fejlesztők, például tesztelők, elemzők és fejlesztők.[1]
A példák az igazság egyetlen forrásaként[szerkesztés]
A példákkal történő specifikáció kulcsfontosságú szempontja, hogy egyetlen igazságforrást hozzon létre a szükséges változtatásokról minden szempontból. Amikor az üzleti elemzők saját dokumentumaikon dolgoznak, a szoftverfejlesztők saját dokumentációjukat, a tesztelők pedig külön funkcionális teszteket tartanak fenn, a szoftverszállítás hatékonysága jelentősen csökken, mivel folyamatosan koordinálni és szinkronizálni kell az igazság különböző változatait. Rövid iteratív ciklusok esetén az ilyen koordináció gyakran heti vagy kéthetente szükséges. A Specification by példa segítségével különböző szerepek vesznek részt az igazság egyetlen forrásának létrehozásában, amely mindenki megértését megragadja. A példák az egyértelműség és a pontosság biztosítására szolgálnak, így ugyanaz az információ használható specifikációként és üzleti célú funkcionális tesztként is. A fejlesztés vagy szállítás során felfedezett minden további információ, mint például a funkcionális hiányosságok tisztázása, hiányzó vagy hiányos követelmények vagy további tesztek, hozzáadódik ehhez az egyetlen igazságforráshoz. Mivel a funkcionalitásról egyetlen igazságforrás van, nincs szükség a tudás koordinációjára, fordítására és értelmezésére a szállítási cikluson belül.
A szükséges változtatásokra alkalmazva a kifinomult példakészlet gyakorlatilag specifikációt és üzletorientált tesztet jelent a szoftverfunkciók elfogadásához. A változtatás végrehajtása után a példákat tartalmazó specifikáció a meglévő funkcionalitást magyarázó dokumentummá válik. Mivel az ilyen dokumentumok érvényesítése automatizált, gyakran érvényesítve az ilyen dokumentumok megbízható információforrást jelentenek az alapul szolgáló szoftverek üzleti funkcióiról. Az ilyen dokumentumok és a tipikus nyomtatott dokumentációk megkülönböztetésére, amelyek gyorsan elavulnak,[4] a példákkal ellátott specifikációk teljes készletét Living Documentation néven nevezzük.[1]
Kulcsgyakorlatok[szerkesztés]
A specifikációt példa alapján sikeresen alkalmazó csapatok általában a következő folyamatmintákat alkalmazzák:[1]
- A hatókör levezetése a célokból
- Együttműködően történő meghatározás – az egész csapatra kiterjedő specifikációs workshopokon, kisebb megbeszéléseken vagy telekonferencia áttekintéseken keresztül
- Követelmények szemléltetése példákon keresztül
- Specifikációk finomítása
- Tesztek automatizálása példák alapján
- Az alapul szolgáló szoftver gyakori ellenőrzése a tesztek segítségével
- Dokumentációs rendszer fejlesztése specifikációkból példákkal a jövőbeli fejlesztés támogatása érdekében
Azok a szoftvercsapatok, amelyek a specifikációt példán keresztül alkalmazzák a Scrum keretrendszeren belül, általában idejük 5–10%-át a termékhátralék finomításával töltik, beleértve az együttműködésen alapuló specifikációt, a követelmények példák segítségével történő illusztrálását és a példák finomítását.[3]
Példa leképezés[szerkesztés]
A példaleképezés egy egyszerű technika, amely képes irányítani a beszélgetést, és rövid időn belül elfogadási feltételeket határoz meg. A folyamat a történeteket szabályokra és példákra bontja, amelyeket példánként specifikáció formájában dokumentálnak, és széles körben használt technika a BDD szférában.[5]
Alkalmazhatóság[szerkesztés]
A példa szerinti specifikáció azokra a projektekre vonatkozik, amelyek szervezeti és tartományi összetettsége kellően bonyolult ahhoz, hogy problémákat okozzon a követelmények megértésében vagy kommunikációjában az üzleti terület szempontjából. Nem vonatkozik tisztán technikai problémákra, vagy ahol a kulcsfontosságú összetettség nem a tudás megértésében vagy közlésében rejlik. Ennek a megközelítésnek vannak dokumentált alkalmazásai olyan területeken, mint a befektetési banki szolgáltatások, a pénzügyi kereskedés, a biztosítás, a repülőjegy-foglalás, az online szerencsejáték és az ár-összehasonlítás.[1] Hasonló megközelítést dokumentál egy atomerőművi szimulációs projekt is.[3]
A megosztott példákon alapuló tesztek a legjobban azon tesztek kategóriájába illeszkednek, amelyek célja egy csapat támogatása, miközben üzleti szempontból szoftvereket szállítanak (lásd: Agilis tesztelési kvadránsok[6]) – biztosítva a megfelelő termék elkészítését. Nem helyettesítik azokat a teszteket, amelyek egy szoftverrendszert pusztán technikai szempontból vizsgálnak (azokat, amelyek értékelik, hogy egy termék megfelelő módon épül-e fel, például egységtesztek, komponens- vagy műszaki integrációs tesztek), vagy azokat a teszteket, amelyek értékelik a terméket a fejlesztés után. (például biztonsági behatolási tesztek).
Történet[szerkesztés]
A valósághű példák legkorábbi dokumentált felhasználása az igazság, a követelmények és az automatizált tesztek egyetlen forrásaként szoftverprojektekben a WyCash+ projekt, amelyet Ward Cunningham ír le az A Pattern Language of Competitive Development[7][8] című cikkében 1996-ban. A Specification by Example elnevezést Martin Fowler találta ki 2004-ben.[9]
A Példával történő specifikáció az Extreme Programming 1997 körül javasolt Customer Test[10] gyakorlatának és a 2004-es tartományvezérelt tervezésből származó Ubiquitous Language[11] ötletnek az evolúciója, amely a fekete doboz tesztek ötletét használja Weinberg és Gause által leírt követelményekként.[12] 1989-ben.
Automatizálás[szerkesztés]
A specifikáció sikeres példán keresztüli alkalmazása nagyszabású projekteken a szoftver funkcionalitásának gyakori ellenőrzését igényli számos példa (teszt) alapján. A gyakorlatban ehhez a példákon alapuló tesztek automatizálására van szükség. Egy általános megközelítés a tesztek automatizálása, de a példák olvasható és hozzáférhető formában maradnak a nem műszaki és műszaki csapattagok számára, így a példák az igazság egyetlen forrása. Ezt a folyamatot a tesztautomatizálási eszközök egy osztálya támogatja, amelyek két szempontra - a specifikációra és az automatizálási rétegre - osztott tesztekkel dolgoznak. Egy teszt specifikációja, amely gyakran egyszerű szöveg vagy HTML formátumban van, és tartalmazza a példákat és a kiegészítő leírásokat. Az automatizálási réteg összekapcsolja a példát egy tesztelt szoftverrendszerrel. Példák az ilyen eszközökre:
- Behat
- Concordion
- Cucumber
- FitNesse
- Framework for integrated test (Fit)
- Robot Framework
- SpecFlow for .NET
- Gauge (szoftver)
Hivatkozások[szerkesztés]
- ↑ a b c d e Adzic, Gojko. Specification by example: How successful teams deliver the right software. Manning (2011). ISBN 9781617290084
- ↑ Pugh, Ken. Lean-Agile Acceptance Test Driven Development: Better Software Through Collaboration: A Tale of Lean-Agile Acceptance Test Driven Development. Addison Wesley (2011). ISBN 978-0-321-71408-4
- ↑ a b c Larman, Craig. Practices for Scaling Lean and Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum. Pearson (2010). ISBN 978-0-321-63640-9
- ↑ a b Adzic, Gojko. Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing. Neuri (2009). ISBN 0-9556836-1-0
- ↑ Wynne: Introducing Example Mapping. Cucumber Blog, 2015. december 8. (Hozzáférés: 2021. május 10.)
- ↑ Crispin, Lisa. Agile Testing: A Practical Guide for Testers and Agile Teams. Addison Wesley (2008). ISBN 978-0-321-53446-0
- ↑ Pattern Languages of Program Design 2. Addison-Wesley (1996). ISBN 978-0-201-89527-8
- ↑ Ward Cunningham: EPISODES: A Pattern Language of Competitive Development Part I. C2.com. (Hozzáférés: 2014. január 8.)
- ↑ Martin Fowler 18 March 2004: SpecificationByExample. Martinfowler.com, 2004. március 18. (Hozzáférés: 2014. január 8.)
- ↑ Beck, K.. Extreme Programming Explained: Embrace Change. Addison-Wesley (1999). ISBN 978-0-321-27865-4
- ↑ Evans, Eric. Domain-Driven Design:Tackling Complexity in the Heart of Software. Addison-Wesley (2004). ISBN 0-321-12521-5
- ↑ Weinberg, Gerald. Exploring Requirements: Quality Before Design. Dorset House (1989). ISBN 0-932633-13-7
Fordítás[szerkesztés]
Ez a szócikk részben vagy egészben a Specification by example című angol Wikipédia-szócikk ezen változatának fordításán alapul. Az eredeti cikk szerkesztőit annak laptörténete sorolja fel. Ez a jelzés csupán a megfogalmazás eredetét és a szerzői jogokat jelzi, nem szolgál a cikkben szereplő információk forrásmegjelöléseként.