Agile – Hello World

Kuidas testide automatiseerimisel õnnestuda

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”

Automatiseerimisest tarkvaraarenduses

Tarkvara arendamisel ettetulevate korduvate protsesside automatiseerimise väärtuses kahtlevad vist üsna vähesed kogenud arendajad ja projektijuhid. Tegelikus elus aga paraku ei ole automatiseerimine kõige prioriteetsem. Sellest võibolla räägitakse projekti alguses, aga töö käigus jääb see tihti unarusse.

Iga arendaja või testija, kes nüri järjekindlusega ühe ja sama toimingu sooritamise asemel eelistab midagi kasulikku oma projekti jaoks teha, peaks tundma automatiseerimise põhimõtteid. Projektijuht, kes teab meeskonna oskuste ja aja efektiivse kasutamise eeliseid ja ei soovi riskida projekti ebaõnnestumisega, peaks oma meeskonda julgustama leidmaks aega ja võimalusi automatiseerimise rakendamiseks.

Continue reading “Automatiseerimisest tarkvaraarenduses”

Impact mapping

See postitus on ühest küljest kokkuvõte 23. novembril Londonis toimunud konverentsi Agile Testing and BDD eXchange 2012 keynotest, kus Gojko Adzic ning Dan North rääkisid metoodikast nimega impact mapping, teisalt on tegu ülevaatega raamatust Impact Mapping: Making a Big Impact with Software Products and Projects, illustreerivad joonised on laenatud siit.

Mis on impact mapping?

Impact mapping ehk mõjude kaardistamine on strateegiline planeerimismeetod, mis annab meeskonnale vahendid nõuete selgeks kommunikeerimiseks, aitab neil oma tegevusi ärieesmärkidega ühildada ja teha paremaid otsuseid. Selle meetodi kasutusala ei ole piiratud tarkvaraarendusega, samamoodi saab seda rakendada ka näiteks protsesside jms planeerimisel.

Continue reading “Impact mapping”

Specification by Example by Gojko Adzic

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”

Acceptance Testing: RSpec vs Cucumber

Levinumad acceptance testide loomise vahendid Behavior-Driven Development metoodikas on RSpec (Ruby jaoks) ja Cucumber (universaalsem). Olles mõlemat mõnevõrra pruukinud, tekkis küsimus, et kumb siis on lõpuks acceptance testimiseks parem. BDD põhitõdesid ei hakkaks ehk siinkohal kordama, vaataks hoopis Cucumberis ja RSpec’is testide kirjutamist hüpoteetilise Rubys kirjutatud veebirakenduse jaoks.

Mõlemad tööriistad kasutavad brauseri käitamiseks Capybara-nimelist veebirakenduste testimise raamistikku. RSpec’i ja Cucumberi erinevus seisneb peamiselt testi loetavuses ning kirjelduse nö. tasemes. Lihtne näide esmalt Cucumberi stsenaariumina:

Feature: Blog articles
  In order to have an awesome blog
  As an author
  I want to create and manage articles

  Scenario: Article index
    Given there are 2 articles
    When I go to the articles page
    Then I should see the following articles:
    | Article title |
    | Article one   |
    | Article two   |

Iga sammu tähenduse Cucumberile arusaadavaks tegemiseks tuleb need defineerida:

Given /there are (.*) articles/ do |number|
  number.times { |n| Article.create! }
end

Nagu näha, kasutab Cucumber testide kirjeldamiseks loomulikku keelt ja seetõttu on sellised testid väga hästi loetavad, samuti aitab kõrgema taseme funktsionaalsusele keskendumine kergemini vastata küsimusele “Mida meie rakendus õigupoolest tegema pidi?“. Teisalt on antud juhul vajalik kirjutada ka sammudefinitsioonid, et Cucumber teaks, mida meie loomulikus keeles kirjeldatud stsenaariumitega peale hakata, seega tekib testidesse üks lisakiht, mis samuti vajab ülalpidamist.

Continue reading “Acceptance Testing: RSpec vs Cucumber”

Kuidas automatiseerida veebiteenuse testimist üle SOAP protokolli

Proeksperdi plaan on testide laialdane automatiseerimine. Esimeseks katsetuseks sai telekommunikatsiooni projekt, kus iseteeninduse veebileht suhtleb teenuste serveriga ja infovahetus toimub vana hea SOAP protokolli abil. Regressiooni käigus tuleb testida, kas teenused käituvad õigesti ja seda saab teha käsitsi iseteeninduse lehte kasutades. Lühidalt öeldes: serverile on vaja saata HTTP päringuid ja veenduda, et tagasi tuleva paketi sees on õige info. Säherdune ülesanne tundub jõukohane just arvutile meie eest ära teha.

SOAP – Simple Object Access Protocol on tuntud asi, aga kohe kuulsin lisaks, et nii “lihtne” see ka ei ole. SOAPiga käib kaasas WSDL (Web Services Description Language) kirjeldus, mis on antud teenuse kirjeldus veebilehel. Sellest saab teada, mis funktsioone teenuselt kutsuda saab, mis argumente tahetakse, milline objekt tagastatakse ja mida objektid sisaldavad. Õnneks on asi nii standardne, et on olemas erinevates keeltes library’d, mis funktsioonide ja klasside genereerimise automaatselt ära teevad, ega ole vaja ise WSDLi dešifreerida. Tulemuseks on PROXY, mis võimaldab funktsioonide näol veebiserverile päringuid saata ja mingeid XMLi ega HTTP päringuid pole üldse vaja näppida.

