Testijad ja arendajad – või ikkagi meeskond?

Käesoleva aasta juunis toimus Tallinnas teist korda rahvusvaheline Nordic Testing Days (NTD) 2013 konverents, mis keskendub testijate kultuuri arendamisele Eestis ja Põhjamaades.

NTD 2013 korraldus oli eelmisest korrast toekam ja fookus kaasaegne – loenguid ja töötubasid läbivaks teemaks oli Testers and Developers – Partners in Quality. Ilmselt oli lugu ka kuulaja valikutes, kuid kaks märksõna, mis loengutest ja töötubadest kummitama jäid, olid teamwork ja automation.

NTD 2013 koosnes kokku kolmest päevast. Esimene päev oli tutorial’ite päralt, teine ja kolmas aga olid tihedalt täis erinevaid ettekandeid ning töötube.

Proeksperdi panus NTD 2013 õnnestumisse

Automatiseerimise rõõmude ja murede lahkamine on ka Proeksperdi jaoks hingelähedane. Kui eelmisel aastal viisime Mati Parve eestvedamisel läbi ühe automatiseerimise teemalise töötoa, siis sel aastal oli meil kogemusi juba topelt jagada.

Continue reading “Testijad ja arendajad – või ikkagi meeskond?”

Raspberry Pi ja ETV järelvaatamine – Flashi-vaba tsoon.

See siin on lühijutt ühest progeja tüüpilisest õhtust, mis hõlmaks justnagu tervet elutsüklit: ideed, probleemi püstitust, kastist-väljas mõtlemist, tagasivaadet, lihtsustamist, lahendamist ja nautimist.

Häda ajab härja kaevu.

Omal ajal oli ütlemine, et Microsoft kirjutab iga IBMi poolt toodetud arvuti tarkvara kohe pilgeni täis. Siis on põhjust jälle uue ja võimsama soetamiseks, mida taas kord uue tarkvaraga üle koormata. Ja nii ongi see juba aastakümneid kestnud. Ikka ja jälle leian end seda lõbusat legendi meenutamast. Alles huljuti juhtus, kui minu valdusesse sattus üks Raspberry Pi. Mida selle peal esimesena katsetada? Eks ikka GPU võimsust – see ju selle riistapuu eeliseks. Naiivse lootuse – kuid realistliku pessimismiga – hakkasin proovima oma lemmikteenust: ETV salvestiste internetist järele vaatamist. Tulemus oli muidugi ette teada.

Kui juba kahetuumalised CISC protsessorid ei suuda flash player rakendust täisekraanil sujuvalt jooksutada, ei suuda seda ka 25 dollarit maksev RISC. Põhimõtteliselt ei jõudnud isegi nii kaugele, et oleks pildi ette saanud. Kuid kas asi ikka piirdub sellega? Kas peaksin selle teadmisega rahulduma? Üks õige progeja ei rahuldu – enne kui pole ise järgi kontrollinud.

Puude taga on siiski mets.

No mida erilist see flash player siis teeb? Selle teada saamiseks tuleb tänapäeval appi iga endast lugupidav veebilehitseja, kus on võimalik suvalise koha peal paremat hiireklahvi vajutada ja inspect element käsku valida. Vahekommentaariks niipalju, et olles viimased 7 aastat sardsüsteemide C++ progeja olnud, olen üllatunud, millise hüppe veebilehitsejad vahepeal on teinud. Igas brauseris on põhimõtteliselt kogu silumissüsteem (debug) sees. Võimalik on vaadata mitte ainult lehe algset lähtekoodi vaid kogu HTML/JavaScript hetkeseisu, jooksutada käsurealt enda lisatud JavaScripti, profileerida jne. Siiski, esmapilgul ei näe kohe puude taga metsa – kui ainult seda flashi ees ei oleks! Tuleb flashi-vaba tsooni peal hiirt vajutada ja natuke kaugemalgi ringi kolada. Lõpuks selgub, et kõik videod on standardsed RTMP meediavood: vaja ainult URL teada saada. Siit juba midagi koidab. Konstrueerime tervikliku URLi ja anname ette Raspberry Pi vaikemängijale (omxplayer), mis on kohandatud Pi riistvaralist kiirendust kasutama (siiamaani ainuke teadaolev). Ja voila! Nii ilusat, sujuvat, vaikset ja nii suurel ekraanil ETV järelvaatamist pole ma veel kogenud. No mis häda on neil kogu aeg seda fläšši teha!? Meenub vanakooli IT mees. Meil on tõesti vist loomupärane omadus kirjutada ka kõige lihtsamad operatsioonid kõige ressursinõudlikumaks.

Lihtsus on geniaalsus.

