Category: Ohjelmistotestaus

Ihmiset ovat kehittäneet itselleen ja muille roppakaupalla juhannusperinteitä. Olosuhteista riippumatta niitä on pakko tai ainakin hyvä noudattaa. Tässä yksi:

Hauskaa Juhannusta lukijoille, olosuhteista riippumatta!

Testaus on investointi. Investoinnin tarkoituksena on löytää virheet siinä vaiheessa, kun niiden korjaaminen on halvinta.

LinkedInin keskustelupalstalta bongasin linkin, jonka takaa löytyi varsin mielenkiintoinen artikkeli. Artikkelissa käydään läpi 10 kalleimmaksi tullutta softavirhettä. Melko karua tekstiä, tässä muutama ns. herkkupala.

Marsiin lähetettiin luotain. NASA oli tehnyt speksi SI-yksiköissä, mutta koodaaja oli käyttänyt imperial unitteja. Laskeutuminen Marsin pinnalle meni ns. käteen ja luotain hajosi. Kustannus 125 miljoonaa dollaria.

CIA väitti, että Neuvostoliitto varastaa USAn öljyputkinen ohjausteknologiaa. CIA ujutti pikkuriikkisen bugin varastettavaksi. Seuraksena Neuvostoliitossa räjähti öljyputki, jonka Wikipedia toteaa olleen “monumentaalisin ei-ydinräjähdys koskaan avaruudesta nähtynä.” Kukaan ei kuollut, mutta on saattanut tovi mennä korjaillessa.

Toimittaja teki softan julkishallinnolle UK:ssa. Uusi ohjelmisto ei ollut yhteensopiva tilaajan järjestelmien kanssa. Kustannus tähän asti, 1000 miljonaa puntaa.

Sädehoitolaite antoi turhan paljon säteilyä. Viisi ihmistä kuoli.

Loput virheet ja tarkemmat kuvaukset löytyy täältä.

Aika hienosti noissa virheissä ja kustannuksissa tiivistyy likipitäen kaikki ongelmat, mistä mekin Antin kanssa olemme tässä blogissa keskustelleet. CIA:n huijaus on sinällään nerokas, mutta muuten. Määritysongelmia, osto-osaamisen puutetta, kiirettä jne.

Siksi en malta olla toistamatta.

Testaus on investointi. Investoinnin tarkoituksena on löytää virheet siinä vaiheessa, kun niiden korjaaminen on halvinta.

Teimme jokin tovi takaperin aasialaispohjaisella testaustiimillä kaksi testikierrosta ihan kokeilumielessä. Ensimmäiselle testikierrokselle laadittiin hyvin selkeäsanainen testispeksi testattavan tuotteen vaatimusten pohjalta.

Testaustyö tehtiin Intiassa ja tulokset olivat odotetunlaiset. 40 testitapauksen joukosta löytyi 18 virhettä. Yhtä paljon kuin testien suunnitteluvaiheessakin oli jo löydetty (*). Toisen testikierroksen tehtävänanto oli selvästi erilainen. Käytettävissä oli yhtä paljon aikaa testaustyöhön kuin edelliselläkin kerralla.

Toimeksiantoon lähetettiin ainoastaan testattava tuote ja ranskalaisin viivoin lista asioista jotka kannattaa tsekata testaustyön ohessa. Ei siis vaatimuksia, eikä testitapauksia:

Test this product to your best knowledge and report all issues in a way you find best suited

Lopputuloksena raportteja saatiin 25. Virheiden raportointiin testaustiimi käytti vielä kekseliäästi videonkaappausta, joten kenellekään ei jäänyt epäselväksi minkälaisista virheistä oli kysymys. Myös ohjelmistokehittäjät kiittivät!

Suorittavaan testaustyöhön käytetystä ajasta saatiin tarkalleen ottaen 38% parempi tulos kun testaajan käsiä ei sidottu vaatimusten tai testitapausten kyttäämisellä. Testaaja otti loppukäyttäjän hatun päähänsä ja raportoi virheistä parhaan kokemuksensa mukaan.

Kuilu vaatimusten mukaan toimivan ja oikeasti toimivan välillä meinasi tässä tapauksessa jäädä hurjan kokoiseksi. Probleema onkin juuri siinä että vaatimusmäärittelyt tehdään lähes poikkeuksetta ennen tuotteen rakentamista. Vaatimukset ovat etukäteen suunnittelijan pään sisällä muodostettu käsitys siitä miten lopputuotteen pitäisi pelata. Pidä se mielessä kun suunnittelet testausta.

