Mites se mobiili?

Kun itse ensimmäisen kerran päädyin testaamaan selainkäyttöistä sovellusta, ohjeena oli testata Firefoxilla ja IE:llä. Edelleen osassa projekteista testausta rajataan tältä pohjalta, mutta tilanne on muuttumassa, ja varmaankin jo nyt monissa projekteissa tällainen rajaus perustuu tottumukseen, ei analysoituihin tarpeisiin.

Mobiili ei ole tulevaisuutta. Se on tätä päivää.

Testaajilla lienee aina ollut haasteena perustella palkkansa maksajalle, miksi testaus vie niin paljon aikaa. Moni asiakas kokee, että järjestelmätoimittajan testaus maksaa liian paljon, eikä organisaation omaan testaukseen ole mahdollisuutta varata tarpeeksi aikaa. Tämä tilanne ei mobiilin myötä ainakaan helpotu, ja sen joka haluaa olla osa tulevaisuuden kaupankäyntiä, on syytä ymmärtää ainakin jollain tasolla, miksi testaamisesta täytyy maksaa entistäkin enemmän.

Siinä missä pöytäkoneella käytettävän järjestelmän toimiminen "kaikilla selaimilla" tarkoittaa testaamista noin kymmenellä selaimella (mikä sekin on paljon), järjestelmän toiminnan varmistaminen kaikilla mobiililaitteilla ei ole mahdollista. Harvalla projektilla on resursseja hankkia kaikkia markkinoilla olevia laitteita, saati testaajia käyttämään niitä niin, että perusteellisen testikierroksen tulokset saataisiin projektin aikataulun puitteissa. On siis paitsi panostettava entistä enemmän testaukseen, myös tehtävä valintoja, mitä ja millä testataan ja kuinka perusteellisesti.

Jos kysymys on esimerkiksi asiakasyrityksen sisäiseen käyttöön tulevasta järjestelmästä, tehtävä on kohtuullisen helppo, koska järjestelmän ei välttämättä tarvitse toimia muilla laitteilla kuin niillä mitä tämä yritys hankkii henkilöstölleen työvälineiksi. Julkisen palvelun taas olisi oikeastaan hyvä toimia kaikilla laitteilla, tai ainakin niistä yleisimmillä. Jos loppukäyttäjä ei pääse käsiksi kaipaamaansa tietoon tai vaikkapa verkkokaupan toiminnallisuudet eivät toimi hänen käyttämällään laitteella, hän käyttää rahansa jossakin muualla.

Mobiililaitteista olisi siis löydettävä setti, joka on riittävän edustava varmistamaan palvelun toiminnan valtaosalla sen potentiaalisista käyttäjistä. Ja projektin aikataulutuksessa ja budjetoinnissa pitäisi ottaa huomioon se työmäärä, joka vaaditaan riittävän perusteelliseen testaamiseen näillä laitteilla.

Mobiilitestauksen haasteet eivät pääty tähän. Jos sitä ei muisteta projektikäytännöistä sopiessa, saattaa käydä niin, että esimerkiksi tietoturvasyistä tehtyjen rajauksien vuoksi mobiililaitteilla ei ole käytännössä mahdollista päästä käsiksi testattavaan ympäristöön. Näiden ongelmien ja niihin liittyvien vastuiden setviminen vie myös aikaa.

Sekä laitehintoihin että IP-rajauksiin liittyviä ongelmia voidaan kiertää käyttämällä emulaattoreita. Kuinka hyvin niillä tehty testaus sitten vastaa testausta todellisilla laitteilla - sitä voi joskus olla vaikea tietää. Lisäksi emulaattoreiden löytäminen kaikille oleellisille laitteille voi sekin olla haasteellista, ja sen jälkeenkin on vielä käytettävä aika siihen testaamiseen.

Mobiilitestaus on siis väistämättä kallista, mutta sen laiminlyönti voi tulla paljon kalliimmaksi. Mitä myöhemmässä vaiheessa ongelmat ilmenevät, sitä kalliimpaa on niiden korjaus, ja kaikkein kalleimpia ovat tuotantokäytössä ilmenevät virheet.