Esimene mõte on nüüd teha selle kasutamine võimalikult mugavaks. Aga kuidas? Meil on antud tuhandeid võimalusi, sadu teid, aga ma olen õnnelik, et inimesed on nii ilusad ja head. Peas hakkavad keerlema tuhanded erinevad ideed uuest rakendusest, mis võiks töötada Raspberry Pi peal, mis tõmbaks ERRi serverist uut infot ja kuvaks seda kenasti suurel ekraanil. ETV kodulehel ei paista aga olevat isegi RSSi, rääkimata veebiteenusest. Tõenäoliselt kasutavad ERRi mobiilirakendused mingit rätsepalahendust, aga see polegi enam oluline. Seda kontrollida ma ei viitsi, sest selle kõige tegemine võtaks liiga palju aega. Mõte veereb hoopis analüütiku ja disaineri köögipoolele. Ma istun kodus, diivani peal, läpakas süles ja kolan ringi ETV kodukal. Kasutan justnimelt läpakat, kuna televiisoriekraanilt ei ole mugav teksti lugeda – olgu ekraan kui suur tahes. Videoklippe tahaks aga telekast vaadata. Mõeldud, tehtud. Tuleb teha üks veebilehitseja pistikprogramm või lehitseja liivakast, mis leiaks kodulehelt automaatselt video aadressi üles ja saadaks selle minu Pi-le edasi. Nii poleks vaja kulutada aega uue täisfunktsionaalse programmi kirjutamiseks/hooldamiseks ja jätaks kasutajale alles võimaluse tarbida ETV kodulehe rikkalikku sisu. Seda rikkalikku sisu, mis tavaliselt mobiilidele mõeldud versioonides puudub.

Nüüd alles läheb tehniliseks.

Eesmärk pühendab abinõu. Tegin ühe lihtsa Chrome’i plug-ini, mis iga avaneva lehe pealt otsib Flow Playerit. Leides selle, parsib ta sealt välja video aadressi ja pakub saatmiseks edasi Raspberry’s asuvale väikesele Pythoni skriptile, mis omakorda juhib omxplayerit. Lõpptulemus on üllatavalt mugav – kuigi kahjuks ei tööta RTMP striimi peal veel edasikerimine kuna seda pole lihtsalt siiani kirjutatud. Vabavara-maailmas pidavat aga asjad ju lihtsalt käima – vaja ainult natuke patchida ja confida! Seega, ülesandeks number üks on leida lähtekood! Kloonida omale repo Githubistmountida Raspberry Weezy image – kompileerida omale üks cross-compiler – õppida FFmpeg librat – kirjutada mõned read koodi – konfigureerida, kompileerida… ja… no peaaegu töötab. Edasi kerib, aga mängimist ei jätka. Tuleb käsitsi pausi panna ja paus maha võtta.

Aga nii lõppeb see seiklusterohke hilisõhtu. Aeg saab otsa ja uus päev toob uued väljakutsed. Jäägu siis pealegi nii, et elus tuleb osata käsitsi pausi panna ja seda käsitsi ka maha võtta.

Asjast huvitatud võivad laadida omale praeguse versiooni kogu tehtud tööst siit: ETV Vaarikas.

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”

“Homse maailma kirjanikud”: laadi tasuta e-raamat siit

“On öö ja ma ei maga jälle. Oleks vale väita, et und ei tule. Ma ei lase tal tulla. Lammaste lugemisest loobusin aastaid tagasi, kui mõtlesin välja algoritmi iseõppiva pildituvastustarkvara jaoks, mis annab sulle pärast mõningaid katseid murdosasekundiga kätte lammaste koguhulga mis tahes suurusega kujutlusväljas.”

Kui Sul tekkis küsimus, et mis jutt see siis nüüd on, siis selgituseks, et tegemist on lõiguga Sass Henno romaanist Proeksperdi ajaloo ainetel. Paberkandjal saab raamatut õige pea poodidest, aga tasuta e-raamatu saad kohe praegu alla laadida siit:

pdf: http://people.proekspert.ee/blog/HMK.pdf

epub: http://people.proekspert.ee/blog/HMK.epub 

 

935555_519361078099309_2104989188_n

 

 

 

 

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”

Pro tiim hindab Robotexil koodi ilu

Robots will take over the world. W will be right behind them.

Kui sa tuled Robotexile ja plaanid seal robotit progeda, siis loe alljärgnevat erilise tähelepanuga, sest see aitab sul võita 500 eurose auhinna. Asi on selles, et Proekspert annab ka sel aastal Robotexil välja auhinna kõige ilusama koodi eest ja siin on mõned vihjed, mida me hindame.

Mis on ilus lähtekood?

Ilus lähtekood on selgesti mõistetav ja hõlpsasti loetav. Loomulikult võiks hakata rääkima siin igasugustest tekstifaili küljendamise võimalustest: taanetest ja tühikutest kuni tühjade ridadeni ja kommentaaride stiilideni välja. Aga kuna me ei dikteeri Robotexi osalistele mingit konkreetset keelt, arendusvahendit ega platvormi, siis jääb ka koodi stiil nende enda valikuks. Küll aga hindame me stiili ühtsust (taane käib kas tühikutega või tabidega, sa ei saa neid vaheldumisi kasutada — või vähemalt ei peaks seda tegema, kui tahad kirjutada koodi, mis on arusaadav ka homme). Sarnaselt peab ka koodi blokke läbiva stiiliga esitama. Muutajate ja meetodite nimed on ilusas koodis alati arusaadavad ja sisu kirjeldavad. Kindlasti ei tohi need olla eksitavalt nimetatud.

