torstai 10. lokakuuta 2013

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.

Ei kommentteja :

Lähetä kommentti