Kuidas Demosthenes Riias käis

Käes oli 24nda mai õhtupoolik. Riia taevast kattis õhuke pilveloor ning vastu Radissoni hotelli aknaid sabistas nõrk uduvihm. Mööda kolmanda korruse tuba sammudes harjutasin kõnet, mida ma saabuval konverentsil pidin esitama enam kui kahesajale inimesele. Justkui Demosthenes mererannal, kordasin oma sõnavõtu algust üha uuest ja uuesti.

Järgmisel hommikul saabus kahe bussi ja mõne autoga üle kahekümne lõbusa testilise Eesti Testijate Liidust. Üht bussi roolis Harles, teist Magnus. Peale sagimist parkimise ja hotellidega oligi aeg päevakava juurde asuda. Kuna järgmisel päeval nägi plaan ette konverentsil pikki kõnesid kuulata, siis esimesel kavatsesime ettevõtetes külas käia. Hakatuseks seadsime sammud Tieto Latvia-sse. Külastasime maksekaartide tarkvara tootvat allüksust, kus on umbes kakssada töötajat ning projekte üle maailma – Aafrikas, Lääne-Euroopas ja mujal. Teste haldavad nad QaTraqi-nimelise vahendiga, mille valis firmasisene eksperdirühm kolme võimaliku seast. Eelistena tõid nad välja kerge seadistamise ja integreerimise Jiraga, kus nad lisaks projekti haldamisele haldasid ka vigu.

Seejärel külastasime ettevõtte Exigen Services kontorit. Exigen pakub mitmesuguseid arendusteenuseid üle maailma. Lätis on nad juhtivad, kui mitte ainsad jõudlustestimise teenuse pakkujad. Selle asemel, et meid pika esitlusega kurnata, otsustas võõrustaja hoopis küsimuste ja vastuste vooru kasuks. Küsida võis kõike! Alates sellest, mitu korda masu tingimustes palka vähendati ja kui palju koondati, ning lõpetades sellega, milline on firmas töötavate nais- ja meestestijate osatähtsus.

Mis siis külastustest meelde jäi? Kõigepealt pakkus lohutust, et me polegi oma probleemidega üksi. Teisedki maadlevad samade küsimustega ning leitud lahendused sarnanevad meie endi omadega. Järelikult oleme õigel teel nii mitmeski asjas!
Teiseks jäi meelde, kui raskelt oli masu tabanud Läti ettevõtteid. Nt Exigen pidi oma testijate koosseisu vähendama 30% ja palku kärbiti kahel korral.
Päeva lõpetas korralik õhtusöök ja mõdu maitsmine kohalikku toitu pakkuvas restoranis. Meeldiv oli näha, kuidas keelepaelad valla pääsesid ning eri ettevõtete testijad suhteid looma hakkasid. Hiljem liiguti edasi tutvuma Riia ööeluga – kas seal mõni suhe ka edasi arenes, jäägu asjaosaliste teada.

Neljapäeva varahommikul liikusime Riia Tehnikaülikooli poole, kus toimus testimise konverents TAPOST 2011. Esinejad olid peamiselt oma ala eksperdid (jah, loen ka end selleks :p), kes andsid ülevaate testimisprotsessi parendamisest, testimise vahenditest, meetoditest ja projektidest. Lähemalt saab räägituga tutvuda siit.
Kui nüüd aus olla, oli mu esinemisärevus liiga suur, et praegu kõiki esinejaid ja nende ettekandeid täpsemalt meelde tuletada. Peate uurima neilt, kes kohal olid!

Minule jättis parima mulje Kaspar Loogi esitlus KnowIT arendatavast vahendist, millega kontrollitakse veebilehtede kuvamist veebisirvijates. Asja tegi minu jaoks huvitavaks fakt, et toote arendamiseks palgati pilditöötlusega tegelev teadlane, kes on sarnast põhimõtet kasutanud sõiduteedes pragude tuvastamiseks. Seega võib testimisvahendite tegemiseks inspiratsiooni leida kõikvõimalikest eluvaldkondadest.

Eelviimasena astusin kõnepulti mina – rääkisin, kuidas pangas eurole ülemineku testimist organiseeriti. Kuna ma polnud enne sellisele hulgale võõrastele esinenud, olid aplaus ning ettekande lõpus esitatud küsimused ja hilisem eraviisiline diskussioon väärt kõike seda harjutamist ja närveerimist. Soovitan julgelt teistelgi sedalaadi konverentsidel üles astuda. Saab nii esinemiskogemust kui ka uusi huvitavaid tuttavaid.

Tegu oli üritusega, mida tahaks kindlasti korrata. Suur tänu eestvedajatele!

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!