Suorituskykymittarit ja testaus
Törmäsin vasta kiinnostavaan Twitter-keskusteluun. Kaksi johtavassa roolissa olevaa testausgurua pohtivat sitä, miten järjestää testaukseen liittyviä suorituskykymittareita(KPI) organisaatiolle, sillä organisaatio vaatii sellaisia.
Ihan ensimmäisenä mieleen tuli kysymys. Jos organisaatio vaatii sellaisia, niin tosiasiassa organisaatiossa on yksi tai muutamia ihmisiä, jotka niitä vaativat. Minua kiinnostaisi kovasti tavata heidät. Ketä he ovat?
KPI-mittareita toivovilla ihmisillä aika usein on jo olemassa valmis käsitys siitä, mitä he haluaisivat mitata ja miksi. Helpointa olisi kysyä.
Jos mitään muuta ei ole tehtävissä kuin rakentaa esitys aiheesta, suosittelen jotain yksinkertaista ja konkreettista. Esimerkiksi voisin aloittaa tekemällä kirjanpidon asioista, joiden parissa vietän enimmäkseen aikani. Tuntitason resoluutio voi olla aivan hyvä tähän tarkoitukseen.
- Valmistelen: Viritän ympäristöjä, tuotan dataa tai dokumentoin.
- Testaan: Metsästän bugeja tähän tarkoitukseen sopivalla tavalla.
- Tutkin: Havaintojeni perusteella tutkin ja raportoi virheitä.
- Aivokuolen: Istun palavereissa. Osassa minua saatetaan tarvita. Useimmissa oikeasti ei. Keräilen KPI -dataa sieltä täältä ja louhin sitä Excelissä näyttävämpään muotoon jne.
Viikon lopussa alkaa kuva hahmottua. Missä työlajissa vietän eniten ajastani ja missä sitä tulisi viettää, jotta kollegat, esimehet ja asiakkaat saisivat enemmän hyötyä irti testauksestani?
Jos enimmäkseen valmistelen ja säädän, se voi tarkoittaa että kehittäjien kanssa on syytä panostaa seuraavaksi testattavuuteen. Jos enimmäkseen tutkin ja raportoin bugeja, se voi tarkoittaa että softa ei ole kovin kypsällä tasolla. Jos istun enimmäkseen palavereissa ja kerään KPI-dataa, se voi tarkoittaa että organisaation vaatimukset eivät ole linjassa todellisten tavoitteiden kanssa.
Tiedon kerääminen voi tuntua aluksi tarpeettomalta. Mutta kuvitellaanpa tilanne, missä joudut perustelemaan työsi tulokset pomolle? Mikä olisi mittaustuloksia parempi tapa iskeä faktat tiskiin?
Haastan sinut. Mitä touhusit tämän viikon?
Suosittelemme myös:
Ei testaaja tähti ole
Mitä tapahtuu, jos softaprojektista tulee vallan ja ylpeyden pelikenttä? Kun jokainen leiriytyy omaan kahvipöytäänsä ja toisia katsellaan vain...
Testaus ei taputtele selkään
Liiketoiminnan kehittämiskonsultin tehtävä ei ole taputella asiakasta selkään ja sanoa, että tässä firmassa on hommat hyvin hoidossa....
Testaus on epäeroottinen bisnes
Ohjelmistotestaus on ihan hemmetin epäeroottinen bisnes. Miksi ihmeessä se ketään kiinnostaisi? Testauspalvelu on kallista ja sen takaisinmaksua...
Minä lähden siitä, että testauksen tulos on aina bugi ja kaikki tarvittavat johtopäätöksen ja statistiikat johdetaan siitä. Jos testaus tekee jotain muuta kuin metsäsätää bugeja, niin jossakin on vikaa muuallakin kuin ohjelmistossa.
Tavanomaiset projektiin kuuluvat tapahtumat ovat osa myös testaajan päivää, mutta niiden tulee olla niin vähäisessä roolissa, että sillä ei ole lopputuloksen kannalta merkitystä. Testaaja testaa eli metsästää bugeja.
Sitten kun niitä bugeja on löydetty, niin on päätelmien aika kuten kuinka paljon tai vähän bugeja osa-alueelta löytyi ja missä ajassa. Mikä on bugien laatu erilaisista perspektiiveistä tarkastetuna kuten tekninen merkitys ja merkitys loppukäyttäjälle.
Jos testaaja tai testipäällikkö viettää ison osa ajastaan testisuunnitelman tai testitapausten dokumentointiin, niin metsään menee sellainen paketti. Ainoa dokumentaatio josta testaajan tulee todellakin pitää huolta, on bugien dokumentointi.