Leiðbeiningar BDD og bestu starfsvenjur

BDD (Behavior Driven Development) er aðferðafræði til að þróa hugbúnað í gegnum stöðugan dæmi byggt samskipti milli forritara, QA og BA. Í þessari grein fjöllum við um nokkrar bestu venjur BDD til að fá sem mestan ávinning.

Meira en nokkuð annað er aðal tilgangur BDD aðferðafræðinnar að hvetja til samskipta milli hagsmunaaðila verkefnisins svo að samhengi hvers eiginleika skiljist rétt af öllum meðlimum teymisins (þ.e. sameiginlegur skilningur) áður en þróunarstarf hefst. Þetta hjálpar til við að greina lykilatburðarás fyrir hverja sögu og útrýma tvíræðni frá kröfum.

Í BDD eru dæmi kölluð sviðsmyndir. Sviðsmyndir eru byggðar upp í kringum Samhengi-aðgerð-útkoma mynstur og eru skrifaðar á sérstöku sniði sem kallast Kúrbítur .


Sviðsmyndirnar eru leið til að útskýra (á látlausu ensku) hvernig tiltekinn eiginleiki ætti að haga sér við mismunandi aðstæður eða með mismunandi inntaksbreytur.

Vegna þess að Gherkin er uppbygging, þjónar það bæði sem forskrift og inntak í sjálfvirkar prófanir, þaðan kemur nafnið „Executable Specifications“.


Hvað er eiginleikaskrá og hvað inniheldur hún

Aðgerðarskrár eru textaskrár með .einkenni eftirnafn, sem hægt er að opna með hvaða textaritli sem er og hægt að lesa með hvaða BDD-tæki sem er meðvitað, svo sem Agúrka, JBehave eða Behat.



Aðgerðarskrár ættu að byrja með samhengi eiginleikans (sem er í raun sagan) og síðan að minnsta kosti ein atburðarás á eftirfarandi sniði

Lögun: Sumir stuttur en samt lýsandi texti yfir það sem óskað er

Til þess að átta sig á nafngreindu viðskiptagildi
Sem skýr kerfisleikari
Ég vil fá jákvæða niðurstöðu sem stuðlar að markmiðinu


Atburðarás: Einhver ákvarðanleg viðskiptastaða

Gefin nokkur forsenda
Og einhver önnur forsenda
Þegar einhver aðgerð leikarans
Og einhver önnur aðgerð
Og enn ein aðgerð
Þá næst einhver prófanleg niðurstaða
Og annað sem við getum athugað gerist líka

Sviðsmyndir í eiginleikaskrám ættu að einblína á „hvað“ frekar en „hvernig“. Sviðsmyndirnar ættu að vera hnitmiðaðar og að markinu, svo að lesandinn geti fljótt skilið ásetning prófsins án þess að þurfa að lesa mikið af óviðkomandi skrefum.

Af hverju ættum við að skrifa eiginleikaskrár

Eins og áður hefur komið fram er meginmarkmið BDD aðferðafræðinnar að hvetja til samskipta milli afhendingarhópsins. Markmið eiginleikaskrárinnar er að skjalfesta atburðarásina sem talað er um til að gefa vísbendingu um hversu mikil vinna felst í því að skila eiginleikanum. Aðgerðarskrárnar eru einnig reklar fyrir sjálfvirku prófin. Aðgerðarskrár þjóna einnig sem skilgreiningu á gert (DoD), sem þýðir að þegar allar sviðsmyndir hafa verið útfærðar og prófaðar með góðum árangri, getum við merkt söguna sem lokið.


Hver á að skrifa eiginleikaskrár

Það skiptir í raun ekki máli hver raunverulega skrifar / slær inn eiginleikaskrárnar, það gæti verið hvaða meðlimur sem er í afhendingarhópnum, þó er innihaldið (sviðsmyndir) sem fjallað er um af tríói Dev-QA-BA er meginatriðið í löguninni skrár. Að fá sameiginlegan sameiginlegan skilning á eiginleikanum er lykilatriðið.

Hvenær ætti að skrifa eiginleikaskrár

Aðgerðarskrár ættu að vera skrifaðar á sögusnyrtingunum þar sem fjallað er um smáatriði hverrar sögu. Aðgerðarskrár sem innihalda sviðsmyndir ættu að vera skrifaðar áður en þróun hefst svo að verktaki sem og QA hafi skýran skilning á tilgangi sögunnar. Það ætti að vera sameiginlegur skilningur á sögunni. Sviðsmyndirnar þjóna sem kröfur til þróunar.

Hvar á að geyma eiginleikaskrár

Það ætti að vera ein uppspretta sannleika sem þjónar bæði sem forskrift og sjálfvirkri framkvæmd, þess vegna ætti að vera það einhvers staðar þar sem allir meðlimir liðsins hafa greiðan aðgang.

Að því sögðu, vegna þess að eiginleikaskrárnar eru reklar sjálfvirku prófanna, þá ætti helst að geyma þær í heimildastýringarkerfi (GitHub) svo að allar uppfærslur á eiginleikaskrám endurspeglast strax í prófunum.


Fyrir meðlimi sem ekki eru tæknilegir og hafa enga reynslu af Git, getum við alltaf framkvæmt þurrkeyrslu á eiginleikaskrám sem síðan sendir lista yfir allar sviðsmyndir sem fyrir eru án þess að nýta eiginleikaskrárnar í raun.

Hvernig eigum við að skrifa eiginleikaskrár

Það eru venjulega tvær leiðir til að skrifa eigin skrár - mikilvægt og yfirlýsing

Brýnt stíll við að skrifa eiginleikaskrá, er mjög orðrétt, inniheldur smáatriði og of mikið af upplýsingum.

Kostir: Sá sem les eiginleikaskrána getur fylgt skref fyrir skref


Gallar: Vegna of mikilla smáatriða getur lesandinn tapað stigi sögunnar og prófunum. Aðgerðarskráin verður of stór, erfið í viðhaldi og líkleg til að mistakast vegna uppfærslna HÍ.

Yfirlýsing stíll við að skrifa eiginleikaskrá er hnitmiðaður og að því marki, inniheldur aðeins viðeigandi upplýsingar um söguna.

Kostir: Yfirlýsingastíllinn er læsilegri þar sem hann inniheldur færri skref í atburðarásinni. Lesandinn getur auðveldlega skilið umfang prófunarinnar og greint fljótt hvort einhverja lykilþætti vantar.