Tämä blogi on ensimmäinen osa iOS-sovellusten laadunvarmistukseen liittyen. Esittelemme sovellusten laatuominaisuudet ja laatua varmistavia toimia sovelluksen kehitysvaiheessa.

Mobiilisovellusten laatuominaisuudet

Sovelluksen laadun ensimmäinen osa on sen käyttökelpoisuus. Pystyykö sovelluksella tekemään sen, mitä varten se on suunniteltu? Sovelluksesta tulee löytyä kaikki käyttöä varten tarpeelliset ominaisuudet loppukäyttäjän ja sovelluksen tavoitteiden kannalta.

Toinen olennainen laatuominaisuus on sovelluksen käytettävyys. Onko sovelluksen käyttö helppoa, luonnollista ja vaivatonta? Loistavatkaan ominaisuudet, jotka nerokkaasti ratkaisevat jonkin käyttäjän tarpeen tai ongelman, eivät pelasta sovellusta, mikäli käyttäjä ei löydä tai ei osaa käyttää niitä.

Kolmas laatutekijä liittyy sovelluksen vakauteen ja suorituskykyyn. Mikä on sovelluksen palvelutaso, keskeytyykö käyttö virheisiin? Säilytetäänkö käyttäjän tiedot turvallisesti tallessa, ja voiko sovellusta käyttää mahdollisimman monessa eri tilanteessa, ulkoisista tekijöistä huolimatta? Tavallisin suorituskykyyn vaikuttava ulkoinen tekijä on mobiilidataverkon toimivuus ja nopeus.

Laadun huomionti ketterässä ohjelmistokehityksessä

Sovellusten ohjelmakoodin kehitykseen käytetään ketterää, iteratiivista ohjelmistosuunnittelua. Siinä kehittäjät ja käyttäjien edustajat suunnittelevat yhdessä toteutusta. Sovellusta rakennetaan pala ja toiminto kerrallaan, ja tehtyjen osien toimivuus ja laatu evaluoidaan kehitysryhmässä.

Jo ennen ohjelmakoodin kirjoitukseen ryhtymistä varmistetaan, että lähdetään kirjoittamaan tarpeellista, ei pelkästään toimivaa. Suunnitelmat, kuten käyttöliittymän toiminta ja ulkonäkö, varmistetaan asiakkaan ja kehitystiimin kesken. Monet lopullisen toteutuksen virheistä ovat peräisin virheistä ja puutteista speksausvaiheessa. Toisaalta kaikkea ei useimmiten voida päättää ja ratkaista valmiiksi ennen koodauksen aloittamista. Silloin hyvänä apuna on prototyyppien käyttö, joiden tekemiseen varautuminen tehdään jo projektin määrittelyvaiheessa.

Käyttöliittymäprototyypeillä voidaan varmistaa käyttökelpoisuus ja käytettävyys. Ratkaisuprototyypeillä puolestaan kokeillaan, toimivatko sovelluksen kannalta keskeiset toteutuksen osat. Näitä ovat esimerkiksi palvelinrajapinnat, uudenlainen käyttöliittymätekniikka (esim. AR tai anturien käyttö), tai aiemmin käyttämättömät ja siksi tuntemattomia vikoja sisältävät sovelluskohtaiset komponentit, joiden varaan sovellus on päätetty tai on pakko rakentaa.

Laatua varmistavat koodaustekniikat

Virheitä välttävillä eli ns. defensiivisillä kehitystekniikoilla pyritään puolustautumaan erityisesti aiemmin tunnetuilta virheiltä. Mobiilisovellusten tekemisessä tiedetään koko joukko tyypillisiä virheitä, jotka kokeneet sovelluskehittäjät tuntevat ennestään ja osaavat välttää niitä kokemuksensa ja muiden kehittäjien jakaman kokemuksen perusteella. Yleisimpiä esimerkkejä näistä ovat alustamattoman tai odottamatta nollatun muuttujan arvon käyttäminen, käyttöliittymän päivitys väärässä säikeessä asynkronisessa ohjelmoinnissa, tai huolimattomuus muistia vapautettaessa.

Tämäntyyppisten tunnettujen sudenkuoppien varalta voidaan automatisoida tarkistuksia. Osa hoituu Applen sovelluskehitystyökalujen tarkistustyökalujen avulla, ja osa voidaan lisätä sovelluskehitysprojektiin käyttäen sopivaa ulkopuolista aputyökalua tai kirjastoa. Automaattiset varmistukset voidaan kytkeä osaksi ohjelman normaalia käännösvaihetta, jolloin tarkistukset tulevat tehdyiksi aina kun ohjelmaa ollaan muuttamassa. Automatisoitujen virheenetsijöiden käyttö tehostaa laaduntarkkailua ja vapauttaa kehittäjien aikaa muuhun työhön.