ps. Mobiilisivusto ei testaamalla pelastu, jos sen suunnittelussa ei ole osattu huomioida käytettävyyttä eri tyyppisillä päätelaitteilla.

Muutoshallintaa v-käyrällä

Projektipäällikkö raahusti hiuksiaan haroen ja raskaasti huokaillen testaajan työpisteelle.

"Istuhan alas", testaaja kehotti. "Mitäs meidän projektille kuuluu? Stabilointivaiheen piti muistaakseni alkaa pari viikkoa sitten, joko nyt vihdoin alkaisi olla jotain testattavaa?"

Projektipäällikkö huokaisi taas syvään.

"Ei ole vielä tarpeeksi valmista," hän vastasi. "Ja itse asiassa nyt on sellainen tilanne, että pitäisi keskustella testauksen määrästä."

"Niin, arvioin silloin projektin alkaessa, että riittävä testaus voisi onnistua kolmen viikon työllä. Se todettiin jo silloin hieman optimistiseksi arvioksi, mutta haluttiin minimoida kustanuksia. Projektin ongelmat tietysti indikoivat, että se ei välttämättä riitä."

Projektipäällikön ilme muuttui entistä tuskaisemmaksi.

"Mutta kun projektin aikataulu ei jousta! Etkö voisi testata vähän nopeammin?"

"No tietysti voidaan vielä priorisoida testitapauksia ja karsia pikkuisen eri päätelaitteilla ja selaimilla tehtävää testausta, mutta se tietysti kasvattaa riskejä. Varmaan kahdessa ja puolessa viikossa saisi jo kohtuullisen käsityksen riskitasosta, vaikka laadun takaaminen voikin olla mahdotonta. Ja aikatauluhan riippuu pitkälti myös siitä, miten nopeasti korjaukset etenevät."

"Minä ajattelin ennemminkin, että jos kuitenkin vaan ottaisit pari päivää ja kliksuttelisit sen läpi? Ei mentäisi niin virallisesti."

"Oletko tosissasi? Meillä on testattavana kymmenkunta prosessikulkua variaatioineen viidellä eri selaimella, tabletilla ja älypuhelimella. Jo siihen kolmen viikon työmäärään liittyy tietyn riskitason hyväksyminen. Ja miten se aikataulu nyt voi olla noin tiukka, kun testaussuunnitelmaa tehtäessä sen kolmen viikon työn jakaminen kuuden viikon jaksolle ei ollut mikään ongelma? Nyt ollaan vasta kaksi viikkoa myöhässä, tai kohta siis kolme viikkoa. Eikö sitä testausaikaa pitäisi olla vielä kolme viikkoa jäljellä?"

"Unohdin kertoa sinulle, että koulutuksia piti aikaistaa kahdella viikolla. Eräillä avainhenkilöillä osui lomat siihen hankalasti, ja sitten oli seminaarimatkoja. Pitäisi saada valmista sitä ennen."

Testaaja veti syvään henkeä ja nojautui tuolissaan taaksepäin.

"Yritätkö siis sanoa, että softa ei ole vielä tarpeeksi valmis testattavaksi, mutta ensimmäiset koulutukset ovat jo kahden viikon kuluttua?"

"Niin."

Hetken aikaa kuului vain ilmastoinnin vaimea humina.

"No, periaatteessa tilanne saattaa olla pelastettavissa, jos voin valjastaa koko testaustiimin työhön, ja pääsemme aloittamaan vielä tällä viikolla. Täytyyhän siellä joku kokonaisuus kohta olla testattavissa, ette kai te kaikkea ole tehneet yhtä aikaa."

Projektipäällikkö vinkaisi hiljaa, muttei sanonut mitään.

"Mutta korjausten pitäisi sitten edetä tosi nopeasti, tai muuten me vain dokumentoimme syyt, joihin koulutus tulee kaatumaan. Ja tietysti sen pitää olla hyvin koodattu, että se saadaan käytännössä yhdellä korjauskierroksella kuntoon. Aika ei mitenkään riitä nyt bugi-pingikseen."

"Ei onnistu, budjetti ei anna myöten."

"Miten niin ei anna myöten? Piti olla mahdollisuus käyttää testaamiseen kolme viikkoa työaikaa."