Miks me seda hindame?

Jah tõesti? Miks ME (Proekspert) seda hindame? Tegelikult peaks iga Robotexil osalev tiim seda ise juba hinnata oskama. Teisest küljest mäletan ma oma tudengipõlve ja Robotexi kogemusest, et alati jääb üks öö puudu. See aga omakorda tähendab, et hakatakse _kiiruga_ lisama elutähtsat funktsionaalsust, mis pahatihti tuleb muude aspektide (koodi ilu/loetavuse) arvelt. Meie auhind on siinkohal lisaks vaimsele rahuldusele väikeseks lisamotivaatoriks, et koodi ilu mitte ohvriks tuua.

Kuna robotid, või peene välismaise nimega tööstusautomaatika on üks Proeksperdi peamisi tegevusalasid, siis arvame, et robotiprogemispraktikutena ja koodi ilu pühaks pidava ettevõttena saame oma kogemusi teiega jagada.

Miks keegi üldse peaks tahtma oma koodi meile näidata?

Ideaalses maailmas tahavad kõik tudengid oma koodi teistele näidata. Kas selleks, et saada tunnustatud õigeaegselt ja iseseisvalt sooritatud ülesande eest või selleks, et saada väärtuslikku nõuannet mõne ülesande optimeerimiseks või siis võistlemaks teise tudengiga, et näha, kelle kood käib kiiremini. Aga päriselus, kus on päris tähtaeg ja päriselt saavad (t)öötunnid otsa enne, kui võistlus pihta hakkab, on kood tihtipeale sama korras kui tudengi /homework folder (või kirjutuslaud) keset sessi.

Selleks, et Robotexil osalejaid ikkagi motiveerida meile oma koodi näitama (ning taluma meie žürii Priit P. ja Lauri V. piinlike küsimusi), on Proekspert välja pannud ka 500 eurolise auhinna kauneima koodiga tiimile. Kohtume peagi Robotexil ja seal ronime me juba teie robotite ajudesse!

Specification by Example by Gojko Adzic

Specification by Example seminar Proeksperdis

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”

Töökas nädalavahetus Rails Girlsil ehk naised programmeerima!

Jahedad ja vihmased sügisilmad lihtsalt on tubaseid tegemisi soodustavad ja kui üks hetk avastasin, et Rails Girls Tallinna septembrikuu workshopile registeerimine on avatud, siis oli asi otsustatud. Olen koolis paar põgusat programmeerimisteemalist kursust küll läbi teinud, kuid oma igapäevases kvaliteediinseneri töös koodi kirjutamisega siiski ei tegele. Ettevõttesiseselt on aga käimas raamatukogu arendus just Ruby on Railsi kasutades ja nii süveneski idee lasta end sel teemal natuke harida.

Igatahes Rails Girlsi näol on tegemist rahvusvahelise mittetulundusliku õpitoaga, mis on kõikidele huvilistele tasuta. Ahjaa, üks väike aga on ainult – osalejateks on vaid naised või kui ikka väga hästi läheb, siis lubatakse ka mõni mees uksest sisse. Muidugi ainult juhul, kui ta eriti ägeda ja tegija naise kaasa toob. Seekord vist keegi selle trikiga hakkama ei saanudki. Nagu tasuta asjade puhul ikka on ka Rails Girlsi workshopile tunglejate hulk alati suur (see aasta koguni 125 naist ning 2 meest) ja silmapaistmiseks tuleb ära täita paarist-kolmest küsimusest koosnev ankeet. See on võimalus demonstreerida oma suurepärasid ilukirjanduslikke võimeid ja korraldajaid võluda. Kusjuures kui “motivatsioonikiri” on atraktiivselt kirja pandud, siis tundub, et mida vähem programmeerimisest teada, seda suurema tõenäosusega ka Rails Girlsi üritusele kutse saab. Paar kevadel toimunud workshopilt välja jäänud neiut soovitasid oma kogemustest õppida ning oma koodi kirjutamise oskuste kohapealt enesekiitusega tagasi hoida. Just sel põhjusel sai oma ankeeti kirja pandud, et ei ole koodi näinud ja ei ole koodi teinud.

 

Mis see Rails Girls ikkagi on?

Rails Girls on 2010. aasta novembris Helsingist alguse saanud üritus, mida organiseerivad vabatahtlikud Ruby huvilised. Selgitusena olgu öeldud, et Ruby on programmeerimiskeel Jaapanist ning Rails veebiarenduse raamistik, mis siis Rubyt kasutab. Continue reading “Töökas nädalavahetus Rails Girlsil ehk naised programmeerima!”