IOS-SOVELLUSTEN LAADUNVARMISTUS, OSA 2

Tämä blogi on toinen osa iOS-sovellusten laadunvarmistuksesta. Ensimmäisessä osassa kävimme läpi sovellusten laatuominaisuuksia ja laatua varmistavia toimia kehitysvaiheessa, tässä blogissa esittelemme julkaisun, beta-testauksen ja tuotantoaikaisen laadunvalvonnan.

 

JULKAISUN QA

Kaikki App Storeen julkaistavat sovellukset tarkistetaan Applen toimesta ennen julkaisua niin sanotussa App Review:ssä. Kyseinen laadunvarmistuvaihe kestää yleensä muutamia päiviä. Apple ei anna tarkkoja tietoja oman laadunvarmistusprosessinsa kulusta, mutta tarjoaa hyvät ohjeet niistä asioista, joihin laadunvarmistus keskittyy. Tarkistettavat kohdat liittyvät tekniseen toimivuuteen, käytettävyyteen, sovelluksen laillisuuteen ja asetusten mukaisuuteen sekä sisällölliseen asianmukaisuuteen, esimerkiksi sopiiko sovellus tarkoitetulle ikäryhmälle. Toimivan sovelluksen lisäksi Apple tarvitsee sovellukseen liittyviä ja siitä käyttäjille App Storessa annettavia tietoja.

Sovelluksen julkaisun lähestyessä on tärkeää olla perillä kaikista App Storen vaatimuksista ja valmistauduttava täyttämään ne. Etukäteen tiedossa olleen vaatimuksen jättäminen huomioimatta johtaa yleensä sovelluksen hylkäykseen, korjausten tekemiseen sekä uuteen lähetykseen App Review:iin.

Koska Applen tekemiin tarkistuksiin tulee aika ajoin uusia vaatimuksia, hylkäyksiin kannattaa varautua vaikka prosessi olisikin ennalta tuttu. Erityisesti iOS-käyttöjärjestelmäpäivitysten ja uusien iOS-laitteiden lanseerauksien yhteydessä Apple usein lisää tai tarkentaa vaatimuksia, ja jotkin näistä (tai tarvittavat toimenpiteet niiden täyttämiseksi) selviävät vasta päivittyneen App Review:n hylkäyksestä.

Nyrkkisääntönä tavanomaisen sovelluksen ensimmäiseen julkaisuun valmistauduttaessa olisi hyvä saada ensimmäisen versio valmiiksi App Review:ta varten viimeistään vähintään kaksi viikkoa ennen suunniteltua lanseerauspäivämäärää. Jo olemassa olevaa sovellusta päivittäessä App Review:iin pitäisi päästä viimeistään viikkoa ennen käyttäjille suunniteltua julkaisua. Näiden aikarajojen puitteissa on yleensä helppo korjata puutteet ja tehdä App Review:n uusinta, mikäli tarpeen. Näistä aikatauluista poiketen App Review:ssä on ajoittain poikkeuksellista ruuhkaa tai koko App Review on tauolla ja näissä tapauksissa sekä julkaisun, että siihen valmistautumisen aikataulua joudutaan luonnollisesti säätämään viiveen mukaisesti.

Suuritöisin osa App Review:n varautumista on yleensä varmistuminen sovelluksen kelpoisuudesta tuotantoon.

 

SOVELLUKSEN TEKNINEN TOIMIVUUS

Teknisen toimivuuden varmistumiseksi tehdään julkaisutestaus, jossa varmistetaan että sovelluksen kaikki toiminnot toimivat tuotantoympäristössä. Tässä vaiheessa testaukseen käytetään integrointitestauksen tapaan tuotantojärjestelmää ja ‘oikeaa’ sovellussisältöä. Testausta pyritään varioimaan riittävästi eri käyttötilanteissa, olosuhteissa, sekä alustan erilaisilla laitteilla, alustan ja etukäteen määriteltyjen yhteensopivuustavoitteiden mukaisesti.

iOS-sovelluksille tyypillisesti julkaisutestauksessa täytyy testata kaikki sovelluksen osat kaikilla sovelluksen kanssa yhteensopivilla iPhone- ja/tai iPad-malleilla, ja normaalisti ainakin uusimmalla ja sitä edellisellä iOS-versiolla. Tapauskohtaisesti käyttöjärjestelmäversioita voi olla valittu tuettavaksi useampiakin ja luonnollisesti testauksen määrä kertaantuu testattavien iOS-versioiden määrällä. Käytännössä pienehköissä sovellustiimeissä kehittäjien ja testaajien aika ei riitä testaamaan kaikkia testikombinaatioita, joten on tärkeää tehdä testauksesta etukäteissuunnitelma, jossa päätetään kuinka kattava testaus tehdään kullekin iOS-versiolle ja laitteelle.

Julkaisutestauksen sekä Applen etukäteisohjeiden mukaan tehtyjen tarkistuksien ja mahdollisten korjausten jälkeen sovellustiimin tehtäväksi jää korjata mahdolliset puutteet, jotka Applen laadunvarmistustiimi raportoi, sekä tehdä tarvittaessa uusinnat App Review:iin.

Kaikissa testausvaiheissa voidaan osin soveltaa automaattista testausta niin sanotun jatkuvan integroinnin prosessissa, missä sovelluskoodimuutoksissa varmistetaan automaattisesti suoritetuilla testeillä, että muutoksia ennen toteutetut sovelluskoodin toiminnat edelleen toimivat.