Muista että vaatimusten mukaan toimiva tuote ei ehkä ole toimiva tuote. Vasta avoimin mielin tehty testaus voi kertoa miten oikeasti kävi!

(*) Testauksen suunnitteluvaiheessa jouduttiin tutustumaan sekä toiminnallisiin vaatimuksiin että tutkimaan itse tuotetta, eli tekemään tutkivaa testausta. Suunnitteluvaihe siis vei myös reilusti aikaa.

Mitä aikaisemmin virheet löydetään, sitä edullisemmaksi niiden korjaaminen tulee. Jotta virheet löydetään ajoissa, pitää testaukseen panostaa mieluummin kehityskaaren alkuvaiheessa.

Tietenkin testauksen laatu ja tarkoitus täytyy aina suhteuttaa tuotekehityksen vaiheeseen. Arkkitehtuurin suunnitteluvaiheessa ei voida todentaa napin paikkaa ja väriä. Mutta ilman muuta voidaan varmistaa, että arkkitehtuuri mahdollistaa myöhemmin nappuloiden sijoittelun halutulla tavalla!

Projekteissa on jatkuva kiire ja rahakin on tiukalla. Siitä huolimatta varmista, että suunta on oikea.

Teuvo Testaajan vastuulla on loppukäyttäjätuotteen viikkoreleasejen regressiotestaus. Pirun tylsää hommaa ja vie yllättävän paljon aikaakin. Testit Teuvo ajaa Excelissä olevan testispeksin perusteella ja tulokset hän raportoi listalle tyyliin pass tai fail. Löydetyistä vioista Teuvo toki heittä failin perään vielä kommentit. Lisäksi löydetyistä virheistä pitää kirjoittaa bugirapsa tuotekehityksen virheidenhallintajärjestelmään. Virheraportin tunniste kopioidaan sitten exceliin failin perään ja ollaan tyytyväisiä työn tuloksiin.

Viimeviikon Kauppalehdessä pisti silmään otsikko “10 vinkkiä liiketoiminnan tehostamiseen”. Visman ilmoituksessa olleet 10 vinkkiä pääset lukemaan tästä. Juttu oli minusta erinomainen yhteenveto asioiden järkeistämisestä. Mielestäni listan tärkein kohta oli ensimmäinen. Opetus on kaikille järkeä käyttäville ihan itsestään selvä: “Tee työt vain kerran”. Mutta mitä se tarkoittaa Teuvon kannalta katsottuna?

Tyypillisen failin kohdalla Teuvo käyttää

• 5 minuuttia työtä virheen toteamiseen,
• 10 minuuttia menee toistamistapojen tutkimiseen ja impaktiarvioon,
• 5 minuuttia kuluu kun ongelman kirjoittaa testituloksiin ja kuvaa sen vaikutukset,
• 5 minuuttia vierähtää helposti virhetietokannan käytössä, kun vian kirjaa sinne ja
• 30 sekuntia kuluu kätevästi kun vielä kopioi käsin tietokantatunnisteen tuloksiin.

Yhteensä Teuvolla meni hommaan aikaa 25 minuuttia ja 30 sekuntia. Tästä ajasta menee 5 minuuttia ja 30 sekuntia aikaa työn tekemiseen kahdesti. Yhteensä se tarkoittaa noin 22% Teuvon työajasta.

Sitten täysin oma lukunsa on virheen korjaaminen. Kun virhe on tietokannassa eikä kukaan ole vaivannut päätään sillä viikkoon, niin kuinka käy Teuvon seuraavalla testikierroksella?

Teuvo toki ajelee testit kuten ennenkin. Sama virhe tulee jälleen kummittelemaan testikierrokselle, koska tieto ei kulje virhetietokannasta Teuvolle. 5 minuuttia menee saman testitapauksen uudelleen ajamiseen ja virheen uudelleen toteamiseen. 3 minuuttia vierähtää kun virhetietokantaan käy päivittämässä että virhe on uudessakin releasessa ja vaikutus on sama. Äkkiä samasta virheestä aiheutuva ylimääräinen työmäärä onkin kasvanut 40%:een. 150 tunnista näin käytettyä työaikaa menee siis 60 tuntia samojen töiden uudelleentekemiseen. Minusta aika hurjat lukemat sekä ajassa että rahassa.

