Vaade minevikku ja pilk tulevikku ehk Üldkoosolek

2. juuni õhtul toimus Eesti Testijate Liidu (ETL) Üldkoosolek. Eriliseks tegi koosoleku see, et esimest korda toimus koosolek kahes linnas korraga: Tartu liikmed olid ühenduses üle Skype!

Esimeses (ametlikus) pooles analüüsiti eelmise aasta tegevusi - seminarid, Testijate Päev, eksamite korraldamine, vaadati üle ja kinnitati majandusaasta aruanne. Edasi arutati 2011/12 tegemisi. Põhiline sündmus, milleks algavad ettevalmistused on 2012 juunis toimuv testimisalane konverents. Konverentsiga samal ajal organiseeritakse Tallinnas ka ISTQB üldkoosolek. 2011 plaanides on seminaridega jätkamine Tallinnas ja alustamine Tartus, külaskäigud liikmete tööandjate juurde ning kindlasti veel mõni huvitav reis mõnda naaberriiki tutvumaks testimisega tegelevate ettevõtetega. Kuna ETL on kasvanud juba päris suureks, siis valiti nõukogu (Raivo, Raimond, Risko, Urmo, Arvi), kes hakkab ergutama juhatust (Maili, Kaspar, Harles).

Peale ametlike otsuste tegemist liiguti edasi söögikohta Rucola, kus pitsasid testides mõtiskleti kuidas tegevust aktiviseerida ning liikmetele huvitavat tegevust pakkuda. Oli tore õhtu! Tuleb tore aasta! Aitähh kõigile osalejatele ja neile kes seekord osaleda ei saanud!

Saabusid czechtest 2011 materjalid

See päev on nüüd käes! Kõik huvilised, kes tunnevad huvi teemade vastu, mida czechtest 2011 käsitleti, saavad nüüd neile pilgu peale visata. Materjalid laadisin üles googledocs-i, kel huvi saatke mulle kiri ja annan teile ligipääsuõigused. Programmi kava on kättesaadav siin. Mõned esitlused on veel puudu aga korraldajate info kohaselt pidid ka need lähiajal kättesaadavaks tehtama. Ja kindlasti on oodatud tagasiside siia blogisse arvamuste ja soovituste näol!

Mis vahet on teoorial ja praktikal?

Eelmises blogis tegin ülevaate Tšehhi testimiskonverentsil saadud teadmistest. See oli teooria. Esmaspäeva õhtuks oli Kristjan Uba organiseerinud väikese testimisürituse, kus mina ja Ervin saime ülesandeks oma kompetentsust ühe pisikese programmi testimisel üles näidata. See oli praktika.

Ei jäänud oma testimisega rahule, ei jäänud. Vead, mis programmi olid sisse ehitatud, oleks pidanud tükk maad kiiremini kätte saama. Koju sõites analüüsisin, milles probleem oli. Vastus (piinlik tunnistada) oli lihtne - uisapäisa tegutsemine. Miks küll on nii, et kui on mõni suur projekt, siis mõtleme enne läbi, mida teha vaja on, aga kui on tegemist näiliselt lihtsa ülesandega, siis unustame planeerimise ära ja anname tuld? Ja saame kõrvetada.

Kui oleksin omandatud teooriat järginud, oleksin alustuseks vastanud küsimustele nagu:

Mis on mu testimise eesmärk?

Missugune on testimise plaan?

Mis riske ma püüan testimisega maandada?

Missugune on süsteemi arhitektuur, selle nõrgad kohad?

Mis vahendid võiksid testimisel kasuks olla?

Mis on testiideed?

Aga ma ei teinud seda. Kui oleks, oleks praktiline pool kindlasti paremini välja tulnud. Mida öelda kokkuvõtteks? Teooria on oluline. Ja Praktika on oluline. Üks ilma teiseta ei saa. Peame omandama teoreetilisi teadmisi ja siis neid praktikas rakendama. Omandama kogemusi, siis tuleb kompetentsus.