Osa App Review:n vaatimusten tarkistuksista on myös mahdollista automatisoida jatkuvan integroinnin testein. Esimerkkeinä rutiininomaisesta hylkäyksestä App Review:ssä ovat puuttuvat App Storen tarvitsemat meta-tiedot, kuten sovelluksen ikonit ja kuvat, sekä puuttuvat tai ristiriitaiset tiedot sovellusten käyttämistä iOSin ominaisuuksista. Tämäntyyppisten asioiden tarkistuksen automatisointi on järkevää erityisesti silloin, kun sovellukselle halutaan säännöllinen ja usein toistuva päivitys App Storeen. Näin toimien voidaan minimoida rutiininomaisissa päivityksissä tapahtuvat App Review -hylkäykset. Tarkistukset voidaan yleensä tehdä käyttäen Applen sovelluskehitysympäristön XCoden mukana tulevia työkaluja. Työkalujen liittäminen jatkuvan integroinnin testeihin on osa sovelluskohtaista laadunvarmistustyötä.

 

BETA-TESTAUKSELLA VARMISTETAAN KÄYTTÖKELPOISUUS JA KÄYTETTÄVYYS

Usein varsinkin kuluttajille suunnattuihin sovelluksiin täytyy ehdottomasti käyttää Beta-testausta, joilla sovelluksen laadusta kerätään tietoa määrältään rajatun loppukäyttäjäkunnan näkökulmasta. Tällä saavutetaan monet tuotantoaikaisen laadunvalvonnan eduista, eli löydetään valtaosa kehitysaikaisessa laadunvarmistuksessa huomaamatta jääneitä asioita, mutta toisaalta suojataan suurin osa loppukäyttäjitä kyseisten puutteiden kohtaamiselta. Beta-vaihetta laadunvarmistuksessa voikin suositella poikkeuksetta ja sen pois jättäminen on suuri riski laadunvarmistuksen näkökulmasta.

Tämä testausvaihe sekä sen tulosten perusteella tehtävä uusi julkaisulaadunvarmistus ajoitetaan hyvissä ajoin ennen App Storeen tähtäävää App Review:tä. Sovelluksen laajuudesta tai uutuudesta riippuen useampi kuin yksi Beta-testauskierros voi olla tarpeen ja suositeltava.

iOS-sovellusten Beta-testauksen järjestäminen tapahtuu käyttäen siihen tarkoitettuja palveluita ja järjestelmiä, joihin kuuluvat esimerkiksi Applen iTunes Connectin Test Flight ja kolmansien osapuolien betatestijakelu- ja palautepalveluita, joista mainittakoon vaikkapa Fabric.io:n Beta.

Beta-testauksen tehokas järjestäminen käytännössä ja siihen liittyvät yksityiskohdat ovat oman blogipostauksensa ansaitseva aihepiiri.

 

TUOTANTOAIKAINEN LAADUNVALVONTA

Kun sovellus on saatu sovelluskäyttäjille ja App Storeen, laadunvarmistustoimet eivät lopu. Alkaa yksi tärkeimmistä vaiheista, eli sovelluksen vakauden ja toimivuuden varmistaminen loppukäyttäjille. Mikään ennen julkaisua tehtävä käytännöllinen testaus ei normaalisti löydä kaikkia ohjelmistovirheitä, vaan osa niistä ilmenee vasta loppukäyttäjien päästessä käyttämään sovellusta. Myös palvelin- ja tuotanto-olosuhteissa voi tapahtua tuotantovaiheessa muutoksia, joihin ei kaikkiin ole ennalta varauduttu. Siksi sovelluksen vakauden monitorointi loppukäyttäjillä sekä erilaiset palautekanavat, joiden avulla käyttäjät voivat raportoida havaitsemistaan ongelmista, ovat erittäin tärkeitä. Nämä valitettavasti pienemmissä sovellusprojekteissa varsin usein saatetaan unohtaa tai jättää julkaisun jälkeiseksi murheeksi, mitä missään tapauksessa ei saisi tehdä. Sovelluksesta löytyvät mahdolliset viat on varauduttava korjaamaan ja tarvittaessa tekemään korjauspäivitys App Storeen, joskus varsin nopeallakin aikataululla.

Tuotannonaikaisten ongelmien seurantaan on palveluja, joita käytämme Starcutin sovellusprojekteissa. Nämä keräävät ongelmatapauksista raportteja ja kerättyjen tietojen avulla voidaan saada tieto kaatumisista, niiden vakavuudesta, ja monesti myös ohjelman siitä osasta, jossa ongelma ilmenee.

 

PALKKANA LAADUNVARMISTUKSESTA SITOUTUNEET KÄYTTÄJÄT

Laadunvarmistus on sitä haastavampaa, mitä monipuolisempi sovellus on kyseessä, mitä kauemmin se on ollut tuotannossa, ja mitä vaihtelevammin ja vaihtelevimmissa olosuhteissa sovellus toimii. Kun suosittu sovellus on tullut vuoden ikään, se on tyypillisesti jo päivitetty muutamaan kertaan. Käyttäjillä on käytössä eri versioita, käyttäjät ovat erilaisia, ja heillä on erilaisia mieltymyksiä ja tottumuksia, jotka voivat olla osin ristiriitaisia muiden käyttäjien tottumusten kanssa.

Parhaiden sovellusten tekijät ja julkaisijat ottavat nämä asiat huomioon. He ovat varautuneet ottamaan sovellukseen liittyvää palautetta ja kritiikkiä vastaan, seuraamaan jatkuvasti eri sovellusversioiden toimintaa ja julkaisemaan korjauksia kun vakavia virheitä esiintyy, tarvittaessa nopealla aikataululla julkaisulaadunvarmistuksen kärsimättä. Palkkana kaikesta varautumisesta ja tottuneesta prosessista on käyttäjän kokeman laadun jatkuva paraneminen ja sovelluksen lunastama paikka arvostettuna ja suosittuna käyttäjien ajan tai rahan vastineena.