Eräs asiakas pyysi meitä apuun, kun hyväksymistestaus karahti kunnolla kiville. Toimittaja luovutti sovelluksen asiakkaalle testattavaksi. Aluksi ei toiminut mikään. Kun testit saatiin pyörimään, löydettiin ensimmäisinä päivinä 86 virhettä. Vastaavaa taitaa olla tapahtunut monelle muullekin uuden ohjelmiston hankkijalle.
On aika surullinen näky, kun testaajien ensimmäinen kosketus ”valmiiseen” sovelluksen kääntyy innostuksesta pettymykseksi.

Viisitoista mielensä pahoittajaa

Maanantaiaamu, testauksen aloitus

Testaajat saapuivat testaustilaan jännittynein mielin. Testitapaukset valmisteltuna ja haasteellinen tavoite päivälle hienosti kommunikoitu. Mutta konsultin sunnuntaina kiireessä tekemä asennus testiympäristöön ei ollut onnistunutkaan, joten testejä ei voinut vielä aloittaa. Toimittaja teki paniikissa korjauksia ja projektipäällikkö keksi testaajille muuta ohjelmaa, jotta he eivät karkaisi.

Maanantai klo 11

Kun pari tuntia oli hukattu, niin päästiin aloittamaan. Aloitettiin yksinkertaisella casella, kaikki yhdessä. Myyjä aloitti tekemällä tarjouksen. Hän koitti tulostaa sen, mutta konsultti keskeytti: ”Noi tulosteet ei oo vielä valmiita, älä turhaan kokeile tulostaa.” Lounastauko.

Maanantai klo 12:30

Tarjous yhdestä varastotuotteesta saatiin tallennettua, joten seuraavaksi tarjouksesta lähdettiin luomaan tilausta. Konsultti keskeytti taas: ”Toi tilauksen luonti tarjouksesta ei ole vielä ihan valmis, joten älkää turhaan sitä testatko.” Samalla tyylillä jatkettiin loppupäivä. Testauspäivän tuloksena löysimme kasan ominaisuuksia, joiden toteutus oli kesken. Toinen tulos oli 14 turhautunutta testaajaa ja yksi huolestunut projektipäällikkö.

Tiistai

Tiistaina löydettiin pari prosessia, jotka pienellä mielikuvituksella voitiin mieltää valmiiksi. Mutta kun siirryttiin testaamaan oikeilla asiakkailla ja tuotteilla, niin testaus alkoi taas tökkiä. Perustiedot olivat puutteellisia, ja sen takia testit päättyivät virheisiin. Raportoitiin ihan turhia virheitä, vain sen takia, että perustiedot olivat päivittämättä.

Tiistai-ilta

Konsultti ja projektipäällikkö viettävät iltaa päivittämällä perustietoja testiympäristöön, jotta edes kolmantena päivänä testaaminen onnistuisi.

Keskiviikko

Aamu aloitettiin uudella ohjeistuksella. Toimittaja oli tehnyt listan toiminnoista, jotka eivät olleet valmiina. Listan pituus yllätti asiakkaan. Samoin kerrottiin, mitä perustietoja testaajien tuli käyttää. Listassa oli 5 asiakasta ja 1 tuote / kategoria.

Testiympäristö oli saatu jotenkin toimimaan, joten alettiin päästä asiaan. Siirryttiin yksinkertaisimmista tapauksista hieman monimutkaisempiin. Testaajille alkoi paljastua, että toteutettu ratkaisu ei ole ihan sellainen kuin he olivat odottaneet. Tilannetta vielä pahensi se, että tilatut räätälöinnit eivät olleet valmiita. Mielet pahoitettiin myös siitä, että osa räätälöintitarpeista oli jätetty tilaamatta, mutta tästä ei oltu tiedotettu liiketoimintaa.

Samaan aikaan toimittajan konttorilla

