“Kas me läheme sinna progema?” ehk kuidas Proeksperdi kvaliteediinsenerid BDD’d tegemas käisid

Kuna Proeksperdi kvaliteedimeeskonna eelmisest treeningpäevast oli möödunud juba hea mitu kuud, kõik olid karmidest kogemustest taastunud ning meeskonda oli lisandunud ka uusi liikmeid, oligi augustikuu eelviimane päev paras hetk järgmise väliõppuse korraldamiseks. Püüaks sellest siis ka natuke lähemalt rääkida.

Seekordse treeningpäeva teemaks sai valitud Behavior-Driven Development ehk BDD metoodika, millest olen ka varem lühidalt kirjutanud. Kuna päris tühja koha pealt on sant alustada, tuli riiulist alla tõsta ja tolmust puhtaks puhuda üks Proeksperdi sisemine projekt – Raamatukogu 2.0, mis on meie füüsilist raamatukogu toetav veebipõhine rakendus. Kuna see rakendus oli juba algusest peale loodud just BDD metoodikat kasutades, oli tegu pea ideaalse õppevahendiga.

 

Kuidas BDD töötab

BDD üks definitsioone kõlab järgnevalt:

Behaviour-driven development is an “outside-in” methodology. It starts at the outside by identifying business outcomes, and then drills down into the feature set that will achieve those outcomes.

Piltlikult esitades töötab see metoodika umbes nii:

  1. Iga stsenaariumi jaoks, mis kirjeldab mingit funktsionaalsust
  2. käivita stsenaarium – tulemuseks on FAIL
  3. defineeri esimene samm – ka selle tulemus on FAIL
  4. kirjuta rakenduse koodi täpselt niipalju, et sammu tulemus oleks PASS
  5. refaktoori kirjutatud kood ja korda samme 4 & 5 iga stsenaariumi sammuga kuni…
  6. …kogu stsenaariumi tulemus on PASS
  7. refaktoori rakenduse kood ja alusta uuesti sammust number 2

 

Tööjaotusest ja ülesannetest

Meeskond jagunes ka seekord gruppidesse üsna kergesti – viis gruppi, igaühes neli inimest. Gruppide koosseisu valimisel oli üheks eesmärgiks panna ühte gruppi kokku võimalikult erinevate kogemuste ja oskustega inimesed. Grupijuhtide valikul sai otsustavaks see, et juhi rolli täidaks inimene, kelle jaoks juhtimine ei ole igapäevane ülesanne, kes saaksid seeläbi uue kogemuse võrra rikkamaks.

Lisaks inimestele on meil vaja ka tööriistu, millega sihtmärgile läheneda. Nimetatud Raamatukogu 2.0 rakendus on kirjutatud Rubys, kasutades Rails raamistikku, ning spetsifikatsioonide kirjutamiseks on kasutusel Cucumber. Kuna nimetatud vahendid on multiplatvormsed ja vabad, ei tundunud töökeskkonna ettevalmistamine vähemalt teoorias probleeme tekitavat. Paraku on teooria tihti üsna elukauge nähtus ja nii ka seekord – Windowsiga arvutil Ruby arenduskeskkonna ülesseadmisel võib ilmneda väga huvitavaid komistuskive. Midagi kaelamurdvat ette õnneks ei sattunud ja õigeks päevaks oli igal grupil olemas vähemalt üks arvuti töötava arenduskeskkonnaga.

Kui grupid on koostatud, tööriistad löögivalmis ja õppevahend valitud, on käes aeg jagada ülesandeid. Iga grupp sai esmaseks ülesandeks spetsifitseerida ühe funktsionaalse osa Raamatukogu 2.0 rakendusest, mis on olemas backlogis, kuid mille arendamiseni pole veel jõutud; lisaks tuli ka vähemalt ühe stsenaariumi sammud defineerida programmiloogikas.

