Uutinen -

Testaus 2013 – herättäviä tarinoita testauksen merkityksestä liiketoiminnalle

Tieturin Testaus 2013 -tapahtuma keräsi yhteen n. 150 ohjelmistotestauksen ammattilaista. Osallistujajoukosta noin puolet edusti testaajia, puolet testausta johtavia, olipa mukana jokunen valistunut ohjelmistokehittäjäkin. Tilaisuuden päätteeksi julkistettiin Vuoden Testaaja 2013.

Tilaisuuden puheenvuoroissa pohdittiin ohjelmiston laadun ja testauksen kehittämisen vaikutuksia kustannuksiin. Testausprosessin laadun vaikutusta ohjelmistotuotteen laatuun ei ymmäretä riittävän hyvin. Jos testausprosessi on huono, myös ohjelmistotuotteen laatu on kehno. Yhteyttä ei vain ymmärretä eikä testauksen kehittämiseen investoida riittävästi. Testausammattilaiset eivät välttämättä puhu liiketoiminnan ymmärtämää kieltä, joten liiketoiminnan ymmärrys ei kasva ennenkuin vahinko on tapahtunut.

Tietoisuutta testausprosessin merkityksestä mm. asiakastyytyväisyyteen on nostettava. Huonosti testattu ohjelmisto aiheuttaa merkittäviä riskejä liiketoiminnalle. Ohjelmistojen ollessa osa liiketoimintaa, säästää laadukas testausprosessi sekä asiakkaan että toimittajan varoja.

Reporting Software Quality – It’s a Risky Business

Testaus 2013 -tapahtuman key note -puhuja testausalan konkari Mark Fewster tunnetaan mm. testausautomaatiokirjoistaan. Tällä kertaa Mark käsitteli ohjelmiston laadun raportointitapoja havainnollisesti ja hauskasti.

Mark totesi, että tyypillinen tapa raportoida ohjelmistovirheiden määrää kertoo enemmän ohjelmiston laadusta ennen testausta kuin asiakkaalle luovutetun ohjelmiston laadusta. Jotta tietäisimme, miten hyvä ohjelmisto on, meidän pitäisi ensin tietää, miten hyvin testaus on tehty. Luovutetut ohjelmistot sisältävät tyypillisesti paljon tuntemattomia vikoja. Kun alamme raportoida vikojen löytämisen tehokkuutta pelkkien vikamäärien sijasta, pystymme jatkossa ennustamaan luovutushetkellä jäljellä olevat potentiaaliset viat. Muuttamalla raportointitapaa pystymme kertomaan enemmän luovutetun ohjelmiston laadusta.

Vaihtoehtona virheitä raportoivalle tavalle Mark tarjoaa mm. liiketoiminnan riskien ja hyötyjen tunnustamisesta lähtevää testausta. Riskiohjatussa testauksessa riskit muodostavat mittarin, jolla voimme osoittaa, miten hyvin ohjelmisto on testattu. Näemme, miten monta ohjelmiston liiketoiminnalle aiheuttamaa potentiaalista riskiä testauksella on kyetty vähentämään. Testauksella pienennetty riskien määrä on ymmärrettävämpi mittari kuin ohjelmistosta löydettyjen vikojen määrä, kun puhutaan liiketoiminnan edustajan kansa. Raportoi siis saavutettuja hyötyjä ja vähennettyjä riskejä, älä vain löydettyjä virheitä.

Näkökulmia hyväksymistestaukseen

Hyväksymistestauksella varmistetaan, että lopputuoteen laatu ja ominaisuudet ovat riittävän hyvät julkaisua varten. Toisin kuin kehitysaikaisessa testauksessa, hyväksymistestauksessa ei toivota löydettävän virheitä, joiden korjaaminen maksaa paljon ja viivästyttää julkaisua.

Tieturin asiantuntijalla Petri Säilynojalla on 15 vuoden kokemus testauksesta ja sen johtamisesta. Hän johdatteli yleisön hyväksymistestauksen haasteisiin kuvaamalla kohtaamiaan käytännön caseja. Petri peräänkuulutti hyväksymistestaukseen kannustavaa yrityskulttuuria. Hyväksymistestausta tekevät usein henkilöt, joiden varsinainen työtehtävä ei ole testaus. Hyväksymistestaus koetaan usein rangaistuksesi ilman palkkiota, ellei hyväksymistestausta osata koordinoida ja motivoida oikein liiketoiminnassa.

Testauksen väheksymisestä saattaa seurata jopa hyväksymistestauksen ulkoistaminen toimittajalle ja oman vastuun pakoilu. Petrin näkemyksen mukaan käyttötapaukset ovat keino kohdistaa testausta. Hyväksymistestaajalla tulee olla selkeä käsitys koko testattavasta kohteesta. Hyväksymistestaajien tulisi myös paremmin ymmäärtää se, että tavoite on hyväksyä ohjelmistotuote, ei etsiä mahdollisimman montaa vikaa.

Laatupäällikkö Antti Auer (Op-Palvelut) paneutui ketteryysnäkökulmaan hyväksymistestauksessa. Antti tähdensi siitä, että ketterässä ajattelussa tuottava tiimi kykenee itsenäisesti hoitamaan tuotteen alusta loppuun, mukaan lukien kaiken testauksen ja ylläpidon. Kun mukaan tulee alihankintaa, ei malli toimikaan enää aukottomasti. Jos eri osapuolet tekevät kehityksen ja toiset testauksen, kokonaisuus ei enää olekaan ketterä. Näin käy helposti hyväksymistestauksessa.

