Kuigi tarkvara testimine seotakse enamikel arendusdiagrammidel üheks tegevuseks, mis leiab aset arendusetapi ja juurutamisetapi vahel, siis reaalsuses eeldab hea ja kvaliteetse tarkvaralahenduse loomine kümneid, kui mitte sadu, erinevaid testimiskordi, mis toimuvad terve arendusprotsessi vältel.
Hästi läbimõeldud ning tugev testimismetodoloogia tagab lisaks sellele, et lõpplahendus päriselt hästi töötab, ka selle, et arendajad ei ehita juba eos vigaste lahenduste peale järgnevaid lahendusi, mis muudab arenduse lõpuks ajakulukamaks, kallimaks ning ebaefektiivsemaks.
Kuigi olevalt konkreetsest projektist võivad täpsed testimissammud mõnevõrra varieeruda, siis üldjoontest läbib Uptime’is arendatav tarkvara järgmised testimisetapid.
Arendajapoolne jooksev testimine
Iga arendaja ülesandeks on kindlaks teha, et tema kirjutatud kood teeb ka päriselt seda, mida ta soovib. See ei tähenda suurte ja keeruliste automatiseeritud testide jooksutamist ning iga edge-case’i läbi proovimist – seda teevad kogenud testijaid – vaid lihtsat ja jooksvat kontrolli. Kui näiteks front-end arendaja on programmeerinud kontaktivormi ja nupu, siis tuleks tal ka päriselt üritada seda kasutada, tehes sellega kindlaks, et nupu vajutamisel ei teki kriitilist viga.
See on küll lihtsustatud näide, kuid sellise lähenemise ja pideva väikese testimise abil on juba arenduse esimestes etappides võimalik välja praakida suur hulk väikeseid vigu ja murekohti, mis võivad süsteemi tööd tugevalt mõjutada.
Staatiline koodianalüüs
Kasutades erinevat testimistarkvara saavad testijad ning QA-insenerid teha kindlaks, et kirjutatud kood vastab täielikult kehtestatud standarditele. Staatilise koodianalüüsi käigus kasutatakse automaatseid süsteeme, mis tuvastavad levinud turvanõrkuseid, standarditest kõrvale kaldumist ning mitmesuguseid muid vigu. Kõike seda tehakse testimiskeskkonnas ilma koodi tegelikult käivitamata, seega on tagatud, et tuvastatud probleemid ei saaks kuidagi mõjutada live-versiooni.
Unit testing
Unit testingu ehk üksuse testimise käigus luuakse arendaja poolt automatiseeritud protsessid, mis testivad kõiki kõige väiksemaid tarkvara tükke võimalikult paljude erinevate sisenditega, et tagada iga komponendi laitmatu töö.
Selle lähenemise abil saavad testijad teha kindlaks, et iga individuaalne tükk tarkvarast täidab sellele kehtestatud nõuded. Teiselt poolt tähendab automatiseeritud lähenemise kasutamine seda, et läbi on võimalik proovida suurem osa edge case’e kui oleks võimalik käsitsi.
Code review
Code review ehk koodibaasi ülelugemine on protsess, kus arendajad loevad üksteise koodi, et leida üles lahenduskäikude ebakõlad ning tagada stiili ühtsus. Selle protsessi käigus on võimalik tuvastada potentsiaalseid haavatavusi, näpuvigu või tuvastada probleeme, mis võivad mõnes hilisemas arendusetapis esile kerkida.
Kuigi arendajad suudavad tihti kirjutada pea veatut koodi, siis vaadates terve päeva ühtesid ja samu koodiridu võib tekkida olukord, kus enda näpukaid enam ei märgata. Kaasates kontrollringi värsked silmapaarid, kes suudavad olla täiesti objektiivsed ja lugeda koodi märksa keskendunumalt kui selle autor, võimaldab üles leida ka need vead, mis algselt märkamata jäid.
Koormustestimine
Lisaks sellele, et iga komponent suudab täita talle ette nähtud ülesandeid, tuleb testimise käigus ka selgeks teha, et arendused peavad vastu suurematele koormustele. Selle jaoks testitakse süsteemi erinevaid osasid erinevate (virtuaalsete) kasutajate hulkadega ning tuvastatakse, mis hetkel süsteem murdub ning vajadusel investeeritakse veelgi ressurssi suuremate koormustega toime tulemiseks.
Siinkohal tasub meeles pidada, et iga tarkvaraarendus on erineva eesmärgiga ning majasisene arvehaldustarkvara, mida kasutab kolm inimest, ei ole harilikult loodud teenindama korraga miljonit kasutajat. See võib küll endiselt väga hästi töötada tuhande samaaegse kasutajaga, kuid kui skaalad muutuvad drastiliselt, eeldab see harilikult ka täiendavaid investeeringuid nii riistvaraliselt kui ka tarkvaraliselt.
Klienditestimine
Lisaks sellele, et loodavat tarkvaralahendust testitakse arenduspartneri poolt, võib olenevalt projekti spetsiifikast täpselt samad läbi viia ka enda majasisene arendusmeeskond. Kui aga see võimekus puudub, siis võib kindel olla, et osaks arendusprotsessist on jooksev funktsionaalsustestimine.
See tähendab, et kui mõni arendusetapp on sellisel maal, kus seda saab proovida, siis palub Uptime lahenduse tellijal seda proovida ning loodut tagasisidestada. Sellise lähenemise abil on võimalik juba varajases staadiumis kindlaks teha, kui mõni osa süsteemist ei tee päriselt seda, mida klient eeldanud on.
Järjest laiem ring
Olenevalt konkreetsest projektist võib kliendi funktsionaalsustestimise erinevaid kihte olla kümneid: kõigepealt üks kliendi esindaja, siis terve projektitoimkond, siis terve ettevõte, siis väike hulk lõppklinte, siis suurem osa lõppkliente ja nii edasi.
Niisamuti tasub meeles pidada, et hea tarkvaralahenduse osaks on pidev täienemine ja probleemide lahendamine, seega võidakse potentsiaalseid murekohti avastada ka pikemaaegse monitooringu käigus (näiteks on mõni versiooniuuendus mõne probleemi tekitanud kolm kuud pärast seda, kui tarkvaralahendus kasutusele võeti), misjärel need hooldusteenuse raames kiirelt ära parandatakse.
Agiilne arendus aitab murekohad kiirelt tuvastada
Kui veel aastaid tagasi oli levinud praktika arendada valmis terve toode ning see siis kasutajatele proovida anda, siis Uptime’i kasutatavad agiilsed metoodikad aitavad riskid terve arendusprotsessi käigus madalamal hoida.
Agiilse arenduse käigus arendatakse lõpptoodet etapi kaupa, mis tähendab, et igat individuaalselt süsteemi luuakse justkui omaette väikest toodet, mis võimaldab seda efektiivselt analüüsida, testida ja juurutada. Kui võtta näiteks tellimushaldussüsteem, siis löödaks agiilse arenduse puhul arendusprotsess paljudeks väiksemateks osadeks: tellimuste sisestamise komponent, tellimuse verifitseerimise komponent, maksekomponent, ja nii edasi.
Sellise lähenemise abil ei saa ühe komponendi murekohad võimenduda mõne teise komponendi loomisel ning see tagab lõppkokkuvõttes efektiivsema arendusprotsessi, madalamad riskid ning parema lõpptoote.