Aitähh Kristjanile ja Ervinile meeldiva õhtupooliku eest. Sain kindluse selles osas, et lisaks seminaridele, mis siiani on enamuses teoreetilisi teadmisi andnud, on vaja ka praktilisi, kus üheskoos testimisülesandeid lahendame. Võtan härja sarvist kinni ja organiseerin aprillis ära. Kui kellelgi on häid ideid, mida testida, võite julgelt teada anda!

Testimiskonverents Tšehhis - Osaletud!

Läinud kolmapäeval seadsin sammud Tallinna lennujaama, et põgeneda mõneks päevaks kevadisse Prahasse, kus toimus iga-aastane testimisalane konverents czech test. Kus tegijaid seal nägijaid - lennujaamas kohtasin Raimondit, kes lubas mulle valusalt varba peale astuda, kui ma konverentsist pisikest kokkuvõtet ei kirjuta. Mis mul siis üle jäi, kui lubadus anda ja ära teha :). Järgnevalt leiate lühikokkuvõtte kuuldust - nähtust. Lähiajal riputan ülesse ka slaidid, kust juba detailsema ülevaate leida võib.

Czech Test oli kahepäevane konverents, millele eelnes üks päev praktilisi seminare. Ise osalesin ainult viimasel päeval ja õhtul oli kahju küll, et seminaridel ja konverentsi esimesel päeval osaleda ei saanud - tase oli väga hea. Tuntumad esinejad olid Lloyd Roden, Erik van Veenendaal ja Graham Thomas. Põhjalikumalt käsitleti konverentsil selliseid valdkondi nagu testijuhtimine, testidisaini tehnikad, agiilne testimine ja testide automatiseerimine.

Järgnevalt muljed ettekannetest, mida kuulasin:

Testing, so many problems but we have solutions don't we?

Tegijal juhtub. Aga kas sa õpid vigadest ja teed järgmine kord paremini? Halb on see, kui oleme laisad ja astume korduvalt samasse ämbrisse. Mitu testimisalast raamatut sul on? Kui tihti sa loed neid? Kas sul on testimisel eesmärgid? Plaan? Kas sulandud arendustiimiga? Need on mõned küsimused, mida peab endalt pidevalt küsima, et mitte arengus seisma jääda ja kvaliteetset tulemust toota.

Top 10 challenges in Aerospace software testing

Projektides osalevad sajad partnerid, kõike ei ole võimalik testida, vead võivad lõppeda surmaga, projektid kestavad > 10 aastat, selle käigus muutuvad pidevalt nõuded, ... - kas ei ole mitte tore? Kuidas sellega toime tulla? Slaididel on märksõnad, millele tähelepanu pöörata ilusti olemas.

Risk-based Testing in Practice

Lihtne ülevaade, kuidas riskipõhist testimist läbi viia. Oluline seejuures on riski mõju ja tõenäosust mitte korrutada vaid kasutada maatriksit (väikse tõenäosuse, kuid suurema mõjuga viga on hullem kui suure tõenäosusega juhtuv, kuid väiksema mõjuga viga. Kas pole?). Kuidas võiksid testiplaan ja -aruanne välja näha? Lihtsad ja kliendile arusaadavad!

A Hitch-Hikers Guide to the Software Testing Galaxy

Don't Panic! Vaata film uuesti läbi või loe raamatut. IPad, Galaxy Tab ja wikipedia on juba ammu leiutatud - peab ainult veidi mõtlema, kuidas neid vahendeid igapäevases töös informatsiooni ja teadmiste hankimiseks/jagamiseks kasutada.

"Test automation trilogy"

Automatiseerimine on hea, aga mis ohud meid valitsevad? Kuidas neid vältida? Testide automatiseerimine on arendusprojekt ja sellele kehtivad kõik arendusprojekti reeglid. Testija töö on ikka testimine, mitte vahendi haldamine. Peab vaatama, et need kaks ülesannet üksteist segama ei hakkaks.

Testide automatiseerimine ei ole ainult vahendi juurutamine - oluline on määratleda eesmärk, paika panna strateegia, pöörata tähelepanu testiandmetele, keskkondadele ja konfiguratsioonihaldusele. Samuti ei tohi unustada kasumlikkuse analüüsi - kuidas täpselt automatiseerimine aitab meil tõhusamalt tööd teha? Ja loomulikult pidev tagasiside vastamaks küsimusele - kas me liigume eesmärkide saavutamise suunas?

