Kuidas testija saab luua lisaväärtust?

 

 

“Halvim on mitte midagi teha, seejärel teha nii palju kui vaja ja parim on teha veidike rohkem kui vaja”. -Theodore Roosevelt

 

Kui interpreteerime sama mõtte tarkvara testimisse, siis “nii palju kui vaja” võrdsustub siinkohal testimise, vigade leidmise ja nõuetele vastavusse viimisega – kõik see kokku on juba suurt pühendumist nõudev ülesanne.

 

“Teha veidike rohkem kui vaja” on kõik see, mis eelnevast väljapoole jääb. Testija peamist ülesannet võiks defineerida kui võimalikult väheste vigadega kvaliteetse toote üleandmist tooteomanikule erinevate piirangute raames, milleks on näiteks tähtaeg, eelarve ja meeskond. Selle saavutamiseks saab testija panustada oluliselt laiemal skaalal, kui ainult arenduse nõuetele vastavusse viimine.

 

Järgnevad soovitused baseeruvad isiklikul kogemusel ja võivad varieeruda sõltuvalt projektist, tooteomaniku ja arendaja meeskonna koosseisust ning projekti mahust.

Need praktilised nõksud võiksid olla abiks algajale testijale, kes soovib kusagilt alustada ning olla tarkvaraarendusprotsessis midagi enamat kui vaid “Dante põrgu viimane aste” nagu üks arendaja naljatades kunagi testimise sõnastas :)

 

 

Kahedimensiooniline testimine: nõuetel ja ideedel baseerumine

Kuna fikseeritud projektimaht seab testimisele samuti piirangud, siis prioriteetne on alati püüda saavutada vastavus nõuetele, kuid see ei keela testijal panna kirja kõik oma ideed toote kvaliteetsemaks muutmise kohta.

 

Näiteks kui analüüsis ja disainis on laadimine kinnitatud sisu juurde nupuga “laadi rohkem”, kuid sisu, mida juurde laadida on tegelikkuses lõppkasutajal sadades ühikutes, siis testija võib teha ettepaneku paginatsiooni lisamiseks “laadi rohkem” nupu asemel.

 

Kuna täiesti uue komponendi loomine ei ole nö “skoopis” ehk projekti kirjutatud, siis võib sääraseid ettepanekuid ideedena talletada näiteks eraldi dokumendis, mis mingi faasi lõppedes tooteomanikule esitatakse ning tema saab vastavalt oma hinnangutest ja võimalustest lähtuvalt neid ideid soovi korral realiseerida.

 

Selliselt nõudeid ja ideid lahutades on võimalik fikseeritud mahuga projektide korral jääda eelarvesse, pakkudes kliendile samaaegselt lisaväärtust.

 

 

Vea raporteerimise asemel vea ja veaparandamise raporteerimine

Viga, mida ma olen ise korduvalt teinud on see, et näiteks mittefunktsionaalse testimise (nt kasutatavuse testimine, ligipääsetavuse testimine) raames olen välja toonud küll vea kirjelduse, kuid ei ole lisanud, kuidas seda viga parandada ning toonud juurde näidet korrektselt töötavast komponendist.

 

Näiteks kui arendatud jäljerida (ing k. “breadcrumbs”) ei ole klaviatuuriga ligipääsetav, sel puudub fookusindikaator ning see ei sisalda endas linkelemente, siis olulisel määral säästab arendaja aega täpne kirjeldus ehk kuidas element peaks käituma, juurde veel koodinäide ja viide õigesti töötavale näitele. Teisisõnu, veakirjeldus ainult läbi eituse ei tohiks kunagi olla piisav sisend arendajale vea parandamiseks.

 

 

Automatiseeritud regressioonitestid

Regressioonitestid on vast kõige "tuimem" osa testimisest, kuid need aitavad meil vabastada aega muude tegevuste jaoks. Nende ülesandeks on korrata juba loodud teste ja avastada seeläbi vigu, mida värske koodijupp võib põhjustada.

 

Aina samade ja samade testide käsitsi “läbihakkimine” on äärmiselt ajakulukas ning selle asemel peaks testija hoopis looma näiteks uusi teste ja liikuma protsessis pidevalt edasi. Ei ole olemas projekti, kus aeg ei oleks kriitiline tegur, eriti agiilsetes mudelites ning seeläbi peaks igasugune automatiseeritus, mis aitab võita aega, asuma pidevalt testija fookuses olulisel kohal.

 

 

Testandmete ja keskkondade haldamine

Testkeskkond peaks võimaldama kõigil arendusosapooltel - nii arendajal kui tooteomaniku poolsel meeskonnal kiirelt ja mugavalt ligi pääseda kogu arenduse ulatusele, sisule ja informatsioonile.

 

Sisuliselt tähendab see seda, et on loodud vastavad andmed, millega on seotud konkreetsed kasutajad ja mis katavad ära maksimaalse võimaliku arenduse ulatuse. Kõik see info on kergesti leitav, vastavad seosed on lahti kirjutatud, ligipääsetavad ning ajakohastatud projekti dokumentatsioonis (soovitavalt pilves).

 

