Älä turhaan suunnittele testausta

Testauksen voi suunnitella monella tavalla. Testitapauksia voi kirjoittaa hyvin yksityiskohtaisesti, tai ne voi rakentaa vain otsikkotasolla, muistilistanomaisesti. Itse testauksen organisointia voi suunnitella enemmän tai vähemmän perusteellisesti. Testaussuunnitelma voi kertoa mm. kuinka paljon työaikaa ja kalenteriaikaa käytetään mihinkin testikierrokseen, miten paljon aikaa varataan niihin liittyviin korjauksiin verifiointeineen, kuinka usein testikierroksia toistetaan, ja mitkä ovat kriteerit testauksen lopettamiseen.

Joskus on hyvä pysähtyä hetkeksi miettimään, millä tarkkuustasolla nämä asiat kannattaa tehdä projektin suunnnitteluvaiheen aikana.

Perusteellinen testaussuunnittelu liittyy usein siihen, että asiakkaalle on luvattu tiettyjä dokumentteja tietyssä vaiheessa projektia. Jos asiakkaan kanssa sovitaan, että he saavat toimittajan testitapaukset sisältöineen kaikkineen käytettäväksi omassa hyväksymistestauksessaan, ne on rakennettava paljon huolellisemmin ja paljon enemmän aikaa käyttäen kuin jos luodaan vain alustava testitapausluettelo, jota muokataan ja täydennetään tarpeen mukaan testausvaiheessa. Jos asiakas haluaa lukea testaussuunnitelman, siinä ei oikein voi lukea että testataan sitä mukaa kun jotain on likipitäen testattavissa, testaajana se joka sattuu silloin parhaiten ehtimään. Joskus tämä kuitenkin olisi tarkoituksenmukaisempi suunnitteludokumentti kuin sellainen, joka ottaa kantaa kaikkeen mahdolliseen testaamisen aloitus- ja keskeytyskriteereistä testikierrosten organisointiin. Kenties keskeisin hyvän testaussuunnitteludokumentin piirre voisi olla se, että se on riittävän lyhyt jotta projektin kulkua ohjaavat henkilöt lukevat ja sisäistävät sen.

Jos oikeastaan mikään ei todellisuudessa tapahdu suunnitteludokumentaation mukaisesti, eikä sitä tosiasiallisesti edes yritetä noudattaa (olipa syy tähän sitten piittaamattomuus tai projektielämän realiteetit), kuinka paljon aikaa tällaisen dokumentin kirjoittamiseen kannattaa käyttää?

Jos projektia edistetään vähän miten nyt kukakin sattuu ehtimään, on testauksessakaan turha pyrkiä tämän suurempaan kurinalaisuuteen. Klassinen testaus perusteellisine testitapausluetteloineen ja huolella ennalta suunniteltuine testikierroksineen on mielekästä vain, jos myös projektin edeltävät vaiheet viedään läpi vastaavaa kurinalaisuutta noudattaen. Eli määritysvaiheessa todella määritetään ja kiinnitetään määritykset, suunnitteluvaiheessa ihan oikeasti suunnitellaan määrityksen pohjalta, ja toteutusvaiheessa nämä suunnitelmat viedään läpi aikataulussa.

Kaikissa projekteissa tämä ei kuitenkaan ole mahdollista. Eikä kyse ole vain toteuttavan projektihenkilöstön osaamisesta ja viitseliäisyydestä. Tilanteeseen vaikuttaa myös esimerkiksi asiakkaan määritysosaaminen, eli pystyvätkö he kertomaan, mitä haluavat, ja kuinka paljon projektin aikatauluun sisällytettäviä muutoksia he keksivät suunnittelu- ja toteutusvaiheiden aikana, Ja tähän taas vaikuttaa paitsi asiakkaan projektiryhmän IT- ja substanssiosaamisen riittävyys, myös asiakkaan tarpeiden selkeys.

Lisäksi, ihmiset ovat erehtyväisiä. Paraskin projektipäällikkö voi unohtaa jotakin, ja paraskin tekninen vastuuhenkilö ymmärtää jotain väärin. On vain hyvä asia, jos nämä unohdukset ja väärinymmärrykset jäävät kiinni ennen stabilointivaihetta, koska silloin niiden vaikutukset aikatauluihin ja työmääriin ovat vähäisemmät. 

Jokainen projektiin tuleva muutos kuitenkin syö etukäteen tehdyn perusteellisen testaussuunnittelun arvoa. Mitä enemmän asioita on kirjoitettu auki testitapauksiin, sitä enemmän niitä on pakko muokata muutosten mukaisesti, ja sitä suurempi riski on sille että testaus raportoi vääriä asioita bugeina. Mitä enemmän projektin käytännöt ja järjestelyt poikkeavat testaussuunnitelmasta ehdotetuista, sitä vähemmän arvoa on sen kirjoittamiseksi tehdyllä työllä. Kun tämän päälle tulee vielä testaussuunnittelun itsensä epätäydellisyys, on selvää että määritysvaiheen perusteella tehdyt testitapaukset on vähintään katsottava läpi kriittisellä silmällä testauksen alkaessa.