Kun toimittajan koodarit kävivät läpi virheraportteja, olivat he ihmeissään. Toimittajan projektipäällikkö sai läksytykset: ”Eihän noi testaajat taida osata mitään? Eihän tilauksesta voi mitenkään luoda ostotilausta, jos tuote on varastotuote! Eiks niitä oo koulutettu ollenkaan? Ja miks näistä puuttuu virhelogi…”

Miksi testaus karahti kiville?

1. Testaus päätettiin aloittaa kalenteriin merkittynä päivänä, vaikka valmiutta testauksen aloittamiseen ei ollutkaan.

2. Toteutus ei ollut valmis, kun testaus alkoi. Virallinen status oli: kaikki on valmista, paitsi pari pikku juttua. Oikeasti tilanne oli paljon huonompi.

3. Perustietojen tärkeyttä ei oltu mielletty. Eikä sitä, että perustietojen ylläpito oli asiakkaan vastuulla.

4. Määrittely oli toteutettu vanhanaikaisesti ja puutteellisesti. Sen seurauksena johto ei ymmärtänyt, mikä vaikutus heidän päätöksillään oli, kun jotain räätälöintejä jätettiin toteuttamatta.

5. Testaajia ei oltu koulutettu testaamaan sovellusta. He enemmänkin arvasivat ja kyselivät ohjelmiston toiminnoista, kuin oikeasti testasivat.

Vältä kehitysprojektin testausvaiheen yleiset ongelmat

Kehitysprojektien ongelmat paljastuvat usein samassa kohdassa: kun toimittaja luovuttaa ratkaisun asiakkaalle testattavaksi. Tähän asti voidaan edetä suunnitelman mukaan, ongelmia voidaan piilotella tai lakaista maton alle, mutta kun loppukäyttäjät saavat ohjelmiston testattavaksi, ongelmat paljastuvat kaikessa karmeudessaan.

Tosiasiassa 90% testauksen epäonnistumisen syistä syntyvät kauan ennen testauksen aloittamista.
Testausta saatetaan moittia huonosti suunnitelluksi tai toteutetuksi, vaikka syy itse ongelmiin löytyy projektin johtamisesta ja suunnittelusta.

Ongelmien välttämiseksi huomio täytyy kiinnittää projektin suunnitteluun ja toteutukseen. Projekti pitää asettaa niin, että testauksen aloituspäätöstä tehdessä on selkeä näkyvyys toteutuksen valmiusasteeseen. Toteutuksen edistymistä täytyy voida seurata reaaliajassa, jotta tiedetään tarkalleen, mitkä asiat ovat valmiina, mitkä eivät.

Projekti kannattaa pilkkoa toteutuspaketteihin, ja toteutuspaketit puolestaan käyttötapauksiin. Projektin pilkkomisen ja käyttötapausten avulla projektin seuranta saadaan riittävän tarkalle tasolle oikeiden päätösten tekemiseksi.

Käyttötapauksia hyödyntäen testauksen valmistelu on järjestelmällistä ja nopeaa, ja aikaa vapautuu testauksen suunnitteluun ja johtamiseen. Käyttötapauksista johdetaan testattavat prosessit, ja liitetään testitapaukset käyttötapauksiin. Laadukkaaseen käyttötapaukseen perustuvat testitapaukset on nopea kirjoittaa ja suorittaa. Käyttötapauksia hyödyntämällä saadaan myös selkeä näkyvyys testauksen kattavuuteen ja testauksen edistymiseen.

Tule kuulemaan lisää ilmaiseen koulutuswebinaariin

Quality Gate Best Practice mallin koulutuksessa esittelen tarkasti, ja esimerkein, mitä tarkoitan käyttötapauksilla, mikä on niiden rakenne ja sisältö.

Opetamme, miten hyödynnät käyttötapauksia projektin suunnittelussa, toteutuksessa ja testauksessa, ja saat projektin maaliin aikataulussa ja budjetissa.

Ilmoittautumislinkki tuossa alapuolella! Tavataan koulutuksessa!