Oletame, et näiteks UX-disainer, tooteomanik või analüütik soovib näha konkreetset varasemas etapis arendatud sisu, mis on loodud maksimaalsete võimalike andmetega. Sel juhul saab ta dokumentatsiooni abil selle iseseisvalt leida ning ei sõltu muust arendusmeeskonnast.

 

Nii vajalike testandmete viimine testkeskkonda kui ka dokumentatsiooni loomine peaksid olema testija ülesanded, kuna tema loob nagunii juba nõuete täitmise testimisel vastava andmestiku.

 

 

Rumal testija on parem kui kogenud empaatiavõimetu testija 

“Rumalana” on siinses kontekstis silmas peetud testijat, kes ei ole veel väga tehniline, kellel pole veel viit aastat testijana töötamise kogemust, kes ei orienteeru väga hästi erinevates andmebaaside keeltes ega tarkvaraarendusprotsessides ning kes esitab väga palju “rumalaid küsimusi”.

 

Miks need omadused on kasulikud ja võivad muuta testija tegelikult hoopis emaaptiavõimeliseks?

Testija üks olulisemaid oskusi on võime näha toodet lõppkasutaja perspektiivist ning puhtalt lehelt. Selleks aga on parem olla “rumal” ehk mitte teada tarkvaraarenduse telgitaguseid, mitte osata seletada puudujääke ehk kuidas mingi asi töötab või miks ta nii töötab või ei tööta ning olla tarkvaraarendusest mitte midagi teadva inimese nõudlikkuse ja vajaduse tasemel.

 

Ehk a priori, lõppkasutajaid ei tohi kunagi pidada sama võimekateks kui on arendusmeeskond ja seepärast tuleb julgesti küsida arenduselt ja analüüsilt “rumalaid küsimusi” - ütleks suisa, et seda parem on testija, mida rohkem ta julgeb ja oskab küsida ”rumalaid” küsimusi.

 

 

Agiilses arenduses on ka testija agiilne

 Sisuliselt tähendab see seda, et testija oskab oma aega planeerida nii, et temast ei saaks pudelikaela näiteks “scrum”-tüüpi projektides. Sellest hoidumiseks töötab ta ülejäänud meeskonnaga samas ajaaknas, mitte ei alusta testimisega siis, kui tal vabaneb aega muudest projektidest ja tegemistest.

 

Lisaks raporteerib testija kõik leitud vead, võimalusel järgides ülaltoodud vearaporteerimise soovitust, et tõsta “debuggimise” ja tarkvaraprotsessi kiirust ka üldises plaanis.

 

 

Testija testib ka arendusprotsessi kvaliteeti

See punkt võib osaliselt kuuluda ka kvaliteedi spetsialisti tööpõllule (ing k “Quality Assurance Specialist”), kuid kompaktsetes meeskondades tihti see roll puudub ning arendusmeeskonna viimase lülina on testijal parim ülevaade kogu arendusprotsessi realiseerimisest tervikuna.

 

Kui disainivaated on liialt visandlikud, näiteks ei sisalda tegelikult reaalset informatsiooni ega erijuhte, või need on versioneerimata - agiilses arenduses kirjutatakse pidevalt üle ühte faili milleks on disainifail, siis reeglina tekitab see vigu arenduses.

 

Või siis, kui nõuetes puuduvad korralikud kasutajalood, need on ajakohastamata või on sisult mitmeti tõlgendatavad, siis reeglina tekitab see samuti vigu arenduses. Ka siis, kui näiteks arendaja valib valmis komponendi, mis tegelikult konkreetsesse lahendusse ei sobi.

 

Testija lisaväärtuslik ülesanne on analüüsida arenduses tekkinud vigu ja põhjuseid ning neile tähelepanu juhtida. Loomulikult annab siin selge panuse ka staatiline testimine, kuid see ei saa asendada täielikult tehtavaid järeldusi ega analüüsi, mida on võimalik teha ainult peale arenduse faasi.

 

Sellist protsessi osa, mida ei saa teha efektiivsemaks, ei ole olemas. Kvaliteet koosneb iga rolli kvaliteedist eraldi ning meeskonnatöö kvaliteedist kollektiivselt.

 

 

Kokkuvõtteks

Testijal on kindlasti võimalik luua tarkvaraarendusprotsessile lisaväärtust, omades vaid soovi panustada natuke rohkem kui vaja. Testijad võivad aidata luua paremaid tooteid, kui nad keskenduvad ennetamisele ja iga projekti käivitamisest tuleneva töövoo optimeerimisele.

 

Loodame, et leidsid meie kirjutatud artiklist kasulikke soovitusi, mida oma ettevõttes testimispraktikasse panna. Katsetage meie testija poolt pakutud nõuandeid ka oma testimistöös ja kirjutage meile oma kogemustest.