Testaussuunnittelu on mahdollista tehdä myös toisin. Määritys- ja suunnitteluvaiheessa testauksen rooli voi keskittyä enemmänkin katselmointiin ja konsultointiin. Testaussuunnitteludokumentaation keskeisin rooli voi olla tiedon kerääminen siitä, mihin dokumentteihin nojaten testaus on tehtävä, sekä millaisia riskejä projektiin liittyy testaamisen näkökulmasta ja miten niihin varaudutaan. Riskitarkastelussa käsitellään niin testaukseen ulkopuolelta vaikuttavat riskit kuin riskit joihin testaaja voi itse vaikuttaa, muistaen erityisesti asiakkaan toiminnan kannalta keskeisimmät toimitettavaan järjestelmään liittyvät riskit, joiden tulisi vaikuttaa testauksen sisällölliseen painotukseen. Varsinaiset testitapaukset voidaan luoda tutkivan testauksen ohessa, tosin tällöin on muistettava että testaukseen tarvittavaan aikaan on lisättävä myös dokumentaation vaatima aika.

Mikä siis on päivän opetus? 

Klassisella, kurinalaisella testauksella on oma arvonsa ja paikkansa, mutta kaikkialle se ei sovi. Jos tiedät, ettet aikuisten oikeasti pysty viemään projektia läpi tiukasti vesiputousmallin mukaisesti, älä tee myöskään testaussuunnittelua niin kuin mentäisiin vesiputousmallilla. Älä silloin myöskään lupaa asiakkaalle testitapauksia (paitsi korkeintaan otsikkotasolla) suunnitteluvaiheessa. Tosiasiat voi tunnustaa jo etukäteen, ja ammattimainen testaaja pystyy kyllä luovimaan tiensä myös vähän epämääräisemmässä projektiympäristössä. Säästytään puolin jos toisin paljolta pahalta mieleltä ja turhalta työltä, jos projektin toimintatavoista sovitaan avoimesti etsien ne tavat, joilla tieto parhaiten löytää tarvitsijansa, ja testaus voidaan suunnitella tavalla jolla se todennäköisesti voidaan myös toteuttaa.

Muutoshallintaa v-käyrällä

Projektipäällikkö raahusti hiuksiaan haroen ja raskaasti huokaillen testaajan työpisteelle.

"Istuhan alas", testaaja kehotti. "Mitäs meidän projektille kuuluu? Stabilointivaiheen piti muistaakseni alkaa pari viikkoa sitten, joko nyt vihdoin alkaisi olla jotain testattavaa?"

Projektipäällikkö huokaisi taas syvään.

"Ei ole vielä tarpeeksi valmista," hän vastasi. "Ja itse asiassa nyt on sellainen tilanne, että pitäisi keskustella testauksen määrästä."

"Niin, arvioin silloin projektin alkaessa, että riittävä testaus voisi onnistua kolmen viikon työllä. Se todettiin jo silloin hieman optimistiseksi arvioksi, mutta haluttiin minimoida kustanuksia. Projektin ongelmat tietysti indikoivat, että se ei välttämättä riitä."

Projektipäällikön ilme muuttui entistä tuskaisemmaksi.

"Mutta kun projektin aikataulu ei jousta! Etkö voisi testata vähän nopeammin?"

"No tietysti voidaan vielä priorisoida testitapauksia ja karsia pikkuisen eri päätelaitteilla ja selaimilla tehtävää testausta, mutta se tietysti kasvattaa riskejä. Varmaan kahdessa ja puolessa viikossa saisi jo kohtuullisen käsityksen riskitasosta, vaikka laadun takaaminen voikin olla mahdotonta. Ja aikatauluhan riippuu pitkälti myös siitä, miten nopeasti korjaukset etenevät."

"Minä ajattelin ennemminkin, että jos kuitenkin vaan ottaisit pari päivää ja kliksuttelisit sen läpi? Ei mentäisi niin virallisesti."

"Oletko tosissasi? Meillä on testattavana kymmenkunta prosessikulkua variaatioineen viidellä eri selaimella, tabletilla ja älypuhelimella. Jo siihen kolmen viikon työmäärään liittyy tietyn riskitason hyväksyminen. Ja miten se aikataulu nyt voi olla noin tiukka, kun testaussuunnitelmaa tehtäessä sen kolmen viikon työn jakaminen kuuden viikon jaksolle ei ollut mikään ongelma? Nyt ollaan vasta kaksi viikkoa myöhässä, tai kohta siis kolme viikkoa. Eikö sitä testausaikaa pitäisi olla vielä kolme viikkoa jäljellä?"

"Unohdin kertoa sinulle, että koulutuksia piti aikaistaa kahdella viikolla. Eräillä avainhenkilöillä osui lomat siihen hankalasti, ja sitten oli seminaarimatkoja. Pitäisi saada valmista sitä ennen."

Testaaja veti syvään henkeä ja nojautui tuolissaan taaksepäin.

"Yritätkö siis sanoa, että softa ei ole vielä tarpeeksi valmis testattavaksi, mutta ensimmäiset koulutukset ovat jo kahden viikon kuluttua?"

"Niin."