Kokkuvõttes: Tegemist oli väga sisuka ja hästi korraldatud üritusega. Esinejate kvaliteedilt ei jäänud üritus kindlasti alla suurele vennale EuroSTAR-le ja võttes arvesse hinda, võin öelda, et tulu/kulu suhe oli väga hea! Tasub silmad lahti hoida nii selle kui järgmiste sarnaste ürituste osas. Näiteks 26. mai Riias lõunanaabrite korraldatud Theory and Practice of Software Testing.

Seminar: testimise automatiseerimine Seleniumiga

27. aprillil toimus Testijate Päeva järelseminar teemal "Testimise automatiseerimine kasutades Seleniumi". Temaatilised ettekanded olid Aqriselt ning Conformiq'lt ning vahepalaks vesteldi vabas vormis osalejaid huvitavatel teemadel. Järgnevalt lühike kokkuvõte sellest, mida räägiti ehk kokkuvõte arutletud teemadest:

Kuidas salvestada ja hallata ekraanipilte? (2 häält)
Seleniumil endal on täiesti standardsed vahendid ekraanipildi loomiseks. Üks variant on lehe source htmli maha salvestamine ja publitseerimine.
Kuid seleniumil on ka meetodid nagu captureEntirePageScreenshot (lehe põhine, töötab ainult Firefoxis) ja captureScreenshot (Operatsioonisüsteemi põhine).

Who write selenium tests? If developer writes Selenium tests, what tester does? (2 häält)
RIK arvab, et arendajad ei tohiks Seleniumi teste kirjutada, kuna nad on oma koodis kinni ja vigu tuvastavaid teste nad ei leia.
Aqris: kui testcase-d on ette kirjutatud siis võiks arendajad neid kirjutada ja testijad saaksid neid teste täiendada või leida programmis olulisemaid vigu.
Conformiq: testid tuleks disainida mudeli põhiselt. Mudeli peaksid tegema arendajad ja testijad koos.

Kuidas otsustada, mida ja kui palju tasub automatiseerida? (2 häält)
Agiilses arenduses: kõrge prioriteediga acceptance testid (prioriteedi ütleb klient, äripool)

Tavaline arendus, jätkuprojekt: salvestada staatilised testid ja need taaskäivitada. Stabiilsed võtta testidena sisse.