1. päev – PERL

Automatiseerimise üks eesmärk on asjad võimalikult lihtsana hoida. Kuna olin sellega veidi kokku puutunud, sai esimeseks valikuks PERL. Otsimise peale selgus, et on kaks pakki Continue reading “Kuidas automatiseerida veebiteenuse testimist üle SOAP protokolli”

“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:

Iga stsenaariumi jaoks, mis kirjeldab mingit funktsionaalsust

käivita stsenaarium – tulemuseks on FAIL

defineeri esimene samm – ka selle tulemus on FAIL

kirjuta rakenduse koodi täpselt niipalju, et sammu tulemus oleks PASS

refaktoori kirjutatud kood ja korda samme 4 & 5 iga stsenaariumi sammuga kuni…

…kogu stsenaariumi tulemus on PASS

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”

Behavior Driven Development ja Cucumber ehk ilusam tarkvara valutu(ma)lt

Sissejuhatuse asemel

Kõik sai alguse sellest, kui ühel ilusal päeval rändasin Suurbritanniasse ja sattusin poolkogemata tööle pisikesse startupi nimega Picklive. Seal kasutati minu jaoks tol hetkel (ja tänaseni) väga uudseid ja põnevaid vahendeid lisaks juba tuntud asjadele – Ruby on Rails, XMPP, JavaScript, agiilne metoodika jne. Alustasin ka seal tegelikult testimisest, aga üsna pea selgus, et sellest jääb väheks. Seega asusin tasapisi ka parandama vigu, mis leidsin. Märkamatult kirjutasin juba lisaks päris uut funktsionaalsust.

Mis tegelikult mu mõtteviisi tarkvara arendamise ja testimise kohta muutis, oli hetk, kui otsustasime võtta kasutusele Behavior-Driven Development (BDD) metoodika ning selle elluviimise vahendiks sai valitud Cucumber. Kuigi BDD’d saab defineerida mitmeti, on minu arust pädevaim Dan North’i antud kirjeldus:

BDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.

BDD definitsiooni järgi tekib tarkvara väljast sisse – esmalt defineeritakse tulemus, mida soovime saavutada, seejärel kirjeldatakse käitumine, mis meid soovitud tulemuseni viib ja alles siis kirjutatakse tegelik programmikood, mis teeb seda, mida me tahame, et ta teeks. Tulemuse definitsioon ja käitumise kirjeldused on esitatud inimloetava tekstina.

Continue reading “Behavior Driven Development ja Cucumber ehk ilusam tarkvara valutu(ma)lt”

Do you know RapidBoard?

Mõtlesin et jagan teiega tööriista, mis on Atlassiani Greenhopperis veidi aega tagasi (versioonis 5.9) “kasutatavaks” muutunud.

Ükskõik mida scrumipuristid väidavad, reaalsuses on meeskonnal sageli samaaegselt käimas mitu projekti. Need on reeglina erinevad tooted, mida arendatakse paralleelselt ja mille kõigiga on seotud sama grupp inimesi. Nende prioriteete seatakse ühiselt ning sageli peavad need tooted koos toimima ning kasutama samu reliisitsükkleid. Senini polnud Jiras/Greenhopperis niisuguste projektide taskide ühiseks planeerimiseks ja vaatlemiseks mugavat võimalust. Selle tulemusena kippus sprintide skoop minu kogemusel ähmastuma ja pidev projektide vahetamine planeerimisel tekitas osalejais segadust. Sprindi käigus proovisime seda probleemi lahendada eraldi projektideülese füüsilise scrumboardiga, aga selle haldamine oli üsna ebamugav (kuigi hi-level füüsilist scrumboardi kasutame siiani).
Continue reading “Do you know RapidBoard?”

Proeksperdi testijate treeningpäevast, common sense’st ja testianalüüsist

Väljas on veel parasjagu külm. Mitte küll nii pakasene, kui veebruari alguses, aga siiski miinuskraadid. Seega viimane aeg kirjutada, kuidas me kuu aja eest Proeksperdi Testimise Treeninglaagri korraldasime. Alguses sai arvatud, et tegu saab olema ühe off-site päevaga, kuid ettevalmistuse käigus sai sellest kokku korralik boot camp.

Miks me nii tegime?

Põhjused on lihtsad – kommunikatsioon ning kogemuste vahetamine. Proeksperdi Kvaliteediarenduse meeskonnas (Quality Engineering Team, edaspidi QE tiim) töötab kirjutamise hetkel 20 inimest. Üks tiimi juht, teine tehniline kirjutaja ja kõik ülejäänud kvaliteediinsenerid (QA Engineer), igapäevatöises kõnepruugis tuntud ka kui testijad. Pea kõik kvaliteediinsenerid töötavad omaette tarkvaraarenduse projektimeeskondade juures ehk siis kõik QE tiimi liikmed on hajutatud laiali üle terve Proeksperdi. Mõned neist suisa teistes majades kliendikeskkonnas.

Continue reading “Proeksperdi testijate treeningpäevast, common sense’st ja testianalüüsist”