Grupiliikmed teadsid päeva alguses oma ülesande plaanitud “business outcome“-i, päeva lõpuks oodatud tulemus oli kirjeldada ära “feature set“, mis tagaks soovitud tulemuse saavutamise. Kõlab lihtsalt? Esialgu veel küll.

 

“Kas me peame seal progema hakkama?”

Kuigi sellises toonis küsimus kerkis ürituse planeerimise jooksul üles päris mitu korda, ei olnud eesmärgiks õppida programmeerima, eelkõige soovisin anda osalejatele hands-on kogemuse tarkvara mõne funktsionaalse osa katmises Cucumberi stsenaariumitega (mis koos stsenaariumisammude definitsioonidega moodustavad tarkvara käivitatava spetsifikatsiooni) BDD metoodikat ja tööriistu kasutades.

Programmeerimise õppimise vältimiseks ei soovinud ma ka ülesande teise eesmärgi – defineerida stsenaariumi(te) sammud programmiloogikas – oodatava tulemusena reaalselt töötavat koodi, ka piisavalt hästi kirjutatud ja arusaadav pseudokood oli täiesti vastuvõetav. Sissejuhatuses esitatud näide ja ka rakendus ise olid kirjutatud Rubys, ilmselt seetõttu kujunes ka gruppide kirjutatud pseudokood valdavalt üsna Rubylikuks.

Kuna mõne kuu eest toimunud Nordic Testing Days konverentsil olin üles astunud samateemalise workshopiga, mis küll piiratud ajalise ressursi tõttu ei jõudnud hands-on faasi, siis sai meie treeningpäevast sujuvalt sellesama workshopi mõnevõrra laiendatud versioon. Sissejuhatuseks kohaldasingi NTD workshopil esitatud BDD teemalise presentatsiooni, täiendades seda näitega nö. “elust enesest” – selleks valisin tillukese osa ühe grupi ülesandest:

Scenario: Notify me when a new book is added
  Given I have enabled notifications
  When a new book is added to the library
  Then I should receive an e-mail about the new book

Väga lühike ja konkreetne stsenaarium, mis kirjeldab ära täpselt, mis toimuma peaks. Defineerime ära ka sammud:

Given /^I have enabled notifications$/ do
  @user = User.find_by_username('my_user')
  @user.settings[:notifications] = 1
  @user.save
end

When /^a new book is added to the library$/ do
  @book = FactoryGirl.create(:book)
end

Then /^I should receive an e\-mail about the new book$/ do
  NotificationMailer.delivery_method = :test
  NotificationMailer.perform_deliveries = true
  NotificationMailer.deliveries.clear
  NotificationMailer.book_added_email(@user, @book).deliver
  @email = NotificationMailer.deliveries.first
  @email.to.should include @user.email
  @email.body.should include @book.title
end

Kui see nüüd väga lühidalt kokku võtta, siis esimese sammuna leitakse baasist kasutaja, seatakse tema teavituste lipp aktiivseks ja salvestatakse muutused. Järgmise sammuna luuakse andmebaasi uus raamat. Lõpuks saadetakse välja e-mail valitud kasutajale valitud raamatu kohta ning kontrollitakse, kas e-maili saaja on meie kasutaja ning kas e-maili sisus mainitakse äsjaloodud raamatut.

Ülejäänud rakenduse koodi ei hakkaks siinkohal välja tooma, aga põhimõte, kuidas suhteliselt vaba tekstina esitatud spetsifikatsioonidest kujunevad automaattestid, peaks siit välja paistma küll.

 

Tagasi treeningpäeva juurde

Eelmise korra kogemust aluseks võttes jagasime ka seekord päeva kolmeks suuremaks osaks, püüdes arvestada piisava ajavaruga:

  1. Esimene osa (2.5 tundi) – sissejuhatus, diagrammide joonistamine ja stsenaariumide koostamine
  2. Teine osa (2 tundi) – stsenaariumide koostamine ja sammude defineerimine
  3. Kolmas osa (2 tundi) – tehtud töö presenteerimine, päeva kokkuvõte ja mõttevahetus edaspidiseks

