Testaus aikataulupuristuksessa

Testausguru Amit on aloittanut työt yrityksessä, joka kehittää logistiikkajärjestelmiä teollisuusyrityksille. Järjestelmäkehitys on projektiluontoista, sillä tarpeet ovat vahvasti erilaiset jokaisen uuden asiakkaan kohdalla.

Työn tekoa leimaa jatkuva kiire ja repivyys tuotekehityksessä. Sovitun järjestelmätoimituksen lähestyessä työt kasaantuvat rankalla tavalla. Yleensä viimeinen kuukausi ennen toimitusta menee ylitöiksi koko tiimillä. Toimituksen jälkeen korjaillaan lisäksi jäännösvirheitä, joista asiakas on toimituksen jälkeen reklamoinut.

Amitin hypätessä puikkoihin yrityksellä ei ollut varsinaista testaustiimiä vaan työvoima testaukselle alihankittiin kylmästi kolmannelta osapuolelta. Testauksen toimintatapana oli, että tuotekehityksestä tehtiin testaustoimeksianto alihankkijalle aina kun siltä tuntui. Sopimus oli hinnoiteltu kiinteästi per testikierros.

Amit huomasi nopeasti, että koko järjestelmäkehitystä vaivaa ikävä pullonkaula: Amitin mielestä repivyys ja aikatauluongelmat johtuivat nimenomaan kehitystyön loppusuoralla löytyvien kriittisten virheiden määrästä. Virheiden korjaamiseen kului merkittävä siivu ajasta, joka piti käyttää järjestelmätoimituksen viimeistelyyn. Lisäksi projektijohto joutui tekemään kipeitä päätöksiä valikoitujen virheiden jättämiseksi korjaamatta. Niistä asiakas useimmiten sitten takuuaikana teki reklamaatioita ja taas kului lisää aikaa korjaustöissä.

Onneksi Amit oli joskus nähnyt Conformiqin kalvosetin testauksen alihankinnasta. Niistä löytyi erinomainen havainnollistus testauksen aikataulupuristuksesta.

Projektipäällikkö ei tehnyt testaustoimeksiantoja kuin vasta jokaisen toimituksen viimeisellä kolmanneksella. Päällikön mielestä testausta ei kannattanut aloittaa, koska budjetti sisälsi kiinteän määrän testauskierroksia ja hänkin tiesi että softassa on vikoja. Testauksen aloittaminen ajoissa tuntui siis resurssien haaskaukselta.  Toisaalta järjestelmätoimituksella oli deadline, josta lipsumisesta seurasi sopimussakkoa. Takuuajalle oli siis pakko jättää virheitä. Lisäksi viimeisen kolmanneksen testaustoimeksiannoista iso siivu kului raportoitujen virheiden verifiointityöhön ja fixien tarkistamiseen.

Onneksi Amitilla oli vanhana guruna kokemusta vastaavasta tilanteesta. Ratkaisukin oli täysin itsestään selvä. Ongelmakenttää kukaan ei vain ollut huomannut tarkastella testauksen näkökulmasta aikaisemmin.

Amit ehdotti, että järjestelmäkehitys jaksotetaan selkeästi testattaviin buildeihin koko projektin ajalle ja testausbudjetti jaetaan koko projektin elinkaarelle. Amitin esittelemät korjaukset prosessimalliin aiheuttivat yrityksessä seuraavat toimenpiteet:

• Buildisykli tiivistettiin kahteen viikkoon. Toimivan buildin oli oltava valmiina aina parillisten viikkojen torstaina.
• Jokaisesta buildista oli tehtävä toimeksianto testaukselle. Testaustulokset olivat valmiina viidessä työpäivässä.
• Virheidenkorjausprosessi aloitettiin heti ensimmäisten testitulosten valmistuttua ja sitä jatkettiin projektin loppuun asti.

Lisäksi testaustoimittajan kanssa sovittiin kiinteästä kuukausihinnasta, joka sisälsi kaksi testattavaa buildia. Hinta laskutettiin oli töitä tai ei. Ennakoitava työmäärä laski testauskierroksen hintaa. Raaka laskutuspolitiikka taas pakotti tuotekehityksen pitämään huolta säännöllisesti tehtävistä tarkastuskelpoisista buildeista.

Näillä toimenpiteillä vakavat virheet saatiin kiinni aikaisemmin ja ne korjattiin hyvissä ajoin ennen toimitusta. Tuotekehityksen työmäärä pysyi tasaisena läpi koko projektin. Ylitöitäkään ei enää tarvinnut tehdä ja takuuaikana tehtävien korjausten määrä puolittui. Yrityksessä huomattiin että:

Testaukseen ja koodaukseen pätee molempiin sama sääntö: Ne eivät toimi optimaalisesti aikataulupuristuksessa!