Category: QA

Testide automatiseerimine on alati kahe otsaga asi, võimaldades küll testijate igapäevatööd kergendada, kuid sama kergesti võib sellega hoopis probleeme juurde luua. Kuidas toimida, et õnnestuda? Automaattestide juurutamisel võib ette tulla mitmeid probleeme, mõned tüüpilisemad komistuskivid:

 

• Automatiseerimine vabal hetkel. Automaattestide loomisega tegeletakse siis, kui selleks on aega – projekti töös tekkivate “aukude” täiteks, omast ajast jne. Puudub vajalik pühendumus.
• Puudulikud eesmärgid. Milleks me üldse automaattestidega vaeva näeme? Aja säästmiseks, testimise lihtsustamiseks, testide katvuse parandamiseks? Testijate motiveerimiseks? Kõike korraga tõenäoliselt ei ole võimalik saavutada, inimeste eesmärgid on erinevad ja kui neid selgelt välja pole öeldud, on lihtne feilida.
• Kogemus. Õigemini selle vähesus või puudumine. Automaattestid võivad kergelt muutuda haldamatuks džungliks, kui neid arendavate inimeste teadmised tarkvaraarenduse põhitõdedest on puudulikud.
• Inimesed vahetuvad. Automatiseerimise õppimine võtab aega ja kui meeskonnaliikmed tihti vahetuvad, kaob ka omandatud kogemus.
• Tahtmatus testida. Paljude inimeste jaoks on automatiseerimise protsess huvitavam, kui tarkvara testimine. Automatiseerimine võib muutuda mugavaks vabanduseks, miks testimisele vähem pühenduda. Sellisel juhul ei ole ka automatiseerimise väljund testimise seisukohalt tihti suurem asi.
• Tehnilised üksikasjad. Kuidas tarkvara automatiseerida, on tehniliselt huvitav ülesanne, kuid liigne keskendumine tehnilistele probleemidele võib tähendada vajadustele üldse mitte vastavat tulemust.

 

Continue reading “Kuidas testide automatiseerimisel õnnestuda”

1. novembril toimus Proeksperdis inspireeriva Gojko Adzic-i poolt läbi viidud seminar Winning big with Specification by Example (SBE). SBE on oma olemuselt kollaboratiivne lähenemine nõuete defineerimisele – fookus on kommunikatsioonil ja reaalsetel näidetel, et kõigil osapooltel tekiks ühine arusaam loodava süsteemi funktsionaalsusest. Positiivse lisana muutuvad SBE “õigel” rakendamisel nõuded ka automaatselt valideeritavateks – teatud tööriistade abil saab kõigile loetavas formaadis kirja pandud nõuded automaat-testideks muuta.

  Continue reading “Specification by Example by Gojko Adzic”

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

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