Kotitehvät sinulle hyvä lukija: Koita keksiä vastaavanlainen skenaario omassa projektissasi.

Epäkohtia on mukava esitellä ja nostaa pöydälle. Mutta mintenkäs sitten niiden ratkaisuiden laita? Miten esimerkiksi tässä Teuvon tapauksessa olisi voinut säästää työaikaa ja kohdentaa sen järkevämmin?

Meillä homma on hoidettu kahdella muistisäännöllä:

1. Huolehdi että järjestelmät keskustelevat keskenään. Kun Teuvo kirjoittaa virheen kerran ylös, sen kopiointi muihin järjestelmiin tapahtuu automaattisesti.
2. Huolehdi että informaatiolle on takaisinkytkentä. Kun virheelle ei ole tehty mitään viikkoon se näkyy myös Teuvon testauksenhallinnassa.

Jos siis haluat saada samalla rahalla enemmän aikaan: Tee työt vain kerran!

Tällä hetkellä pelataan lätkän maailmanmestaruudesta. TV:n äärellä on miljoonia ihmisiä, jotka kannattavat omia joukkueitaan tai ovat muuten vain kiinnostuneita lajista.

Lätkäjoukkueen työnjakohan on kutakuinkin seuraava: Valmentaja päättää kuka pelaa ja milläkin paikalla. Hyökkääjien tehtävä on tehdä maaleja. Puolustus ja maalivahti yrittävät pitää oman pään puhtaana. Joukkue pelaa faneille, jotka myötäelävät joukkueen mukana. Fanien painostuksesta on jopa saatettu antaa valmentajille kenkää.

Maalinteko vastustajan verkkoon useimmiten onnistuu ainostaan, mikäli varsinaisten hyökkääjien lisäksi myös puolustajat osallistuvat järkevällä tavalla hyökkäyksen tukemiseen. Hyvä yhteispeli hyökkääjien ja puolustajien välillä mahdollistaa suuremman määrän erilaisia hyökkäysvariaatioita, jolloin maalinteon onnistumisen todennäköisyys kasvaa. Kun joukkue tekee maalin, koko kentällinen juhlii varsinaisen maalintekijän kanssa.

Vastaavasti puolustajien työ pitää kiekko pois omasta maalista on käytännössä mahdotonta, mikäli hyökkääjiä ei kiinnosta oman pään pelaaminen pätkän vertaa. Tyypillisesti omaan päähän tullut maali aiheutuu hyökkäyspäässä otetusta riskistä, jolloin puolustus on väistämättä myöhässä tilanteesta. Puolustaja on sankari tai konna, riippuen viimeisimmän pelitilanteen onnistumisesta. Tilanteen, joka olisi voitu välttää hyvällä viisikkopuolustuksella.

Pärjätäkseen joukkueen tulee olla hyvin johdettu ja puolustuksen ja hyökkäyksen tulee toimia saumattomasti joukkueen voiton eteen. Onnistuneesta suorituksesta fanit palkitsevat.

Sama pätee myös softakehitykseen. Devaajan tehtävä on pelata peliä kohti tavoitetta, testaajan tehtävä on pitää oma pää puhtaana. Kumpikaan ei kuitenkaan voi menestyä ilman toista. Kun homma toimii, niin myös loppukäyttäjä kiittää.

Yksikään tiimi ei voi ulkoistaa onnistumista yhdelle osaajaryhmälle: Pelkästään hyökkäykseen panostava joukkue häviää varmasti.

Asiakaslähtöisyys ja joustavuus. Siinä arvot, joita lähes jokainen suomalaisen yritys mainostaa. Asiakashan on aina oikeassa. Eikö totta?

Näin meitä toki on opetettu, mutta ajatellaampa asiaa tarkemmin.

Mannertenvälisellä lennolla viihtyminen on tärkeää. Se on jopa niin tärkeää, että matkustamossa on henkilökuntaa pitämässä siitä huolen. Matkustajalle kannetaan huopaa, tohvelia, leffaviihdettä sekä juotavaa nokan eteen. Sekoitetaan juuri niin mielikuvituksellinen drinksu kuin vain keksiä saattaa. Tarjoillaan ruokaakin oli matkustaja sitten vegaani tai barbaari. Asiakaslähtöistä sanon minä.

