Tuesday, December 2, 2008

Mõtteid EuroSTAR-i mõttekojast

Läinud reedel võttis seltskond aktiviste ette teekonna Aqris Software kontorisse, kus Mart meid vastu võttis ja lahkelt kostitas. Külastuse eesmärgiks oli siiski kuulata Raivo muljeid EuroSTAR-l kuuldust-nähtust ja sellele oma vaatenurgast hinnang anda. Olles ise eelnevalt kolmel korral EuroSTAR-l osalenud, oli ette aimata, et tulemas on huvitav õhtupoolik.
Omast kogemusest võin öelda, et peale nelja päeva konverentsil on tagasi tulles väga raske vastata küsimustele nagu "Noh, said nüüd targaks?" või "Mis head teada said?". Samas on vägagi loogiline, et arvestades konverentsi hinda sealt lausa peab midagi väärtuslikku kaasa haarama. Olgu selleks siis mõni uus idee, mida saab kohe realiseerima hakata, või lihtsalt kinnitus sellele, et liigud õiges suunas. Olen endale pannud nö. normiks saada igalt külastatud ürituselt vähemalt kolm nimetatud kriteeriumitele vastavat ideed.
Järgnevalt toon välja mõtted, mida sain antud ürituselt.
Esiteks. See, kuidas me testime, ja kui motiveerituna me end tunneme, sõltub ainult meist endist. Me võime teha seda igavalt ja samas väga huvitavalt. Exploratory testimise propageerijate vaatenurgast lähtudes oli nende meelisviis nö. 'hele tulevik', kus põhiliseks märksõnaks on loomingulisus. 'Tumeda tulevikuna' nähti pingsat teooriast ja tehnikatest kinnipidamist, mis kõik testijad ühesuguseks pidavat muutma. Mida sellest arvata? Maailm ei ole ainult must ja valge, enamuses on siiski hallid toonid (kui järgida must-valget skaalat). On väga oluline, et me ei võtaks ühte konkreetset teooriat absoluutse tõena, vaid omades laia kogemuste ja teadmiste pagasit, oskaksime vajalikul momendil valida just õige lähenemisviisi. Keegi meist ei taha ju sõita lennukiga, mille tarkvara on testitud ainult loomingulisest vaatenurgast. Teisest küljest ei saa internetipanga kasutusmugavuse kohta rangete testimistehnikate abil ka midagi asjalikku öelda.
Teiseks. Mõelgem enne testima asumist, miks me seda teeme. Mis on see lisandväärtus, mida me oma klientidele pakume? Kas lihtsalt sõnake 'OK', mis väljendab meie arvates tarkvara valmisolekut toodangukeskkonda installeerimiseks? Või on see ülevaade tarkvara vastavusest kirjalikult dokumenteeritud nõudmistele? Või hoopis midagi uut selle kohta, kuidas tarkvara saab kasutada ja kuidas see võiks kliendile sobida? Tuli meelde vanasõna, et seitse korda mõõda, üks kord lõika. Kas just seitse korda mõõtma peab, aga enne lõikamist peame igal juhul teadma, miks me midagi teeme, ja mis on lõpptulemus. Motivatsioonile aitab kaasa ka see, kui teame, mis otsuseid klient meilt saadud info alusel teeb. Kui hiljem näeme, et sellest kasu oli, on ka testimise vajalikkus selgelt mõistetav.
Kolmandaks. Milline näeb välja testija roll tulevikus? Oleme harjunud mõtlema, et ühes õiges tarkvaraprojektis on esindatud projektijuht, analüütik, arendaja, testija ja kui hästi mõelda, siis leiab mõne vajaliku rolli veel. Siiski, järjest enam tulevad kasutusele agiilsed arendusmetoodikad ja enam ei ole võimalik eristada nö. puhtaid rolle. Pigem suudavad projektis osalejad teisi teatud määral katta ja vajadusel on võimalik rohkem jõudu suunata sinna kuhu vaja. Juhtivat rolli selles tegevuses etendab vastava ala kõige paremini tundev projektirühma liige. See viitab ka sellele, et testija ei saa olla ainult persoon, kes arenduse lõppfaasis funktsionaalsuse ekraanil läbi klikib, vaid heade tehniliste teadmistega spetsialist, kes testimist väga hästi tundes, suudab mitte vigu ainult võimalikult kiiresti peale nende tegemist leida, vaid analüüsi käigus asjalikke küsimusi küsides ja riske analüüsides suisa ennetada. Vähetähtis ei ole ka teiste projektirühma liikmete juhendamise oskus ning suutlikkus oma tegevusplaani põhjendada.
Mida kokkuvõtteks öelda - on, mille üle mõelda. Liiga tihti langeme laiskuse ohvriks ja pakume oma klientidele ainult seda, mida meilt küsida osatakse. Või teisest küljest - tutvudes mõne uue teooriga, hakkame seda kiiresti ellu viima mõtlemata sellele, mis kasu see kokkuvõttes annab. Hoidkem oma silmad ja kõrvad tahti, mõelgem selle peale, mida ja kuidas teeme. Ja teeme seda nii, et oleks Fun! Head testimist!

1 comment:

Raivo Päts said...

Loovus ei ole testimise tehnika, meetod või strateegia. Loovus on mõttelaad mida testija reakndab kui ta kasutab testimise tehnikat, meetodit või strateegiat. Seega ei saa väita, et loovus testimise juures ei sobi mingi kinlda toote testimiseks.

Loovus on annab tavapäraste tehnikate reakendamisele lisaks veel midagi ning tema kasu tuleb välja lisandväärtuse loomisel.

Näiteks: Kosmoselaevas kirjutamiseks kasutatakse pastakaid. Liigub legend, et venelased võtsid kasutusele selle asemel pliiatsid mille arendamiseks ei pidanud miljoneid raiskama. Kui me oletame, et see legend tõsi on, siis tekib küsimus kus olid testijad? Nimelt, hariliku pliiatsi süsi laguneb kirjutades muutudes grafiidi tolmuks, mis kaaluta olekus hõljuks erinevate masinate osadesse ja põhjustaks kahtlemata millegi rivist välja langemise. Testija, kes lihtsalt kontrolliks nõudeid vaataks: "Pliitas olemas, OK". Testija, kes suudaks läheneda loovalt, suudaks ette kujutada situatsiooni ning suudaks välja tuua riski, mis kaasneb hariliku pliiatsi kasutamisega (grafiidi tolm satub masinatessse).
Mõlemad juhud nö. testivad toote ära, kuid viimasel juhul loob testija lisa väärtust tuues välja riski. Just selles seisnebki loovuse eelis testimise juures.