Koskaan ei ole hyvä hetki

Yksi tärkeimmistä opetuksista, joka tarttui matkaani opinnoista TKK:lla, oli Esa Saarisen luennolta. Se kuului: jos odotat täydellistä hetkeä tarttuaksesi toimeen, et koskaan tule tekemään sitä mitä suunnittelet. Muutama vuosi sitten romaania kirjoittava ja taidenäyttelyä valmisteleva työkaverini muotoili saman ajatuksen hieman toisin: kun nainen tulee tiettyyn ikään, sitä ymmärtää että unelmien ei voi antaa enää odottaa jos ne joskus haluaa toteuttaa.

Tämän opin mukaan olen pyrkinyt elämään manageroidessani viisihenkisen perheeni aikatauluja ja sovitellessani siihen itselleni tärkeitä asioita. Koskaan ei ole täydellistä hetkeä, joten tärkeitä asioita on edistettävä aina kun siihen saa tilaisuuden.

Niinpä bussimatkani kuluvat kieliä opiskellen, kirjoja tai testausaiheisia artikkeleita lukien ja silloin tällöin myös blogia kirjoittaen. Tiskatessani saatan seurata youtubesta esim. BBST-luentoa. Kun valmistaudun puheeseen, harjoittelen sitä imuroidessani tai vaikka uidessani.

Moniajossa ja pätkittäin tekemisessä on tietysti huonotkin puolensa. Oppimateriaaleista saisi enemmän irti keskittymällä niihin täysillä. Kokonaisuudessaan aikaa menee enemmän tavoitteen saavuttamiseen kuin jos asian tekisi kerralla. Ja on asioita jotka eivät koskaan valmistu.

Kuitenkin, jos vaihtoehtona on olla tekemättä ollenkaan, oleellinen kysymys ei ole, oliko tämä paras tapa tehdä, vaan oliko tästä iloa.

Edes lopullisesti kesken jääminen ei aina ole pahasta. Esim. blogin kanssa ideaa täytyy alkaa jalostamaan tekstiksi ennen kuin voi tietää, tuleeko siitä jotain julkaisemisen arvoista. Ja se kirjoittamiseen liittyvä ajatustyö voi olla itselle arvokasta riippumatta siitä, julkaiseeko vai ei. Jos alkuperäiset tavoitteet eivät enää vaikuta mielekkäiltä, tavoitteet voi asettaa uudelleen.

Blogin kirjoittaminen ei vaadi erityistä nerokkuutta, se vaatii vain aloittamisen, ja sen että sinnikkäästi löytää hetkiä kirjoittamiseen. Eikä konferenssipuhujaksi tulla odottamalla täydellistä hetkeä ja täydellistä aihetta ja täydellistä uraa, vaan etsimällä aiheita jotka itse kokee jakamisen arvoisiksi ja tarjoamalla niistä puhetta tapahtumiin joihin haluaisi osallistua. Pahin, mitä yrittämisestä voi seurata, on että ei tule valituksi, ja silloinkin prosessista on voinut oppia jotakin.

Toinen pelottava skenaario on tietenkin, että tulee valituksi. Siksi onkin tärkeää valita aihe johon itse uskoo, ja johon ehtii käytettävissä olevan ajan puitteissa valmistautua. On myös tärkeää muistaa, että unelmia ei saavuteta muuten kuin yrittämällä uusia asioita, asioita jotka ovat oman mukavuusalueen ulkopuolella tai vähintään sen ulkoreunalla.

Jonglöörauksen keskellä on hyvä käyttää ajoittain hieman aikaa oman tekemisensä analysoimiseen. Tähän hyvän työkalun tarjoaa PROOF-malli, jota voi soveltaa tähän tapaan:

Past 

Kuinka käytit ajan, mitä teit ja edistikö se asiaa? Millaiset asiat ehkä häiritsivät keskittymistäsi?

Results

Mitä löysit tai sait aikaan? Voitko jakaa tämän jonkun kanssa jäsentääksesi ajatuksiasi aiheesta paremmin?

Obstacles 

Tarvitsetko apua tai työkaluja? Uusien asioiden opetteluun voi löytyä mobiilisovelluksia tai online-kursseja. Blogin kirjoittamiseen on oppaita, puhumiseen kursseja, hakemusten tekemiseen mentorointia.

Outlook 

Miten tästä eteenpäin, mitä vielä pitäisi tehdä? Voiko ajanhallinnallisesti jatkaa näin, vai onko asioiden prioriteetteja tarkasteltava jotta tärkeimmät asiat tulisivat tehdyksi?

Feelings 

Oliko tämä mielekästä? Onko tästä hyötyä tai iloa? Uskotko tähän? Kun kymmenen vuoden kuluttua katsot elämääsi taaksepäin, ovatko nämä niitä asioita joista voit olla ylpeä? Asioita joilla olet muokannut itseäsi positiivisella tavalla, tai luonut jotain hyvää tähän maailmaan? Mitä pidemmän tähtäimen tavoitteita tämä palvelee? 

Elämä on liian lyhyt pelkkään ajelehtimiseen ja valittamiseen.

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.

Miten testaus voi auttaa asiakastyytyväisyyden parantamisessa

Asiakastyytyväisyys on hankala suure. Sen mittaaminen on usein hieman epämääräistä, ja siihen vaikuttavien asioiden perusteellinen analysointi kenties vieläkin haasteellisempaa.

Asiakkaalle ihanteellista olisi saada hyvää halvalla nopeasti, vieläpä hyvällä palvelulla ryyditettynä. Mutta asiakkaan etu on myös se, että yhteistyökumppanien toiminta on kannattavaa, koska nappiin mennyt toteutusprojekti ei kauheasti lämmitä, jos ylläpidosta huolehtiva organisaatio katoaa.