Entäpä sitten jos asiakas tulee matkalla siihen tulokseen että hän tietää parhaiten miten päästään Sydenystä Los Angelesiin ja vaatii lentäjää vaihtamaan lentokorkeutta? Entäpä jos suunta pitäisikin ottaa asiakkaan toivomuksesta New Yorkin kautta?

Koneen pilotti ei tietenkään edes harkitse ideoiden toteuttamista. Pilotti noudattaa laatimaansa lentosuunnitelmaa, koska se on toimivin juuri tällä konetyypillä ja näissä olosuhteissa. Sitäpaitsi sääpalvelu on ilmoittanut tuhkapilvestä taivaalla. Pilotti on tämän tarinan asiantuntija, guru joka tietää mikä tässä tilanteessa on järkevin etenemistapa.

Äkkiä joustavuutta ja asiakaslähtöisyyttä ei enää tarvitakaan. Kunhan matkustajat pääsevät turvallisesti ja ajallaan perille. Se jos mikä on asiantuntijan rooli.

Juttelin erään testauspäällikön kanssa taannoin testauksesta ja työajankäytöstä. Erityisesti keskustelu raportoinnista herätti ajatuksemme vallitsevaan ajatusmalliin. Käsittämätöntä mutta totta: Usein ajatusmalli on että työkalut maksavat, mutta työaika ei.

Testauspäällikön kanssa keskustellessa kävi ilmi, että hän käyttää testauksen raportointiin työaikaa noin 3-4 tuntia viikossa. Kerää testauksen tulosdatan yhteen exceliin käsin ja lähettelee raportit sidosryhmille. 3-4 tuntia oli mielestämme vähän työaikaa testauspäällikön tehtäviä ajatellen.

3-4 tuntia viikossa tarkoittaa kuitenkin hyvin suoraviivaisesti 141-188 tuntia vuodesta. Siis henkilötyökuukauden verran! Pelkkään manuaaliseen excelien pyörittelyyn. Eihän se tietenkään tunnu pienissä erissä pahalta, mutta aika hurjat lukemat siihen nähden kuinka arvokasta testauspäällikön työaika yleensä on. Siinähän kuluu helposti 6000 euroa vuodessa pelkästään exceleiden kirjoitteluun.

Muista tämä: 3 haaskattua tuntia viikossa tarkoittaa 141 haaskattua työtuntia vuodessa

Testaajat tekevät hirvittävän usein töitä juuri niillä toiseksi parhailla työvälineillä eli toimistosovelluksilla. Se on puhdasta käsityötä alusta loppuun ja käy aika kalliiksi meillä päin.

Rakennustyömailla tämä homma on jo huomattu. Siellä ostetaan mieluummin kunnon sirkkeli työntekijöille kuin laitetaan kaverit tekemään samat työt pokasahalla.

Asiaa palautteen antamisesta ja sen kommentit kertovat ohjelmistokehityksen kommunikoinnin haastavuudesta. Kehittäjiä tympii, kun testaajilta tulee negatiivista palautetta virheraporttien muodossa. Testaajat joutuvat olemaan kieli keskellä suuta miettiessään kuinka asian voisi ilmoittaa siten, että devaajat eivät vedä hernettä nenään.

Ongelma ei ole niinkään koodareitten ja testaajien välisessä kommunikaatiossa ja sen tavassa, vaan projektijohdon asettaman roolituksen toteuttamisessa.

Kokonaisuuden kannalta on tehokkainta, että devaajat kirjoittavat koodia vaatimusten mukaan riittävällä tarkkuudella. Testaajat puolestaan pyrkii löytämään koodista oleelliset puutteet. Molemmat ovat ammattilaisia omassa tehtävässään. Eikö olekin kokonaisuuden kannalta järkevintä, että projektissa asioita tekevät ne, jotka asiat parhaiten osaavat?

Mikäli vastuunjako ja henkilövälit eivät ole täysin kunnossa, kehittäjät voivat pelätä virheitä ja niistä johtuvaa negatiivista palautetta.

