Mobiilisovellusten testaus: Käytännön vinkkejä ja kokemuksia

Jimi Hendrix -vainaa keksi aikanaan lähestyä instrumenttiaan sen eri kulmista, milloin niskan takaa tai polven alta soittaen, ja joskus lähti kipakka soolo hampaillakin. Tuikkasipa maestro Stratocasterinsa kerran palamaankin keikallaan 1967 Montereyssa. Ja äimistynyt kansa hurrasi.

Aivan kuten Henkalle Fender Stratocaster, tarjoaa mobiililaite ohjelmistotestaajalle herkulliset lähtökohdat lähestyä mobiilisovellusta mitä mielikuvituksellisimmista testauksen näkökulmista.
Noh, toistaiseksi ei ole vielä tullut sytytettyä mobiililaitetta tuleen, mutta teen sen kyllä, mikäli se tuottaa työssä menestymiselle lisäarvoa!

Vietin liki yhden työpäivän miettien, mitä keskeisiä mobiilisovellusten testaukseen liittyviä menetelmiä ja näkökulmia on tullut vuosien saatossa sovellettua.

Kertaan tässä artikkelissa myös aiemmasta artikkelistani Mobiilipankkisovelluksen tutkivasta testauksesta tutuiksi tulleita asioita, mutta tietyt seikat vain kuuluvat tähän aiheeseen ja kertaus on opintojen äiti!

Mobiililaitteiden valtava laitekirjo

Noh, Android itsessään on sellainen suo, jonka lakkoja (tai hilloja) ovat erilaiset laitteet, näytöt, resoluutiot ja käyttöjärjestelmäversiot. Tämä tarkoittaa sitä, ettei yhdelläkään testaajalla ole sellaista ämpäriä, johon jokainen marja saataisiin suolta poimittua. Vähemmälläkin saadaan silti kiisseliä pöytään. Jos testauksen vaatimuksissa kuitenkin koetaan välttämättömäksi käydä läpi kymmeniä tai jopa satoja erilaisia testilaite- ja käyttöjärjestelmäkomboja, on syytä tarkastella siihen vihkiytyneitä palveluita, kuten erilaiset mobiililaitepilvet tai Applause.

Tyypillisessä mobiilitestausprojektissa työpöydälläni makaa yleensä 3–5 erilaista Android-laitetta eri Android-versioineen, joilla suoritan ytimekkäämmän testauksen. Lisäksi pyrin viemään tiimille selkeää viestiä siitä, että buildien testaukseen voisi osallistua kaikki kynnelle kykenevät, edes yleisellä tasolla ja vaikka sitten hyväksymistestausvaiheessa. iOS-maailmassa pärjätään yleensä vähemmällä, koska Applella on tiukemmin hallittu kokonaisuus laite- ja järjestelmäkirjossaan. Applen osalta ongelmat tulevat eri näyttökokojen välillä ja joissain tapauksissa iOS-versioiden välillä. Yleensä olen testannut 2-3 laitteella, mutta toki iOS-testausta suoritetaan projektin sisällä myös muiden toimesta.

Mobiilisovellusprojekteissa onkin hyvä tapa julkaista sovellus ensin beta-versiona rajoitetulle käyttäjäryhmälle, jolloin beta-käyttäjiltä saadaan kaikenlaista palautetta havainnoista, mahdolliset laiteyhteensopivuudet mukaan lukien. Mutta valitettava tosiasia on se, että täysin aukotonta yhteensopivuustestausta on liki mahdotonta toteuttaa, etenkään Android-sovelluksilla. Loppukäyttäjä on tässä yhtälössä laadunvarmistuksen viimeinen toimija.

Järjestelmäasetusten vaikutukset mobiilisovellukseen

