Mitä bugille tapahtuu?

Kaikki tietävät, mitä ensin tapahtuu. Testaaja lähtee käymään läpi testitapauksia, hetken päästä prosessi katkeaa. Tilanne dokumentoidaan tekstein, kuvakaappauksin, nauhoittein, miten milloinkin, kuitenkin mahdollisimman yksityiskohtaisesti. Sitten se tallennetaan bugitietokantaan ja jäädään odottamaan korjausta.

Mutta mitä sitten tapahtuu?

Testaaminen on välttämätöntä toimintavarman ohjelmiston rakentamiseksi. Joskus voi kuitenkin käydä niin, että testaus tuottaa bugeja paljon nopeammin kuin niitä ehditään korjaamaan. Yksikin testaaja saattaa raportoida kymmeniäkin bugeja päivässä, ja samaan aikaan kehittäjät ovat ehkä kiinni uusien ominaisuuksien kehittämisessä tai jopa muissa projekteissa. Tai jos bugeja korjataankin, yksittäinen korjaus saattaa avata testaajalle tien löytää monta uutta bugia. Muutamassa päivässä bugitietokanta saadaan niin täyteen, että sen perkaaminen käy työstä. Ja todella se perkaaminen vie myös aikaa. Bugien korjaamista ohjataan käymällä listaa läpi, delegoimalla ja priorisoimalla. Kehittäjät etsivät itselleen mielekkäitä kokonaisuuksia korjattaviksi. Testaaja kahlaa läpi aktiivisten bugiraporttien listaa tarkistaakseen, muistiko eilen raportoida sen yhden kummallisen bugin, jonka selvittely jäi kesken, tai etsii viime viikolla löytyneen bugin täydentääkseen sen kuvausta uudella tilanteella, jossa sama ongelma toistuu. Kenties muukin projektihenkilöstö raportoi löytämiään bugeja joko suoraan samaan tietokantaan luoden duplikaatteja, tai kyselemällä sähköpostitse testaajalta, joko olet huomannut tämän ja tämän asian. Kehittäjien tehdessä uutta toiminnallisuudet saattavat myös muuttua tavalla, jonka myötä vaivalla dokumentoituja bugeja ei enää saada toistumaan, ja niiden moniportainen käsittely vie turhaan aikaa niin kehittäjiltä kuin testaajilta.

Ei kuulosta ihan hirveän tehokkaalta.

Soppa saadaan kasvamaan entisestään, kun kirjataan bugeina kaikki testaushavainnot, ja oletetaan, että ne hoituvat kehittäjien ja testaajien välisellä pingiksellä.

Testaaja ei kuitenkaan yleensä ole projektipäällikkö, ei suorassa yhteydessä asiakkaaseen eikä vastuussa määrityksestä tai vaikkapa käyttöliittymäsuunnittelusta. Tarkentavat kysymykset, joiden oleellinen sisältö on "pitääks tää oikeesti tehdä?" tai "mitä tää määrityksen kohta oikeesti tarkoittaa?" pitäisi ohjata jonnekin muualle. Esimerkiksi suoraan asiakkaalle. Testaaja kun ei voi yksinään antaa kehittäjälle lupaa oikaista.

Miten tilanteen sitten saisi pysymään hanskassa?

Bugien löydettävyyttä parannetaan paitsi hyvällä nimeämisellä myös linkityksillä (esim. käyttötapauksiin) ja luokitteluilla (esim. mihin toiminnallisuuteen liittyy). Sotkun syntymistä voi vähentää myös niin, että sovitaan tarkkaan testauksen tavoitteet, ja vain niihin liittyviä bugeja raportoidaan. Jätetään se kaikesta jännästä nipottaminen vähän myöhempään, kun keskeisimmät asiat toimivat. (Tämä toki tarkoittaa, että testaukseen on oltava käytettävissä riittävästi kalenteriaikaa, eli testaus on aloitettava heti kun toteutus on siinä vaiheessa, että testaaminen on mielekästä.) Voidaan myös jakaa testaushavainnot esim. bugeihin, keskeneräisiin toiminnallisuuksiin ja lähdemateriaalien ongelmiin, ja sopia näille toisistaan poikkeavat käsittelytavat. Kunhan projektissa mietitään, mitä testaukselta aikuisten oikeasti halutaan, ja miten organisoimalla se saadaan mahdollisimman hyvin tukemaan ja mahdollisimman vähän tukkimaan kehitystä.

Jos kaikki oikeasti tietävät, ettei olla vielä stabilointivaiheessa, on hyvä jos testaaja voi työskennellä kehittäjien lähellä, jolloin tieto kulkee myös ilman bugitietokantaa. Kysymyksiä on silloin helppo pallotella suullisesti, ja arvioida yhdessä, miten paljon testauspanoksia kannattaa laittaa mihinkin toiminnallisuuteen juuri nyt. Tätä keskustelua on toki mahdollista käydä sähköisestikin, jos vain kaikki osapuolet ymmärtävät sen olevan yhteinen etu.

Lopulta tärkeää on myös se, ettei pelätä nostaa kissaa pöydälle. Jos toteutuksen ja testauksen lähdemateriaaleissa kuten määrityksessä on ongelmia, joiden takia ei ole mielekästä jatkaa, tieto tästä pitää saada mahdollisimman pian etenemään sinne, missä asioista päätetään. Ongelmien raportoiminen ei koskaan saa hilpeää vastaanottoa, mutta tämä asia ei yleensä odottamalla parane.Näiden maton alle lakaistujen asioiden esiin nostaminen on yksi testauksen tärkeimmistä tehtävistä, ja niiden edistämiseen onkin löydyttävä kanavat, joita käyttäen ongelmat myös ratkotaan. 

Ä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."