Tällaisissa tilanteissa projektijohdon tulisi olla hereillä. Projektijohdon pitää viestittää aktiivisesti kehittäjille, että heiltä ei odoteta virheetöntä koodia, koska testaajat löytävät puutteet ja ongelmat kehittäjiä nopeammin. Tuote valmistuu nopeammin, koodi uskalletaan jättää testattavaksi ilman päivien tai viikkojen hierontaa.

Virheraportit eivät ole enää negatiivista palautetta vaan normaalia kommunikointia hyvän lopputuloksen saavuttamiseksi. Hyvästä työstä on syytä kehua, sekä koodaajia että testaajia.

Oleellista ei ole se, kuka virheen löytää. Oleellista on se, kuinka nopeasti virhe löydetään ja korjataan.Molemmat ovat ammattilaisten töitä.

Kyllä suomalainen osaa antaa palautetta!

Työskentelin opiskeluaikojen alkupäässä Soneran puhelin- ja liittymämyynnissä Teleringillä. Tyypilliseen työpäivään kuului joukko uusia liittymiä ja myytyjä puhelimia. Asiakkaiden kanssa saatettiin myös ratkoa heille tärkeitä ongelmia puhelinten asetusten säätämisessä, eli toimittiin tukipalveluna.

Jokaiseen päivään kuului rutiinitoimintojen lisäksi asiakkaiden murheiden kuunteleminen. Asiakkaat tulivat myymälään avautumaan milloin mistäkin liittymän tai puhelimen ongelmasta. Asiakaspalvelijan rooli oli kuunnella, ymmärtää ja auttaa mikäli vain mahdollista. Yksi heinäkuinen lauantai kuitenkin jäi kaikkein elävimmin mieleeni. Se oli poikkeuksellinen päivä.

Myymälään tuli asiakas, jonka muistin käyneen meillä edellisellä viikolla ongelminensa. Synkkiä pilviä ehti kerääntymään pään yläpuolelle, kun ei taas jaksaisi kuunnella valitusta. Asiakas yllätti meidät kaikki lyömällä pöytään pussin pullaa ja kiittämällä saamastaan hyvästä palvelusta! Positiivinen palaute nosti hymyn huulille ja koko tiimin asiakaspalveluhenki oli loppupäivän huipussaan. Ja lisäksi pullakin oli hyvää. Sitä Dallaspullaa, jossa on vanilijakreemiä keskellä.

Tämän kokemuksen jälkeen jäin ajattelemaan palautteen antamisen voimaa. Miksi suomalainen antaa palautetta pääasiassa silloin kun joku on persiillään? Kun kaikki menee hyvin, suomalainen on hiljaa. Minä väitän että suomalaiset ovat todella huonoja palautteen antajia! Siinäpä meille opettelemista.

Miten tämä kaikki sitten liittyy testaamiseen?

Joel Spolsky kirjoitti blogissaan otsikolla Why testers? Teksti avasi uuden näkökulman testauksen tarpeellisuuteen. Koodaaja nimittäin kehittyy työssään nimenomaan palautteella. Mitä nopeampaa palaute on, sitä paremmin siitä voidaan ottaa opiksi. Tehdyt virheet ovat nimittäin vielä hyvin muistissa kun palaute tulee välittömästi. Kun softan kääntää ja sen itse toteaa toimivaksi, koodaaja saa ensimmäisen siivun palautteestaan. Toinen siivu onkin sitten testaajan vastuulla.

Huippuluokan testaaja on siis nopea palautteen antaja. Palautteen tulee olla suoraa ja täsmällistä, MUTTA:

Testaajan yksi arvokkaimista ominaisuuksista kehitystyössä on positiivisen palautteen antaminen. Luit oikein: positiivisen palautteen. Aivan kuten pienen koiranpennun koulutuksessakin, järkevämpää on kannustaa hyvää käytöstä kehuilla ja herkkupaloilla, kuin rangaista aina huonosta käytöksestä.

Koodaajan, kuten kenen tahansa ihmisen moraalin, motivaation ja onnellisuuden tason parantamisessa nimenomaan positiivinen palaute on kaikkein keskeisintä. Kyllä kaverille tulee hyvä mieli, kun välillä joku taputtaa olkapäälle ja sanoo:

“Sinä olet tehnyt perhanan hyvää työtä tänään! Sä oot hyvä tyyppi ja oot kyllä ansainnut pullakahvit.”