• Käyttöjärjestelmän ominaisuudet. Kun sovellus hyödyntää käyttöjärjestelmän tarjoamia ominaisuuksia (capabilities), kuten vaikkapa kameraa, sijaintia tai yhteystietoja, sovellus tiedustelee käyttäjältä niiden käyttöoikeutta. On aina tarpeen kokeilla, mitä käyttöoikeuksien evääminen aiheuttaa sovelluksen toiminnalle ja tuottavatko ne käyttäjälle selkeät virhe- ja ohjeilmoitukset.
• Kielivalinnat: Vaikka sovellus ei olisikaan lokalisoitu eri kielille, on paikallaan minimissään tarkistaa sen toimivuus vaihtamalla järjestelmäkieltä vaikkapa edes englanniksi ja ruotsiksi. Itse kokeilen myös eri merkistöjä käyttävillä kielillä, kuten kiinaksi, japaniksi ja hepreaksi. Erityisesti RTL (Right To Left) -tyyppiset kielet, kuten persia, aiheuttavat joskus jänniä ilmiöitä käyttöliittymässä!
• Fonttikoko: Suunnittelijoiden painajainen on aina järjestelmän fonttikoon suurentaminen, joka usein aiheuttaa kummia käyttöliittymässä. Tämä kannattaa ainakin kertaalleen tarkistaa sekä käyttöliittymän että erityisesti heikkonäköisten loppukäyttäjien parasta ajatellen.
• Järjestelmän keskeytykset: Joskus järjestelmän puolelta tapahtuva keskeytys, kuten saapuva puhelu, toast-viesti tai muu äkillisesti sovelluksen toimintaa jollain tavalla häiritsevä tai keskeyttävä operaatio saattaa aiheuttaa sovellukselle hätätilanteen.
• Bluetooth ja oheisjärjestelmät: Mikäli sovellus hyödyntää järjestelmän mikrofonia saattavat Bluetooth-kuulokkeet tai autojen järjestelmät (esim. CarPlay) tuottaa yllättäviä havaintoja. On siis hyvä testata myös niiden parissa! Myös älykelloon tulevat notifikaatiot on hyvä tsekata.

Verkko-ongelmien testaus

Vaikka tänä päivänä mobiililaitteet ovat pääasiassa huippunopeiden verkkoyhteyksien äärellä, kohdataan edelleen tilanteita, joissa verkon tolpat vähenevät askel askeleelta. Sellaisissa tilanteissa vähimmäisvaatimuksena on sisäänrakennettu mekanismi, jonka avulla sovellus ilmoittaa käyttäjälle verkko-ongelmasta. Lisäksi erilaiset ‘handoverit’, kuten verkon vaihtuminen WiFistä mobiiliverkkoon ja toisin päin, kannattaa aina tarkistaa.

Esimerkki, kuinka erään kerran halusin etäolosuhteissa testata asiakkaan sovellusta heikentyvän verkkoyhteyden olosuhteissa

Käyttökokemus ja saavutettavuus ovat laadun osa-alueita

Yleensä testaaja ajattelee sovellusta eri näkökulmasta kuin sen suunnittelija tai kehittäjä. On tavallista, että testaajana annan palautetta ja vaihtoehtoisia ehdotuksia sovelluksen toimintalogiikkaan liittyvissä asioissa – vaikkei aiheeseen liittyisikään varsinaista ohjelmistovirhettä. Joskus palaute poikii muutoksen, joskus ei. Kommunikointi on silti aina paras laadun parantamisen työväline!

On tyypillistä, että suunnittelupöydälle palataan vielä useita kertoja sovelluksen testauksen aikana, koska erilaisia käyttökokemukseen ja saavutettavuuteen liittyviä seikkoja hienosäädetään. Tyypillisimpiä unohduksia ovat virhe- tai opasteilmoitusten puuttuminen tai niiden vaikeaselkoisuus, joiden kautta käyttäjän tulee saada selkeää lisätietoa ongelmatilanteissa. Lisäksi erilaiset visuaaliset tehosteet ja korostukset käyttäjän toimia odottavissa elementeissä ovat tärkeitä asioita käytön selkeyden nimissä.