"Mutta tässä on nyt ollut vähän kaikenlaista, on tullut yllättäviä kustannuksia. Muista projekteista aiheutuvien resursointiongelmien vuoksi tätä on nyt tehty aika takapainotteisesti, ja siksi projektiin piti ottaa mukaan odotettua suurempi joukko kehittäjiä. Osa on ollut vähän kokemattomia, työ on edennyt hitaasti ja ovat tarvinneet suunniteltua enemmän ohjausta. Hommia on myös jouduttu vaihtamaan tekijältä toiselle, kun on pitänyt priorisoida työskentelyä eri projektien välillä. Yksi päivä meni hukkaan, kun integraatioympäristö asennettiin ensin väärin. Pari päivää meni kun piti kaivaa yhden sairaslomalle jääneen kehittäjän koneelta, mitä hän oli ehtinyt tehdä. Ja sitten yksi kone hajosi, eikä ollut varmuuskopiota. Ja..."

"Eli kun koodarit säätävät, testaus maksaa?"

"Maksaa ja maksaa, asiakashan se tästä maksaa. Tai meidän firma, asiakas ei suostu maksamaan enää yhtään enempää."

"Tiedätkö, miten kalliiksi tuotantokäytössä löytyvät bugit tulevat? Tai miten paljon työläämpää on tulkita ja hallita keskivertoasiakkaan bugiraportteja kuin meidän omien ammattitestaajien bugiraportteja? Mitä tulee koulutuksesta, kun softa ei toimi? Tai miten vaikuttaa asiakastyytyväisyyteen tai käyttäjien muutosvastarintaan, jos aloitetaan keskeneräisellä järjestelmällä?"

"No en minä voi kehittäjiltäkään sitä työaikaa nipistää, kun ei siitä järjestelmästä tule valmista ilman heidän työtään."

"Ja mikä saa sinut kuvittelemaan, että he saavat sen käyttökuntoon ilman että sitä testataan? Kuule maailmassa on aika paljon hyvää tuotekehitystä mennyt hukkaan, kun puutteellisen testauksen takia softaa ei ole saatu riittävään kuntoon, että sitä oikeasti voisi käyttää."

"Noh, tuskin tästä nyt sen luokan katastrofi on tulossa."

"Minusta kuulostaa, että sinulla on tässä projektissa toteutunut aika merkittävä määrä riskeistä. Sillä on väistämättä aikataulu- tai kustannusvaikutuksia, usein molempia."

"Mutta kun asiakas ei tule hyväksymään korkeampaa hintaa eikä viivästettyä aikataulua!"

"Ei se järjestelmä tunne projektin aikataulua, se valmistuu tekemällä ja testaamalla. Jos hintaa ja aikataulua ei voi venyttää, niin ominaisuuslistaa tulee pienentää."

"Sinä et tunne tätä asiakasta, eivät ne tule suostumaan... Eikä se tällä aikataululla onnistuisikaan. Sitä paitsi kaikki on melkein valmista, joten olisi tyhmää jättää mitään kesken."

Laskeutui hiljaisuus. Ilmastoinnin humina tuntui painostavana. Projektipäällikkö painoi päänsä käsiinsä ja huokaisi syvään.

"Mitä tässä sitten sinun mielestäsi tulisi tehdä?"

Testaaja katsoi ulos ikkunasta. Aurinko paistoi.

"Lähdetään kaljalle."

"Mitä, nyt on keskiviikkoiltapäivä?"

"Joo joo. Sulla on varmasti jo viikon tunnit täynnä, etkä pysty nyt edistämään mitään. Mennään kaljalle."

"Mutta eihän se käy!"

"No tietysti se käy. Otetaan mukaan kynää ja paperia ja suunnitellaan yhdessä kriisiviestintä. Kun sitten aamukrapulassa soitat asiakkaalle, kuulostat niin autenttisen katuvalta ja uupuneelta, että ne kyllä leppyvät."

Hetken hiljaisuus.

"Absurdia, mutta tuossa saattaa olla järkeä..."

"Joo joo. Enemmän kuin monessa asiassa, mitä tänään on tullut vastaan."