- 30.9.2015

Asiakas on kunkku myös laadunvarmistuksen näkövinkkelistä

Mitä paremmin onnistumme laadunvarmistuksessa, sitä parempi on myös asiakkaamme tuntema asiakaskokemus. Tätä asiaa käsiteltiin myös Testing Assembly –seminaarissa. Paikalla oli kolmisensataa testauksen, laadunvarmistuksen ja prosessien kehityksen ammattilaista. Tietyt teemat toistuivat puheenvuoroissa, joita olin kuuntelemassa:

1. Asiakaslähtöisyys

Tämä kuulostaa itsestään selvältä, mutta budjettien ja aikataulujen kiristyessä pitää erityisesti tietää, mikä asiakkaalle on kaikkein tärkeintä ja mistä asiakas ansaitsee tuloja. Eli jos ja kun on kiire, niin varmistetaan asiakkaalle liiketoimintakriittisimpien ominaisuuksien toiminta. Pitää myös nähdä laajasti, että keskitytään rajallisilla resursseilla oikeisiin asioihin.

2. Ketteryys

Ketteryys on tuttua kauraa ohjelmistoprojekteissa. Puheenvuoroissa painotettiin, että pitää olla ymmärrys mitä tehdään ja mikä on asiakkaalle oleellisinta. Näin osataan keskittyä kaikista tärkeimpiin asioihin ensin. Testauksen näkövinkkelistä ketteryys tarkoittaa Janet Gregoryn sanoin: ”agile testing is activity, not a phase” eli että ketterässäkään projektissa testausta ei voi jättää sinne viimeisen sprintin viimeiseen päivään.

3. Automatisoitu testaus

Regressiotestaus pitää saada automatisoitua. Myöskään yksikkötestauksen merkitystä virheiden löytämisessä ei voi vähätellä, kehittäjillä on oltava kunnon yksikkötestausympäristöt, joita käytetään tehokkaasti. Mikään automatisoitu testaus ei kuitenkaan korvaa tutkivaa testausta. Tutkiva testaus tulisi tehdä eri käyttäjäroolin mukainen hattu päässä: talousjohtajan, assistentin ja varastotyöntekijän käyttötavat samalle järjestelmälle voivat poiketa suuresti toisistaan. Vanha viisaus bugin hinnasta on edelleen täysin totta, mitä aiemmin bugi löydetään, sitä halvemmaksi se tulee.

4. Keep it real
  • Älä lupaa liikoja. Jos aikataulu on jo valmiiksi tiukka, älä lupaa ottaa vielä paria taskia lisää.
  • Pidä viestisi näkyvillä. Tämä on oma lempilapseni, en ole koskaan nähnyt, että jokin asia olisi ”ylitiedotettu”. Tämä tarkoittaa, että viestitään selkeästi ja riittävästi sekä projektiryhmän sisällä, asiakkaan suuntaan talon ulkopuolelle sekä myös muille sidosryhmille.
  • Varmista, että seuraavalla kerralla ei tehdä samoja virheitä. ”How did WE miss this bug” painotti Janet Gregory, eli mikäli kriittinen bugi ehtii asiakkaalle asti, koko tiimin tulee pohtia miksi näin kävi, eikä ainoastaan osoittaa testaajaa syyttävällä sormella. Jos tässä projektissa epäonnistuttiin jossakin asiassa, varmistetaan, että seuraavassa projektissa ei langeta samaan kuoppaan.

Edellä esitetyistä kohdista mikään ei ole rakettitiedettä, mutta toimintatapojen ja prosessien muuttaminen on työlästä. On helpompi tehdä niin kuin aina ennenkin on tehty. Muutos on kuitenkin mahdollista, kun päämäärätietoisesti pienin askelin suunnataan kohti haluttua toimintatapaa.

Lue lisää Sinisen Meteoriitin testauspalveluista.

Tietoa kirjoittajasta