Sissejuhatus tehtud, asusidki grupid oma ülesandeid murdma. Ülesande kõige esimeseks ja mahukuselt ka kõige väiksemaks osaks oli kavandatud diagrammide joonistamine. Võib tekkida küsimus, miks on antud ülesande juures vaja joonistada diagramme ja kuidas seda üldse teha? Ega tingimata polegi vaja. Eelkõige oli see mõeldud grupisiseselt mõtete korrastamiseks, mitte kohustusliku elemendina, lisaks oli ka diagrammi formaadi valik täiesti vaba. Päeva lõpuks loobus kaks gruppi üldse diagrammi joonistamisest, ülejäänud kolmest kaks kasutasid mindmapi ja üks lähenes ülesandele traditsioonilisema flow-chartiga.

Stsenaariumide koostamine etteantud lühikese kirjelduse põhjal oli üsna valutu protsess, gruppidele olid antud ka vabad käed oma nägemuse esitamiseks funktsionaalsusest. Jõudes järgmise suurema ülesandeni – sammude defineerimiseni – tekkis siinkirjutajal aga tungiv vajadus endast vähemalt kolm klooni spawnida, et jõuaks kõigile küsimustele vastuseid anda. Ka sellele ülesande osale lähenemine oli grupiti väga erinev – kes üritas sissejuhatuses antud näitest inspireerituna kirjutada enam-vähem puhast Ruby koodi, kes läks kohe pseudokoodi teed, kes miksis kokku nii üht kui teist. Raskustele vaatamata keegi ei kurtnud, tööd murti mehemoodi ning  eesmärk sai täidetud – defineeritud olid vähemalt ühe stsenaariumi sammud.

Päeva lõpuks planeeritud presentatsioonide käigus sai kogu meeskond vaatamata piiratud ajale – 15 minutit grupi kohta – päris põhjaliku ülevaate sellest, mida ja kuidas iga grupp midagi tegi. Selle faasi mitte vähem olulised eesmärgid olid ka näha, kui hästi juht oma gruppi päeva jooksul haldas ja grupiliikmete tegevusega kursis püsis, ning kas grupp suutis deliverdada ettenähtud tulemuse piiratud aja jooksul. Tuleb nentida, et suutsid küll ja väga hästi, nii grupid kui grupijuhid.

 

Mida kokkuvõtteks öelda?

Tuleb korrata eelmise treeningpäeva kokkuvõtte mõtet, et ettenägelik planeerimine on edu alus. Kuigi ilmselgelt viie grupi peale vaid üks inimene juhendaja rollis on liiga vähe ja ideaaljuhul peaks olema vähemalt kaks inimest, kes on käsitletava teemaga väga hästi kursis ja suudavad ka oma teadmisi edasi anda, püsis üritus vaatamata sellele üsna täpselt ettenähtud ajakavas.

Esmapilgul lihtsana näiv võib tegelikult ootamatult keeruline olla. Selline mõte jäi päeva kokkuvõtvas osas päris mitu korda kõlama ja eks ta nii olegi. Tarkvara arendamine BDD metoodikat kasutades on teoorias tõesti imelihtne, kuid inimesele, kes tarkvara arendamisega igapäevatööna ei tegele, on esimestest sammudest edasiminek juba paras pähkel. Keerulisusele vaatamata meeskond päid norgu ei lasknud ja see viib mind tegelikult päeva kõige olulisema järelduseni.

Meeskond on meil ikka kuradi pädev. Ilma igasuguse kahtluseta. Jaga inimesed gruppidesse, jaga kätte ülesanded teemal, millega valdaval enamusel neist igasugune kokkupuude sisuliselt puudub ja päeva lõpuks on lahendused olemas. Kiitus ja tänu kogu meeskonnale taaskord väga õnnestunud päeva eest!

Leave a Reply

Your email address will not be published. Required fields are marked *