Testimise roll arendusprotsessis
Kvaliteet ja testimine
Kvaliteetne tarkvara koosneb lõppkasutaja ja tellija vaatevinklist vaadatuna paljudest erinevatest aspektidest. Näiteks sõiduauto puhul on lisaks heale välimusele, mis on tähtis enamikule kasutajatest :), olulisteks kriteeriumiteks veel kasutusmugavus, ergonoomika, töökindlus, hooldusarvete suurus ja muu taoline. Nii on ka tarkvaraga.
Toome siinkohal välja mõned kvaliteeti puudutavad näitajad, mida arendusprotsessis jooksvalt testitakse:
- disain – väljanägemine, tunnetuslik kogemus ja kasutusmugavus
- funktsionaalsus – st tarkvara teeb seda, mida oodatakse
- usaldusväärsus – töötab suuremate vigadeta
- paindlikkus – ei vanane kiiresti ja töötab kõigi populaarsemate brauserite ja operatsioonisüsteemidega
- kiire hooldus hilisemas faasis
- paigas hinna- ja kvaliteedisuhe
Trinidad Wiseman`i juured ulatuvad sügavale UX`i (kasutajakogemus) valdkonda, kanname olulist rolli WCAG (Web Content Accessibility Guidelines) direktiivide ligipääsetavuse tagamisel ning oleme teinud Eestis selleteemalisi uuringuid, andnud loenguid, kirjutanud mitmeid blogipostitusi ja koostanud auditeid. Luues ka avaliku sektori suuri infosüsteeme ja rakendusi (nt Haridusportaal, Minukarjäär.ee, uus Eesti Hariduse Infosüsteem) on oluline, et meie loodud tarkvara saab testitud agiilselt ning vastavalt ligipääsetavuse nõuetele, lähtume headest UX tavadest ning kasutajasõbralikkusest.
Ka erasektori projektide partnerina oleme järginud parimaid praktikaid, sealhulgas kasutanud agiilseid arendus- ja testimismeetodeid, mis tagavad kliendile paindlikkuse ning parema ülevaate käimasolevatest arendustsüklitest ning jõu ja nõuga abiks olnud kasvõi nt JIRA platvormi kasutamisel.
Tooteomaniku panus tootekvaliteeti
Tooteomaniku (tellija) roll on kogu kvaliteediprotsessis (sh testimine) väga oluline, kuid kohati alahinnatud. Kvaliteetse toote loomisel võivad saada otsustavaks just tooteomaniku teadmised agiilsete arendus- ja testimismeetodite põhitõdedest (nt Scrum, Kanban), teadmised tarkvaraarenduseks loodud platvormidest (nt JIRA, Confluence, Asana) ning aktiivne osalemine igas arendustsükli etapis, olgu selleks siis agiilse arenduse piletid testimisel või kasutuslugude loomine. Agiilse arenduse kohta saab lisaks lugeda meie blogipostitusest “Vesiagiilsus”.
Kindlasti ei tohiks alahinnata tooteomaniku panust ka vastuvõtu- ja beetatestimises. Soovi korral on kõik suunised veebist leitavad, kasutades otsinguks vastavaid märksõnu, samuti on võimalus osaleda temaatilistel koolitustel. Tõsisema tahte korral,et kvaliteediprotsessis läbi testimise osaleda, tasub läbi töötada ISTQB algtaseme materjalid, mis annavad väga hea baasteadmise tarkvara testimise alustest ning võimaldavad tooteomanikul seeläbi veelgi rohkem panustada.
Hea testija on sõltumatu
Kujutleme, et kokk kirjutaks ise oma loodud supiretseptist toidublogisse arvustuse. Sel juhul puuduks adekvaatse hinnagu andmiseks kõige olulisem - objektiivsus. Testimise maailmas kutsutakse seda “sõltumatuse astmeks” ehk mida sõltumatum on testija arendustiimist ja loodavast tootest, seda objektiivsem ta on. Samal põhjusel ei ole parim valik testijaks paluda arendajat ennast ega ka näiteks analüütikut, kes on kirjutanud nõuded, sest parafraseerides Goethe`t: “Me näeme ainult seda, mille olemasolust oleme teadlikud”.
Ka tooteomanikul puudub vajalik distants oma tootest ning seega võime näha seda objektiivselt ehk lõppkasutaja perspektiivist (erandjuhul võib ta ise olla ka lõppkasutaja). Lisaks võib protsessi takistada tooteomaniku loomulik surve kulusid kokku hoida ning seda ka kasutusmugavuse, funktsionaalsuse ja tootekvaliteedi arvelt. Hea testimine sünnib sõltumatu testija poolt, kes ei vali pooli arendusmeeskonna ja tooteomaniku vahel ning oskab ennast seejuures asetada lõppkasutaja rolli.
Kas saab ka testimiseta?
Testimine ei ole kindlasti tähtsaim lüli tarkvaraarenduse protsessis. Veebiavarustes leidub suurel hulgal tarkvara, mida ei ole spetsialiseerunud testija kunagi testinud ja millel puudub põhjalik dokumentatsioon. Põhjuseid miks spetsialiseerunud testijat ei kaasata on mitmeid, siin mõned levinumad:
- teadmatus täisväärtuslikust tarkvaraarendusprotsessi elutsüklist. Kvaliteetne tarkvara = kvaliteetne arendusprotsess.
- arusaam, et testimine on kallis. Tegelikult on oluliselt kulukam hiljem vigu parandada ja/või kliente kaotada.
- arendajad võivad ju ise testida. Arendaja teeb vigu, sest ta ei märka neid oma koodis.
- usk, et testimisega saadakse hakkama ka tellija meeskonnas. Kõik suudavad leida tarkvaras vigu, kuid oluline on see kui palju olulisi vigu jääb leidmata.
- lootus, et lõppkasutaja testib ise ja teavitab vigadest. Kahjuks reeglina ta hoopis lõpetab tarkvara kasutamise ning lahkub.
Kõik need erinevad fantoompõhjused viivad reeglina sama tagajärjeni - vigu täis tooteni ja rahulolematute klientideni (lõppkasutajateni). Tänases konkurentsitihedas maailmas kehtib aga tendents, et kõige edukamad ettevõtjad lähtuvad klientide vajadustest ehk mõtlevad väljast sissepoole, mitte vastupidi. Teisisõnu kui tarkvara, olgu selleks siis e-pood, infosüsteem või miski muu, ei vasta kliendi ootustele ehk ei ole kvaliteetne, siis ta lihtsalt lahkub, on arendajates pettunud ning rahuldab oma vajaduse kusagil mujal. Kalli raha eest loodud tarkvara ei täida oma eesmärki ning läheb vett vedama. Seega on testimisel arendusprotsessis väga oluline roll, et klient saaks täpselt selle, mida ta vajab – kvaliteetse toote.
