Hyvin suunniteltu on puoliksi tehty

Ketterän kehityksen ideologian mukaisesti ohjelmistokehitysprosessin kehittämisessä on hyvä miettiä prosessin eri hukkapisteitä (waste). Niillä tarkoitetaan esimerkiksi sellaisia ohjelmistotestauksen tehtäviä, jotka eivät edesauta projektin onnistumista tai paranna sen laatua. Hukkapisteitä ovat myös tehtävät, jotka vaikuttavat projektin onnistumisen liian hitaasti.

Voit aloittaa kysymällä itseltäsi ja muilta tiimin jäseniltä: ”Mitä toistuvia tehtäviä on ohjelmistokehityksen sprintin aikana?” Kun olet saanut vastauksen tähän kysymykseen, mieti seuraavaksi, onko toistuvien tehtävien joukossa myös sellaisia, joista voidaan luopua kokonaan. Voisiko samalla pohtia testaukseen kokonaan uutta lähestymistapaa? Tässä kohtaa kannattaa malttaa mielensä ja harkita asiaa ohjelmistokehityksen kannalta. Missään tapauksessa ei tule tehdä päätöksiä, jotka nojautuvat nykyisiin testaustyökaluihin ja niiden käyttömahdollisuuksiin.

Siirry prosessissa vasemmalle

Jos sinulla ei ole vielä tässä vaiheessa testausstrategialle hyvää nimeä, rakenna ajattelusi esimerkiksi ”Aikainen lintu madon nappaa” lauseeseen perustuen. Avustavan ajatuksen avulla voit kirjoittaa auki projektin tai sprintin haasteita ja tehtäviä ohjelmistokehitysprosessin aikajanalle.

Älä sido tehtäviä tiukasti mihinkään rooliin tai testitasoon, sillä olennaista on ensin löytää ratkaisut ja menetelmät eri haasteisiin. Tämän jälkeen on mahdollista keskittyä enemmän eri vastuisiin esimerkiksi RACI -matriisin avulla. Pidä mielessäsi koko ajan se tosiasia, että bugien poistaminen prosessista ja ohjelmistosta on sitä edullisempaa, mitä aiemmin se tapahtuu (shift left).

Kohti kokonaisvaltaista testiautomaatiota

Liian usein testiautomaation kehitys toteutetaan siiloissa. Tämän mukaisesti testauksen avulla on pyritty ratkaisemaan yksittäisen roolin suorittamaa testaustehtävää, joka liittyy tyypillisesti ainoastaan toiminnalliseen testaukseen. Onneksi testiautomaatio nähdään nykyisin entistä enemmän liiketoimintaa tukevana toimintana, ja sen suunnittelu pohjautuu yhä useammin kokonaisvaltaiseen ajatteluun. Kokonaisvaltainen ajattelu kattaa E2E ohjelmistokehitysprosessin, odotusaikojan minimoinnin ja koko ohjelmistotuotteen elinkaaren. Lisäksi hyvin suunniteltu testiautomaatio ottaa huomioon oikean toiminnallisuuden lisäksi myös ei-toiminnallisen näkökulman.

Rakenna testiautomaatiosta uudelleenkäytettävä

Jotta automaatiosta voidaan rakentaa aidosti liiketoimintaa hyödyntävää, sen suunnittelun yhtenä peruspilarina täytyy olla uudelleenkäytettävyys myös myöhemmillä testitasoilla ja eri ympäristöissä. Lisäksi staattisen testidatan käyttämisen sijaan on pyrittävä rakentamaan dynaaminen testidatan generointi osaksi automaatiota.

Automaatio voi auttaa myös ratkaisemaan testitapausten dokumentoinnin haasteita, ja esimerkiksi Robot Frameworkin testitapaukset voidaan tarvittaessa kirjoittaa selkokieliseen (user story) muotoon. Selkokielisyys avaa toiminnallisuuden helposti liiketoiminnan edustajille ja tarvittaessa myös asiakkaille. Parhaassa tapauksessa automatisointi suunnitellaan siten, että testitapausten generointi tapahtuukin automaattisesti liiketoiminnan malleihin perustuen (model- based testing).

Kimmo Hakala, Senior QA Consultant
kimmo.hakala@q-factory.fi

Blogisarjamme ”QA tänään ja huomenna” jatkuu seuraavaksi käyttäjätyytyväisyyttä käsittelevällä kirjoituksella. Aiemmat blogikirjoitukset voit lukea seuraavista linkeistä:

QA tänään ja huomenna, osa 2
Testaus on liiketoimintaa varten