Feature managerin heiniä

23. lokakuuta, 2009
| Ohjelmistotestaus
|Kirjoittaja: Antti Niittyviita

Suurissa tuotekehitysprojekteissa on usein suuri organisaatio. Tuotekehityksen osista vastaavilla hepuilla on kiinnostavan kuuloisia titteleitä, kuten feature manager. Miten nämä kaverit sitten liittyvätkään testaukseen?

Tyypillisestä tuotekehitysorganisaatiosta löytyy tuotevastuuta kantavat johtajat, yksittäisten projektien tai ominaisuuksien vastuuta kantavat johtajat ja sitten itse tekijät. Tekemisen todellisista tuloksista annettavat näytöt organisaatiossa ylöspäin ovat usein kivoja käppyröitä ja diagrammeja. Metriikoita, joilla mitataan työn hyvyyttä.

Väitän, että metriikat kuvaavat sitä suppeammin todellisuutta mitä korkeammalle tieto matkustaa. Aivan kuten lasten pelissä “rikkinäinen puhelin“.

Usein alas ammutuissa projekteissa tekijät tietävät tuleeko tuotteesta mitään jo kauan ennen kuin ratkaisu johtoportaassa on edes tehty. Minusta tämä on vahva merkki siitä, että informaation kulku takkuilee. Kommunikaatio ei pelaa.

Ei varmasti tarvitse kovin pitkään pohdiskella mistä informaatio projektin hyvyydestä nykyisin tulee? Mitkä ovat ne metriikat, jotka kulkeutuvat organisaatiossa aina ylöspäin?

Olin kerran projektissa, jossa testaustiimini vastasi joukosta tuoteprojektin yksittäisiä ominaisuuksia. Perinteisen testaustavan mukaan meillä oli isot testispeksit tarkkojen tapauskuvausten kera. Virheitäkin löytyi ja niistä raportoitiin aktiivisesti. Testiraportit sisälsivät listauksen löydetyistä uusista virheistä ja testauksen perusmetriikat. Perusmetriikkaa olivat testien läpäisyprosentti suhteessa kaikkiin suunniteltuihin tapauksiin sekä suhteessa ajettuihin tapauksiin. Lisäksi mitattiin skipattujen testitapausten määrää ja syitä.

Organisaatiossa ylempänä mitattiin tuotteen kypsyyttä nimenomaan testien läpäisyprosentin tai maturiteetin perusteella. Läpäisyprosentit koko projektin ajan olivat heikot suhteessa tavoiteltuun 95%:iin. Todelliset testien tulokset olivat jossain välillä 40%-80% eivätkä ne kasvaneet kuten toimivassa projektissa tyypillisesti. Projektin aikana vakiintui käytännöksi katselmoida osa-aluekohtaisesti testitulokset “feature managerin” kanssa.

Katselmoinnin lopputuloksena hyvin usein fail statuksen saaneita testitapauksia väännettiin pass statukseen ja merkittiin testitapauksen kommentteihin: “Vika huomioitu. Korjataan seuraavaan releaseen”. Toinen vaihtoehto oli muuttaa testitapausta siten, että faili saatiin väkisin passiksi.

Ensimmäinen vääristymä testituloksiin siis tapahtui jo näin aikaisessa vaiheessa. Onko siis tässä tilanteessa minkäänlaista syytä olettaa, että lisää vääristymiä ei tapahdu myös viestin edetessä pidemmälle?

Tuotteen kypsyyden arvioiminen läpäisyprosentin perusteella ei perinteisessä hierarkisessa organisaatiossa toimi. Läpäisyprosentti on juuri niin hyvä kuin yhdessä sovitaan. Korjaavat toimenpiteet ovat varmasti jokaisen tiedossa.

Hyväksy tulokset sellaisina kuin ne testauksesta saadaan. Kommunikoi asiat avoimesti koko organisaatiossa. Ole avoin äläkä kiillota tuloksia. Käytä niitä tuotteen ja toimintatapojen parantamisvälineenä.