Kuidas paremini organiseerida/üles ehitada testide struktuuri? (3 häält)
Testide loomisel tuleb kasutada helperklasse, tegelikud testide väljakutsed on lühikesed, kogu töö tehakse helperklassides. Koodi haldamine on siin oluline.
Testide loomisel on variant kasutada ka PageObjects metoodikat (http://code.google.com/p/selenium/wiki/PageObjects).
Testide struktureerimiseks võib kasutada ka raporteerimise vahendeid. Näiteks kasutada Java-s koodi annoteerimist ja selle läbi ette anda nii testi andmeid kui ka defineerida testi eel- ja järeltegevusi. TestNG võimaldab sellist lähenemist.


Millises agiilse arenduse etapis tasuks hakata teste automatiseerima? (4 häält)
Sõltub projektist ressurssidest. Kui klient nõuab siis muidugi tuleb igal juhul kirjutada.

Kui järgida test-driven developmenti siis tuleks testid kirjutada juba prototüüpimise faasi (kui see faas on olemas). Kui prototüüpimist ei toimu, siis tuleb ikkagi oodata kuni on valmis vähegi stabiilsem keskkond.

Kui prototüüpimist ei ole siis võiks eesmärk olla: ASAP (as soon as possible), reaalsuses tuleb aga kuskil sprintide vahepeal, kui keskkond on natuke stabiliseerunud.
Andres: kui sprintide käigus tehakse kräppi koodi siis ei ole mõtet teste kirjutada.

Toodi välja probleem: kui automatiseerida teste sprintide lõikes siis läheb asi käest, ei jõua enam. Testide arendamise tuleb ka aega varuda ja planeerida sprindi sees.
Probleemiks: on ka testide muutmine, võib minna aina aja kulukamaks. (Tuleks üle vaadata testide disain?)

Idee: testijad võiksid arendajatega koos paika panna elementide id-d. Nii saaks testija juba varakult kokkulepitud id-dega hakata teste kirjutama.


Testi raportid (11 häält)
How to create human-readable test report? (5 häält)
Milliseid vahendeid paremini kasutada Seleniumi testraportite loomiseks? (3 häält)
Testide astmelisus (testcase, test, testsuite) (3 häält)

Vahendid, mida kasutatakse raporteerimiseks:
EMT - kostümeeritud testng, mis võimaldab luua veebipõhiseid raporteid. Lisaks võimaldab vahend komplekteerida test suite ja testide järjestusi. TestNG-ga saab realiseerida ka data-driven testimist ehk kui testis assert ebaõnnestub siis võetakse testi andmete failist uus test koos testandmetega.

RIK
kasutab isetehtud framework, mis töötab anti peal. Ant võtab sisse testsuite-i ja genereerib custom xslt template alusel vajaliku arusaadava raporti.
Mõned mõtted siia frameworki juurde:

• testsuite, testcase (1 class file per testcase), tests - selline peaks olema tegelik struktuur, testide astmelisus
• Vaikimisi on nii: testsuite, tests, testcases
• Tuleks hallata ainult testide struktuuri (testid ise on viidud helper klassidesse) – nii oleksid testide koostamine justkui legomäng, kus vajalikud tegevused pannakse kokku eri klotsidega ja edaspidiselt on vaja mitme või mitmekümne testi haldamiseks muuta vaid üht/mõnd klotsi - kui miski testitavas süsteemis peaks muutuma.
• Kui testimiseks on kasutatav vaid IE siis peab kahjuks iga testija oma valgete kätega kõikide elementide ID´d ise sisestama (kas siis otse testi või helper klassidesse - olenevalt testija testsüsteemi keerukusest)
• Iga test loob oma algandmed käivitamata eeltingimuste täitmisel kontrolle - igal klotsil on vastav väli, mis ütleb kas on tarvis selle klotsi puhul teha ka kõik kontrollid või tuleb eeltingimustena selle klotsi tegevused teha ilma põhjalike kontrollideta, lisaks toimub testi jooksmisel kontrolltingimuste ja eestikeelsete veateadete kogumine, kontrollid viiakse läbi alles testi lõpus, siis kui kõik tegevused on tehtud, testide kontrolltingimused on seotud ID´dega (mitte elementide ID´d vaid kontrollidel on oma ID´d mida saab testdokumentatsiooni lihtsalt nummerdada))

Ruby ja Rspec:
Rspec suudab genereerida vaikimisi juba väga häid raporteid. Raportites on vaikimisi vea korral olemas lehe html source, screenshot, diff ja kui testi käigus salvestati mingi fail siis ka see on testi juures kätte saadav.

Lauda jäänud küsimused/probleemid

• Selenium ja threadid
• Kiiruse probleemid
• IE salvestaja (nagu on Firefoxil)?
• Seleniumi crashi mure (ei lasta sessiooni kinni)
• Paroolide salvestus faili ning nende lugemine
• Mingid characterid on sisestamatud/trükitamatud
• Selenium startup akna mõõdustamine (FIXED-SIZE)
• Millised on levinumad probleemid, mis on ette tulnud? Kuidas neid lahendati? Kas on teadaolevaid lahendamata probleeme seotud Seleniumiga?
• Kas Seleniumiga saab mõõta CPU ja mälu kasutust? Kas saab ette kirjutada veebilehel navigeerimise stsenaariumi?
• Kuidas võiks olla testimise protsess üles ehitatud automatiseeritud testimise korral? Millest võiks alustada?
• Kuidas kõige paremini disainida testide kogum (testsuite)? (töömaht ja selgus loomisel ning muutmised oleksid minimaalsed)
• Millised võivad olla põhjused, et test kord jookseb läbi ja siis jälle annab vea?
• Mis vahe on FFPluginil (IDE) ja RC vahel? (funktsionaalsus, näiteks kui ma tahan testida ainult FF browseris)
• Faster test runs
  