Jotkut automaattiset tarkistukset ovat niin aikaa vieviä, että ne kannattaa tehdä vain ajoittain, eikä joka käännöksen yhteydessä. Tarkistukset tuleekin rytmittää siten, että ne viivyttävät uusien toimintojen kehitystä mahdollisimman vähän. Toisaalta yksikin virhe, jonka automaattinen testaus olisi voinut estää, voi helposti johtaa tuntien ajanmenetykseen virhettä etsiessä, joten etukäteistarkistuksia kannattaa useimmiten tehdä enemmän kuin olettaisi olevan tarpeen. Tyypillisesti ne säästävät pidemmässä kehitysprojektissa paljon aikaa projektin julkaisuhetken lähestyessä.

Jo valmiiden koodirivien laatua voidaan parantaa ohjelmoijien tekemillä katselmuksilla. Näillä pyritään parantamaan erityisesti ohjelmakoodiin selkeyttä ja ylläpidettävyyttä. Katselmukset ovat tehokkaimpia toisen saman alustan kehittäjän tekemänä. Vaikka mobiilisovelluksen tekemisestä usein vastaa yhdestä kahteen pääohjelmoijaa, ajoittain heidän tekemäänsä ohjelmakoodia katselmoi projektin ulkopuolinen kehittäjä.

Yksikkötestaus

Yksikkötestauksessa sovelluskehittäjä tekee ohjelmanosia testaavia ns. testicaseja. Tyypillisesti yksikkötestit ovat sovelluskoodin oheen tehtävää testikoodia, joka testaa kohdekoodia hyvin määritellyissä osissa, esimerkiksi luokka tai aliohjelmakirjasto kerrallaan. Mitä enemmän järkeviä yksikkötestejä saadaan laadittua, sitä helpompaa on ohjelmiston jatkuvan vakauden varmistaminen ohjelmistoon tehtävien muutosten myötä.

Tämä on tärkeää erityisesti siksi, että sovellusten koodimäärä kasvaa jo ennen julkaisua yleensä niin suureksi, että kaikkien koodin toimintojen ihmisvoimin tehtäviin tarkistuksiin kuluva aika ohittaa melko pian uuden koodin kirjoittamiseen tarvittavan ajan. Suhde tarvittavan testauksen ja uuden koodin kirjoituksen välillä kasvaa ohjelmiston kehittyessä elinkaarensa aikana, koska ohjelmistojen toimintomäärällä on taipumus kasvaa versio versiolta.

Eräs usein tehty virhe on jättää yksikkötestien kirjoitus omaksi vaiheekseen, kun varsinainen sovelluskoodi on jo kokonaan tehty valmiiksi. Vaikka yksikkötesteistä on hyötyä myös tässä vaiheessa, suurin hyöty saadaan jos yksikkötestejä kirjoitetaan sitä mukaan, kuin sen testaamaa sovelluskoodiakiin.

Integrointitestaus

Integrointitestauksessa sovellusta kokeillaan sen käyttämien taustajärjestelmien ja muiden sovellusten kanssa. Sovellusten palvelimilta ja muista järjestelmistä käyttämä tieto muuttuu tuotantovaiheessa yleensä jatkuvasti. Kun niin tapahtuu, onko sovellus valmisteltu käsittelemään kaikki tilanteet ja selviytyykö se niistä? Mitä tapahtuu kuormitustilanteissa, entä jos jostain syystä joitain tietoja puuttuu? Miten hoidetaan ennakoidut ja ennakoimattomat virhetilanteet sekä käyttökatkot palvelinten käytössä? Ovatko kaikki käyttötapaukset, joihin liittyy tietoliikennettä muihin sovelluksiin tai palvelimiin, käyty testaamalla läpi? Pystytäänkö tekemään jo tehty testi uudelleen samoilla tiedoilla, entä eri syötteillä ja odotetuilla vasteilla?

Integrointitestauksessa sovelluksien laadunvarmennus laajenee käsittämään koko järjestelmän. Sovelluksen ensimmäistä versiota kehitettäessä integrointitestaukset ovat monesti aluksi vain sovelluksen pääkehittäjän vastuulla. Varsin pian ne kannattaa kattavuuden, syvyyden ja toistettavuuden takia organisoida erillisen testausryhmän hoidettavaksi. Aivan kuten yksikkötestauksessakin, integrointitestauksen hyöty paranee mitä aiemmin se saadaan käyntiin.

Sovelluksien laadun varmistus ei pääty kehitysvaiheeseen. Kuinka laadunvarmistusta tehdään julkaisun osalta, beta-testauksella ja tuotantoaikaisen laadunvalvonnan muodossa? Niistä jatkamme laadunvarmistusta käsittelevien blogien seuraavassa osassa.