Ugrás a tartalomhoz

Cikkjelölt:Specifikáció példa szerint

A Wikipédiából, a szabad enciklopédiából

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]
  1. a b c d e Adzic, Gojko. Specification by example: How successful teams deliver the right software. Manning (2011). ISBN 9781617290084 
  2. 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 
  3. 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 
  4. a b Adzic, Gojko. Bridging the Communication Gap: Specification by Example and Agile Acceptance Testing. Neuri (2009). ISBN 0-9556836-1-0 
  5. Wynne: Introducing Example Mapping. Cucumber Blog, 2015. december 8. (Hozzáférés: 2021. május 10.)
  6. Crispin, Lisa. Agile Testing: A Practical Guide for Testers and Agile Teams. Addison Wesley (2008). ISBN 978-0-321-53446-0 
  7. Pattern Languages of Program Design 2. Addison-Wesley (1996). ISBN 978-0-201-89527-8 
  8. Ward Cunningham: EPISODES: A Pattern Language of Competitive Development Part I. C2.com. (Hozzáférés: 2014. január 8.)
  9. Martin Fowler 18 March 2004: SpecificationByExample. Martinfowler.com, 2004. március 18. (Hozzáférés: 2014. január 8.)
  10. Beck, K.. Extreme Programming Explained: Embrace Change. Addison-Wesley (1999). ISBN 978-0-321-27865-4 
  11. Evans, Eric. Domain-Driven Design:Tackling Complexity in the Heart of Software. Addison-Wesley (2004). ISBN 0-321-12521-5 
  12. 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.

További információk

[szerkesztés]