• Kuidas on äripool (klient) rahul automaatsete testide koostamise kohustusega ning kuidas nad hakkama saavad (Kui tihti satuvad probleemide otsa)?

Vaata ette, EuroSTAR! Eesti Testijate Päev kogub tuure

Kui järgmiseks telehitiks saaks "Eesti otsib Supertestijat", siis esikolmiku oleks kindlasti leidnud naljakuu esimesel neljapäeval (01.04) toimunud Eesti Testijate Päevalt. See kujutas endast konverentsilaadset üritust, kus testimise eri valdkondade spetsialistid andsid ülevaate oma praktilistest töödest ja tegemistest.

Nagu telehitile kohane, oli saal täis noori fänne, kes ühelegi teemale tormilist kiitust avaldamata ei jätnud. Minu suurima aplausi pälvisid kaks esitlust:
• turvatestimine (Mait Peekma) ja
• veebipõhiste rakenduste automaatne testimine Seleniumiga (Raimond Sinivee).
Kes soovib teada ülejäänud teemasid, võib heita pilgu siia.

Mis siis pani mul kui korraldajal silma särama? Loomulikult oli väga meeldiv näha Swedbanki söökla külastajaid hämmeldunud nägudega vaatamas kohvitassidega ringi sebivaid ja innukalt vestlevaid testijaid. Vaheaegadel istusid igas võimalikus nurgas koos Eesti eri paigust kohale tulnud testijad, vahetades elavalt muljeid ja kogemusi.
Kindlasti ei saa mainimata jätta meie staaridest esinejaid, kes suutsid muidu tuimades eestlastes esile kutsuda rõõmsaid naerupahvakuid ja nad samas ka mõtlemapanevaid küsimusi esitama panna.

Kuigi meil puudusid kohtunikest Heidy Purga, Rein Rannap ja Mihkel Raud, avaneb kõigil osalejatel peagi võimalus oma hinnang anda, kui nende postkasti potsatab tagasisideküsitlus.

Quo vadis, Eesti Testijate Päev? Kas varasügisel tuleb uus üritus või peab aasta-paar ootama? Mina seda küsimust ei esitaks, vaid toetaksin nii käte kui ka vaimuga juba järgmise testijate päeva korraldamist!

Mis muud mul veel öelda oleks? Eks ikka suured tänud kõigile osalejatele, sügav kummardus meie säravatele esinejatele ning loomulikult kestev ovatsioon ürituse korraldajale – minule :D!

Eesti testijate Päev!

Teil on hea meel edastada ETL-i nimel kõigile blogi lugejatele ja ametivendadele kutse osalemaks ETL-i korraldataval Testijate Päeval, mis toimub 01.04.2010 Tallinnas, Pärnu mnt. 139/ Kohila 8 asuvas Swedbanki IT majas.

Testijate Päev on praktilise suunitlusega ning päeva eesmärgiks on pakkuda osalejatele võimalust kokku saada ja kuulata oma ala spetsialiste rääkimas praktilistest lahendustest testimisega seotud probleemidele. Siinkohal on tähtis roll mängida ka kuulajatel: luues diskussiooni ning jagades oma temaatilisi kogemusi.

9:30 - 10:00 Kogunemine - hommikukohv ja snäk
10:00 - 10:15 Sissejuhatus

10:15 - 11:45 Turvatestimine
Esineja: Mait Peekma
Ettekanne, kust iga osaleja lahkub vähemalt ühe uue testijuhuga oma testide paunas. Alustuseks näited äriloogikas pesitsevatest vigadest. Seejärel keskendutakse veebirakenduste haavatavustele - ka sellistele, mida leidub rohkem kui pooltes dünaamilist sisu pakkuvates veebisaitides. Lisaks saab teada, mis on turvatestija motivatsiooni võti ja näha testimise etappeHollywoodi näitel. Ettekanne lõpeb ülevaatega ründetestimisest - muuhulgas sellest, kuidas sportautosid vasakule pannes seaduslikult leiba teenida.

11:45 - 13:00 Lõuna

13:00 - 13:45 Üllatusteema - testimine ja kvaliteet ITst väljaspool