Laadun tekeminen halvalla kannattavasti on haasteellista. Tämä pätee niin huonekaluostoksilla, ravintolassa kuin ohjelmistokehityksessäkin. Näiden tekijöiden optimointi asiakkaan parhaaksi - laatu, hinta, aikataulu, palvelutaso ja kannattavuus - ei ole ihan yksinkertaista. 

Testaus (hyvin hoidettuna) on yksi tapa vaikuttaa positiivisesti näihin kaikkiin.

Laatu

Testauksen vaikutus laatuun on kenties helpointa nähdä, puhutaanhan testaamisesta usein laadunvarmistuksena. Testaus ei kuitenkaan itse tuota laatua, vaan ennemminkin mittaa sitä, antaen laadun tekijöille eli järjestelmän määrittelijöille, suunnittelijoille ja toteuttajille informaatiota, jonka avulla lopputuloksesta voi tulla laadukas.

Järjestelmän käyttöönoton kannalta ohjelmiston laatu on usein keskeisempi asia kuin toteutusprojektiin liittyvät kommellukset, ja siksi laadunvarmistus on keskeinen tekijä asiakastyytyväisyydessä.

Muissa asioissa arkiajattelussa testauksen rooli ei ehkä ole yhtä ilmeinen.

Hinta

Testaus nähdään usein asiana, joka kasvattaa hintalappua. Näin asia onkin, jos testausta ei tehdä oikein, sillä kaikkien bugien kaivaminen esiin monimutkaisesta ohjelmistosta on ikuisuusprojekti. Päämäärätön ohjelmiston läpikliksuttelu ei myöskään välttämättä löydä oleellisimpia virheitä, vaikka aikaa siihen saa kulumaan ihan niin paljon kuin aikaa käytettävissä on.

Ammattitaitoisesti suunniteltu testaus ei kuitenkaan välttämättä kasvata kokonaishintaa verrattuna tilanteeseen jossa vain ollaan testaavinaan, vaan voi toimia jopa päinvastoin.

Testaajan osallistuminen jo määritysvaiheeseen dokumenttien katselmoinneilla sekä alustavien testitapauksien luominen ennen ohjelmiston toteutusta voi tehostaa muiden projektiin osallistuvien työskentelyä ja ehkäistä virheitä, vähentäen kokonaistyömäärää. Testaajan ammattitaitoa on myös mm. testitapauksien priorisointi, eli sen arviointi miten perusteellisesti mitäkin kannattaa tehdä, ja tätä kautta pystytään yhtä aikaa minimoimaan testaukseen kuluvaa aikaa ja maksimoimaan testauksen kykyä löytää merkittävät virheet.

Aikataulu

Toinen testauksen perusongelma on se, että siihen ei jää aikaa kun toteutus venyy.

Todellisuudessa asiantunteva testaaminen ei kuitenkaan viivästä projektia, koska järjestelmän käyttökelpoisuus ei riipu siitä, miten paljon testaajat ovat löytäneet bugeja, vaan siitä, miten paljon niitä oikeasti on. Testauksesta nipistäminen aikataulun nimissä johtaa helposti tilanteeseen, jossa stabilointivaihe venyy ja kuormittaa niin projektipäällikköä kuin kehittäjiä kohtuuttomasti, koska aikaa kuluu paljon asiakkaan löytämien bugien perkaamiseen, selittelemiseen ja hyvittelemiseen. Sen sijaan asiantuntevan sisäisen testauksen avulla on mahdollista siirtää projektin aikataulua hallitusti, kun ammattitestaaja pystyy auttamaan järjestelmän valmiusasteen ja stabilointivaiheen vaatiman aikataulun arvioinnissa.

Palvelu

Testauksen tuki aikataulun arvioimiseen, sekä tarvittaessa käyttöohjeiden luomiseen ja asiakkaan hyväksymistestauksen ja käyttönoton tukemiseen paitsi helpottaa projektipäällikön työtä, voi myös parantaa asiakkaan kokemusta saamansa palvelun laadusta. Näin jo siksikin, että testaajan avulla projektipäällikön on helpompaa keskittyä olennaiseen. Lisäksi testaajan tuominen asiakasrajapintaan voi parantaa asiakkaan kokemusta siitä, että hänen kokemansa haasteet ohjelmiston käyttöönotossa otetaan vakavasti.

Kannattavuus

Mitä toiminnan kannattavuuteen tulee, yksi näkökulma on tuotantokäytössä löytyvien bugien määrä ja laatu. Asiakkaan tai hänen asiakkaansa löytämän bugin korjaaminen on paljon kalliimpaa kuin bugin korjaaminen toimittajan itse tekemän stabiloinnin aikana. Ongelman selvittelyyn osallistuu silloin vähemmän osapuolia, kehittäjät ovat orientoituneet kyseiseen projektiin kun tekevät sitä muutenkin, ja lisäksi bugiraportti tarjoaa tyypillisesti paljon paremmat eväät ongelman syyn löytymiseen.

Tuotantokäytössä löytyviä virheitä ei välttämättä tarkastella yrityksen kustannuslaskennassa projektien kannattavuuden näkökulmasta, koska itse toteutusprojekti on ehtinyt jo päättyä. Yrityksen kannattavuuteen ja mahdollisuuksiin jakaa työ tekijöilleen tehokkaasti ne kuitenkin vaikuttavat. Merkittävien tuotantokäytössä löytyvien bugien pr-arvo on myös korkea, ja osa asiakkaista osaa myös vaatia ylläpitosopimuksia, joissa ongelmatilanteisiin liittyy sanktioita.