Kuidas tagada veebirakenduse sõbralikkust?

Veebirakenduse kasutajasõbralikkusest rääkides tulevad esimesena pähe lihtne ja selge visuaalne kujundus, mis võimaldab kasutajal intuitiivselt ning suure kasuteguriga oma eesmärke saavutada. Eesmärkideks võivad olla näiteks majandusaasta aruannete koostamine, müügitöö koordineerimine, e-poest meelepärase eseme tellimine või siis lihtsalt tuttavate piltide kommenteerimine ja meelelahutuslike videoklippide vaatamine. Tõhusam eesmärkide saavutamine loob sageli väärtusliku konkurentsieelise, seetõttu haaratakse uutest tehnoloogilistest võimalustest õhinaga kinni. Selge sisuesitluse ja intuitiivse funktsionaalsuse arendamisel kipub aga pahatihti tähelepanuta jääma rakenduse jõudlust määravate protsesside optimeerimine. Järgnevalt vaatleme, kuidas saab jõudlustestimine aidata kasutajasõbraliku rakenduse loomisel.

Kärsitu kiirustamine

Esimene jõudlusega seostuv parameeter, mis kasutajakogemust oluliselt mõjutab, on kiirus ehk aeg, mille jooksul rakendus suudab vajalikku infot kuvada. Kui 1990ndatel olid veebis surfajad harjunud kannatlikult enam kui 30 sekundit liivakellakujulist kursorit põrnitsema, siis nüüdseks on olukord drastiliselt muutunud. Arvutikasutajate kannatus katkeb üha kiiremini ning sageli otsustatakse juba paarisekundilise esmamulje põhjal, kas lehele jääda või mujale liikuda. Iga lisasekund lehe laadimisel võib seega rahulolevate kasutajate hulka märkimisväärselt vähendada.

Jõudlustestimine aitab saada ülevaadet sellest, kui kiiresti mingi veebirakenduse osa päringutele reageerib ning võimaldab kindlaks määrata rakenduse kõige aeglasemad kohad. Näiteks võivad optimeerimata andmebaasipäringud või virtuaalserveri vale konfiguratsioon põhjustada tarbetuid viivitusi, mida saaks vähese vaevaga parandada. Jõudlustestimine juhib sellistele pudelikaeladele tähelepanu ning aitab veenduda selles, et süsteemi kasutajatele kuvatakse vajalik info võimalikult kiiresti.

Skaleeritavus

Üksikute kasutajatega süsteemi testimisel ei pruugi välja tulla rakenduse võimekus hakkama saada suurema hulga päringutega. Ebaotstarbekalt süsteemi ressursse kulutav algoritm võib vähese arvu kasutajatega näiliselt edukalt toime tulla, kuid päringute arvu kasvades ootamatult kinni joosta. Jõudlustest aitab hinnata, mitut kasutajat suudab süsteem üheaegselt piisava kiirusega teenindada. Nii on võimalik kasutajatele süsteemi suure koormuse korral juba ennetavalt kuvada vabandav teade. Kasutajate piirarvu täitumisel uutele sisenejatele viisaka selgitusega sissepääsu takistamine on märksa kasutajasõbralikum lahendus kui ootamatud tõrked või talumatud viivitused.

Süsteemi skaleeritavuse planeerimisel tasub arvestada ka sellega, et süsteeme kasutatakse tavaliselt ebaregulaarselt ning keskmine lehekülastuste arv ei pruugi kasutajate käitumist piisavalt täpselt kirjeldada. Turunduskampaaniad, tähtajad, riigipühad ja mitmed muud faktorid võivad tavapärase süsteemi koormuse lühikese aja jooksul mitmekordistada. Näiteks kipuvad ülikoolide õppeinfosüsteemid olema kõige aeglasemad vahetult enne ainetele registreerumise tähtaegu ning piletimüügisüsteemid ägavad ülekoormuse käes, kui algab müük ülipopulaarsele üritusele.

Ebaregulaarsete kasutusmustrite tundmine võimaldab jõudlustesti tulemusi paremini mõtestada ning vastavalt ka rakenduse arendustegevusi planeerida. Lisaks mineviku mõtestamisele tasub mõelda ka tulevikuplaanidele. Ettevõtte laienemine ja uute tehnoloogiate (näiteks aina taibukamad nutiseadmed, täiendatud reaalsus, semantiline veeb, Big Data) kasutusele võtmine mõjutab märgatavalt kogu infovahetusprotsesside mahtu. Jõudlustestimine aitab kontrollida rakenduse skaleeritavust, et arendatav tarkvaralahendus oleks võimalikult jätkusuutlik.

Kasutusvoog

Kõikvõimalike testide üks peamine eesmärk on lõpptulemusena tagada rakenduse kasutajale võimalikult sujuv kasutusvoog (flow). Aeglane lehe laadimine, keerukatest menüüdest vajaliku funktsionaalsuse otsimine ja muud tarbetult aeganõudvad tegevused takistavad kõik sujuvat voogu rakenduse alguspunktist soovitud tulemini. Eriti häirivalt mõjuvad ootamatud tõrked ning tavakasutajale arusaamatud veateated (näiteks "0x361F ERRORIPSECIKE_SRVACQFAIL" või "Uncaught exception: Java.lang.Error at sun.plugin.util.PluginSysUtil $SysExecutionThread.run").

Ideaalses süsteemis toimiks kõik loogiliselt, kiiresti ning vigadeta, kuid reaalses elus on tarkvaravead praktiliselt vältimatud. Taibukamad süsteemid oskavad aga veasituatsioonidest väärikalt välja tulla. Nimelt ei kuvata komplitseeritud veakirjeldusi ega lakoonilisi 404-laadseid koode, vaid konstruktiivne ja viisakas teade, mis aitab võimalikult valutult kasutusvoogu jätkata. Mitmed lehed lähevad veel sammu kaugemale ning katsuvad potentsiaalse frustratsiooni vähendamiseks veateated lõbusaks teha.

Ükskõik kui meisterlikult loodud veateated ei aita aga pikemaajaliste ja sagedaste jõudlusprobleemide korral. Ka jõudlustestimine iseenesest veel jõudlusprobleeme ei lahenda, vaid annab ainult infot, mille põhjal edasi tegutseda. Näiteks kui on teada, et enam kui 10 paralleelse ühenduse korral on rakenduse töö häiritud, aga planeeritud kasutajate hulk päevas on ligikaudu 4000 inimest, siis on mõistlik kiiremas korras võtta kasutusele ettevaatusabinõud hiireviha tekitavate olukordade ennetamiseks. Jõudlushinnangu puudumisel võib julgelt kasutajate kannatusega katsetamine vägagi kulukalt lõppeda.

Edukalt läbitud jõudlustest ei tähenda, et ollakse kaitstud 400-gigabitiste rünnete eest. Küll aga on rakenduse haldajal märksa täpsem ülevaade vastava tarkvara võimekusest ning rohkem infot efektiivsete arendusotsuste tegemiseks, mis aitavad tagada rakenduse võimalikult kasutajasõbralikku käitumist.

Sten Mäses
ASA Quality Services