Hetken aikaa kuului vain ilmastoinnin vaimea humina.

"No, periaatteessa tilanne saattaa olla pelastettavissa, jos voin valjastaa koko testaustiimin työhön, ja pääsemme aloittamaan vielä tällä viikolla. Täytyyhän siellä joku kokonaisuus kohta olla testattavissa, ette kai te kaikkea ole tehneet yhtä aikaa."

Projektipäällikkö vinkaisi hiljaa, muttei sanonut mitään.

"Mutta korjausten pitäisi sitten edetä tosi nopeasti, tai muuten me vain dokumentoimme syyt, joihin koulutus tulee kaatumaan. Ja tietysti sen pitää olla hyvin koodattu, että se saadaan käytännössä yhdellä korjauskierroksella kuntoon. Aika ei mitenkään riitä nyt bugi-pingikseen."

"Ei onnistu, budjetti ei anna myöten."

"Miten niin ei anna myöten? Piti olla mahdollisuus käyttää testaamiseen kolme viikkoa työaikaa."

"Mutta tässä on nyt ollut vähän kaikenlaista, on tullut yllättäviä kustannuksia. Muista projekteista aiheutuvien resursointiongelmien vuoksi tätä on nyt tehty aika takapainotteisesti, ja siksi projektiin piti ottaa mukaan odotettua suurempi joukko kehittäjiä. Osa on ollut vähän kokemattomia, työ on edennyt hitaasti ja ovat tarvinneet suunniteltua enemmän ohjausta. Hommia on myös jouduttu vaihtamaan tekijältä toiselle, kun on pitänyt priorisoida työskentelyä eri projektien välillä. Yksi päivä meni hukkaan, kun integraatioympäristö asennettiin ensin väärin. Pari päivää meni kun piti kaivaa yhden sairaslomalle jääneen kehittäjän koneelta, mitä hän oli ehtinyt tehdä. Ja sitten yksi kone hajosi, eikä ollut varmuuskopiota. Ja..."

"Eli kun koodarit säätävät, testaus maksaa?"

"Maksaa ja maksaa, asiakashan se tästä maksaa. Tai meidän firma, asiakas ei suostu maksamaan enää yhtään enempää."

"Tiedätkö, miten kalliiksi tuotantokäytössä löytyvät bugit tulevat? Tai miten paljon työläämpää on tulkita ja hallita keskivertoasiakkaan bugiraportteja kuin meidän omien ammattitestaajien bugiraportteja? Mitä tulee koulutuksesta, kun softa ei toimi? Tai miten vaikuttaa asiakastyytyväisyyteen tai käyttäjien muutosvastarintaan, jos aloitetaan keskeneräisellä järjestelmällä?"

"No en minä voi kehittäjiltäkään sitä työaikaa nipistää, kun ei siitä järjestelmästä tule valmista ilman heidän työtään."

"Ja mikä saa sinut kuvittelemaan, että he saavat sen käyttökuntoon ilman että sitä testataan? Kuule maailmassa on aika paljon hyvää tuotekehitystä mennyt hukkaan, kun puutteellisen testauksen takia softaa ei ole saatu riittävään kuntoon, että sitä oikeasti voisi käyttää."

"Noh, tuskin tästä nyt sen luokan katastrofi on tulossa."

"Minusta kuulostaa, että sinulla on tässä projektissa toteutunut aika merkittävä määrä riskeistä. Sillä on väistämättä aikataulu- tai kustannusvaikutuksia, usein molempia."

"Mutta kun asiakas ei tule hyväksymään korkeampaa hintaa eikä viivästettyä aikataulua!"

"Ei se järjestelmä tunne projektin aikataulua, se valmistuu tekemällä ja testaamalla. Jos hintaa ja aikataulua ei voi venyttää, niin ominaisuuslistaa tulee pienentää."

"Sinä et tunne tätä asiakasta, eivät ne tule suostumaan... Eikä se tällä aikataululla onnistuisikaan. Sitä paitsi kaikki on melkein valmista, joten olisi tyhmää jättää mitään kesken."

Laskeutui hiljaisuus. Ilmastoinnin humina tuntui painostavana. Projektipäällikkö painoi päänsä käsiinsä ja huokaisi syvään.

"Mitä tässä sitten sinun mielestäsi tulisi tehdä?"

Testaaja katsoi ulos ikkunasta. Aurinko paistoi.

"Lähdetään kaljalle."

"Mitä, nyt on keskiviikkoiltapäivä?"

"Joo joo. Sulla on varmasti jo viikon tunnit täynnä, etkä pysty nyt edistämään mitään. Mennään kaljalle."

"Mutta eihän se käy!"

"No tietysti se käy. Otetaan mukaan kynää ja paperia ja suunnitellaan yhdessä kriisiviestintä. Kun sitten aamukrapulassa soitat asiakkaalle, kuulostat niin autenttisen katuvalta ja uupuneelta, että ne kyllä leppyvät."

Hetken hiljaisuus.

"Absurdia, mutta tuossa saattaa olla järkeä..."

"Joo joo. Enemmän kuin monessa asiassa, mitä tänään on tullut vastaan."