13:45-14:30 Kuidas testida uut ID kaardi baastarkvara?
Esineja: Maili Markvardt
Kas teadsite, et iga päev antakse üle 40 000 digiallkirja? ID kaardiga isikutuvastusi on päevas aga üle 70 000. Riigi Infosüsteemide Arenduskeskus kuulutas 2008. aastal välja hanke "uue ID kaardi baastarkvara" arenduseks. Üheks uue tarkvara olulistest eesmärkidest oli võimaldada ID kaardiga seotud funktsionaalsuste kasutamist erinevatel Windows, Linux ning Mac platvormidel, et ID kaardi elektroonilist kasutust veelgi populariseerida. Paralleelselt arendushankega viidi läbi ka teine, Eesti mõistes ebatüüpiline hange: sõltumatu kvaliteedikontroll ning tugi tarkvaratulemite vastuvõtutestimisel. Käesolev ettekanne valgustabki uue ID kaardi baastarkvara vastuvõtutestimisega seotud küsimusi ja vastuseid:
· Kuidas testida efektiivselt kriitilist, keerukat ja mahukat multiplatvormset tarkvara?
· Kas automatiseerimine aitaks hea tulemuse saavutamisele kaasa?
· Kuidas optimeerida testide arvu, kui kõigi soovitud testide läbiviimine oleks liialt kulukas?
· Mis on see, mida ei ole ainuüksi testimisega võimalik saavutada, ja miks?

14:30 -14:45 Kohvipaus

14:45-15:30 Agiilne arendus- ja testimisprotsess
Esineja: Valli Rennig
Agiilne arendus/testimine kõlab küll uhkelt, kuid mida see sõna "agiilne" üldse tähendab? Milline on agiilne arendus ning kuidas testimine agiilses arenduses välja näeb? Kuidas võiks testija kohanduda agiilse arendusega? Valli Rennig annabki ülevaate agiilse arendusprotsessi ja testimise põhimõtetest baseerudes enda kogemusele ettevõttes Helmes.

15:30 - 17:00 Veebipõhiste rakenduste automaatne testimine Seleniumiga
Esineja: Raimond Sinivee
Organisatsioonidel, kes on kliendid tarkvaraarendus firmadele, on raske leida infot tarkvara arenduse kohta. Kliendid peavad testima rakendusi enne kui nad neid vastu võtavad, aga kuidas seda teha?
Probleem on selles, et kõik protsessid ja tehnoloogiad on tehtud silmas pidades tarkvara arendajate vajadusi ja eesmärke. Klient ei saa kasutada unit taseme või teisi tehnilisi meetodeid kui kogu arendus on väljast sisse ostetud. Kliendile jääb vastuvõtmise testid, kuid see on tavaliselt ettekannetest välja jäetud kuna pole arendaja vajadus.
Ettekanne räägib veebipõhise tarkvara testide automatiseerimise kogemusest firmas, kus kogu arendus on sisse ostetud. Peamiselt oli kolm põhimõttelist valikut või probleemi:
· Valikute tegemine - mida automatiseerida ning mis vahendeid kasutades?
· Probleemid Seleniumiga ning kuidas neist üle saada?
· Kuidas juurutada uut protsessi olemas olevasse?
Need küsimused ei ole tegelikult uued ja ülal toodud valikutest on kirjutatud raamatuid, aga ikka tulevad nad ette. Uus on vaade nendele küsimustele - tarkvara kasutaja vaade.Inimene, kelle jaoks on automatiseerimine uus teema, saab ettekandest häid näpunäiteid, millised probleemid võivad tulla. Need, kellel on juba kogemused kõnealuses valdkonnas, saavad ülevaate probleemidest kliendi seisukohalt.

Üritus on kõigile tasuta!

Registreeruda palume hiljemalt 24. märtsil läbi järgneva vormi: http://testijatepaev.eventbrite.com/
Ühtlasi leiab sealt ka vajalikku lisainfot ürituse kohta.

Kuna kogemusi vahetada ilma osalejateta on raske, siis ootame Teid aktiivselt osalema Testijate Päeval ning andma oma panust diskussiooni loomisse!

Kui te teate kedagi keda see üritus võiks huvitada siis edastage see kutse julgelt ka temale!