Eräs avainkysymys onkin: Miten saadaan tuotekehitykseen ajoissa riittävää näkyvyyttä ja muutoshallintaa, jotta hyväksymistestauksessa ei löydy enää vikoja? Ratkaisuja on monia. Mm. hyväksymistestausympäristö kannattaa pitää mahdollisimman samanlaisena kuin tuotantoympäristö, hyväksymistestaus kannattaa aloittaa ajoissa, tuotteen omistajan pitää olla valtuutettu tekemään päätöksiä koko tuotteen elinkaaren ajan. Ketterään wiki-dokumentointiin kannattaa panostaa ja tekninen velka on tehtävä näkyväksi jokaisella kehityskierroksella. Vaikka hyväksymistestaus onkin haastavaa, voi se Antin näkemyksen mukaan olla osa ketterää kehitystä.

Testausprosessin parannus – business case

Tapani Aaltio (Manager, Sogeti) tietää, että testausprosessin kehittäminen tuo huomattavaa kilpailuetua. Hän kokee, että testausprosessin laatuun ei satsata yrityksissä riittävästi osittain siksi, että tetaajat eivät kykene kertomaan muille osapuolille, mitä konkreettista hyötyä parannetuista prosesseista on. Testaajat kyllä tietävät, että testausprosessien kypsyyttä parantamalla tuotteiden laatu paranee, kustannukset pienevät ja kehitysaikakin lyhenee. Silti testauskäytäntöjen parantamiseen tarvittavien investointien perustelu on vaikeaa. Mitä tehdä, että päättäjätkin uskovat?

Tapani ehdottaa ratkaisuksi TPI (Test Process Improvement) -arviointimallin käyttöä. Mallin avulla testausporsessit voidaan arvioida ja prosessikehityksen hyöty voidaan osoittaa ROI (Return on Investment) -laskelmalla. Tätä kieltä päättäjätkin ymmärtävät. Eri tutkimusten mukaan laadunvarmistuksen ja prosessikehityksen ROI on varsin korkea. Eri tahojen arviot vaihtelevat, uskottavalta tuntuu arvio, jonka mukaan yksi panostettu euro tuo seitsemän takaisin, joten kehittäminen kannattaa.

Parasta, mitä testaukselle on tapahtunut sitten viime kerran

Tapahtuman viimeinen puhuja oli Vuoden Testaaja 2012 Antti Niittyviita (toimitusjohtaja, Prove Expertise). Antti pohjasi lennokkaan esityksenä viimeisen vuoden aikana Suomessa tapahtuneisiin mega-luokan virheisiin testauksessa. Antin mielestä näissä caseissa on parasta se, että testauksen merkitys ja laatu on nostettu keskusteluun ja testausta on viimeinkin alettu arvostaa.

Antin keskeinen huolenaihe on silti johdon erkaantuminen liiketoiminnasta. Case-esimerkit osoittivat, että organisaatio voi panostaa satoja tuhansia euroja esimerkiksi markkinointikampanjaan, joka loppu viimein onkin vahingollinen yrityksen imagolle. Kampanja saattaa olla varsin onnistunut markkinointikampanja, mutta linkit vievät palvelimelle, joka ei kestänytkään kampanjan suuren suosion aiheuttamaa kävijämäärää. Kuormitustestaus on jäänyt tekemättä, kaatuneella sivustolla käyvät asiakkaat ovat harmissaan ja muistavat pettymyksensä palvelun huonoon tasoon.

Antin puheenvuorosta opimme, että testaajan tärkeä tehtävä on parantaa liiketoiminnan kannattavuutta. Testaajien tulee oppia puhumaan kieltä, jolla he voivat osoittaa johtajille ja liiketoiminnan edustajille testauksen merkityksen myös liiketoiminnan kannattavuudessa.

Vuoden Testaaja 2013

Tilaisuutemme päätettiin perinteiseen tapaan julkistamalla Vuoden Testaaja 2013 -arvonimen uusi haltija. Julkistukseen osallistui TestausOSYn edustaja Sami Söderblom ja Tieturin edustajana allekirjoittanut. Yleisö oli ehdottanut seitsemää ehdokasta, joista kolme eniten ääniä saanutta julkistettiin aakkosjärjestyksessä. Tänä vuonna voiton vei Minna Aalto (Knowit). Minna luonnehdittiin monin ylisanoin, tässä kaksi osuvaa poimintaa:

”Minna on hieno ihminen, loistava kouluttaja ja intohimoinen laadunvarmistuksen puolestapuhuja.”
”Minna Aalto on ilolla ja huolella työnsä tekevä asiantuntija!”

Sydämelliset onnittelut Minnalle!

Testaus 2013 oli jälleen tapahtuma täynnä opettavaisia tarinoita. Kiitokset upealle yleisöllemme aktiivisuudesta, kiitokset myös kumppaneillemme Sogetille ja FiSTB:lle! Tervetuloa mukaamme jälleen huhtikuussa 2014!


Aiheet

  • Koulutus

Kategoriat

  • testaus
  • ohjelmistokehitys
  • vuoden testaaja