Author: ohjelmistotestaus

Jauhot suuhun. Kävin tovi takaperin Tampereella, Kataran Mikan tutkimusryhmän järjestämässä mallipohjaisen testauksen seminaarissa. Avauspuheenvuoron käytti Googlelta ja eBaylta testauskokemuksia kerännyt Julian Harty. Julian veti terävän avauksen testausautomaatiota käsittelevälle seminaarille:

Suurin osa testausautomaatiosta on roskaa ja joutaisi suorinta tietä romukoppaan.

Jos et usko väitettä, niin kokeile itse: Nasauta testit käyntiin ja ota sen jälkeen esimerkiksi serveriltä virrat pois. Tarkista tulokset.

Hämmentävän usein automatisoidut testit tuottavat hyvän pass-raten vaikka jotain oleellista ympäristöstä puuttuukin. Tällaisen kokeilun tarkoituksena on selvittää kuinka helppoa on saada automatisoidut testit tuottamaan väärää informaatiota. Kysymys on tehtyjen ratkaisuiden jatkuvasta kyseenalaistamisesta. Testauksen kohteen lisäksi on siis muistettava suhtautua kriittisesti myös itse testauksen toteutustapaan.

Testausautomaation yksi suurimmista synneistä on tuudittautuminen hyvän olon tunteeseen siitä että nyt on tehty paljon töitä. Työ tuntuu tulokselliselta kun on saatu ajettua valtava testimassa onnistuneesti läpi. Tässä tilanteessa on muistettava haastaa oma ajatusmaailma kerta toisensa jälkeen perustelemaan: Onko testauksen tavoite valtavan testimassan läpi ajaminen vai järjestelmän oleellisten virheiden kiinni saaminen? Entäpä jos automaation rakentamiseen käytetty aika olisi käytetty virheitä etsivään manuaaliseen testaukseen?

Testauksessa onnistumisessa on siis kysymys taidosta kyseenalaistaa, mutta pelkästään se ei riitä. Asiat täytyy osata myös kommunikoida muille. Täytyy olla sosiaalinen kaveri. Mutta sekään ei vielä riitä. Ongelmiin täytyy osata etsiä myös itsenäisesti ratkaisut ja esitellä ne sujuvasti kollegoille ja esimiehille. Näitä kokeneen testaajan taitoja myös me arvostamme ja etsimme… ympäri Suomen.

Ala testausguruksi ja lähetä hakemuksesi suoraan minulle osoitteella etunimi@ohjelmistotestaus.fi

Testitapaukset ovat yleensä paskoja. Ne on suunniteltu huonosti ja ne on kirjoitettu auki vielä huonommin!

Jos et usko väitettäni, niin kokeile itse:

Laadi 100 testitapausta ja tee kolmelle eri testaajalle samanlainen toimeksianto niiden ajamisesta.

Kaikki kolme testauskierrosta tuottavat erittäin suurella todennäköisyydellä erilaiset tulokset. Niiden ajaminen vie jokaiselta testaajalta eri ajan ja testien läpäisyprosenttikin eroaa kaikissa. Veikkaisin vielä että raportoitujen virheiden määrä jokaisella testaajalla on eri.

Kun asiaa pysähtyy hetkeksi ajattelemaan syykin on selvä. Testien laatija on liian usein eri henkilö kuin testien ajaja. Vaara piilee siinä että testien kirjoittajista oikeasti vain pieni osa on hyviä ohjelmoimaan ihmisten käyttäytymistä. Testitapausten kuvaukset harvoin onnistuvat luomaan jokaiselle lukijalle saman kuvan testin tavoitteista, taustoista ja suoritustavoista.

Tarkkojen testitapausten suunnittelu onkin tästä nimenomaisesta syystä erittäin riskialtista puuha. Testitapausten tarkkaa speksaamista perustellaan usein hyvän ja vertailukelpoisen historiatiedon keräämisellä erityisesti regressiotyyppisestä testauksesta. Kuitenkin testejä ajavat henkilöt vaihtuvat usein ja siten muuttuvat myös testitulokset. Perinteisessä speksipohjaisessa testausprosessissa palaakin hurjat määrät työaikaa testitulosten tarkistamiseen ja normalisointiin.

Se voi olla järkevää ajan käyttöä ainoastaan silloin kun projektin laskutusperiaate on tuntipohjainen ja työn maksajalla on pohjaton kassa.

Siksi suosittelenkin pohtimaan erikseen jokaisen projektin kohdalla edellä mainittua ongelmaa. Ratkaisu voi löytyä esimerkiksi näin:

1. Jokainen testaaja ajaa vain itse suunnittelemiaan testitapauksia. Itse laaditut proseduurit yleensä onnistutaan ymmärtämään oikein. Näin säästetaan aikaa testitulosten tarkastamisesta ja normalisoinnista.
2. Luovutaan testitapausten liian tarkasta laatimisesta. Siirrytään testitapausten kuvauksissa käyttämään vaikkapa tarkistuslistoja tai tutustutaan säikeistettyyn prosessimalliin. Näin säästyy aikaa paitsi testitulosten tarkastuksesta ja normalisoinnista, myös testispeksausesta, katselmoinneista.

Hassua. Yhtäkkiä en osaakaan kertoa mikä on hyvä testitapaus. Osaatko sinä?

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!

Tervehdys,

Viime viikolla kyselin LinkedInin TestausOSYn palstalla kommentteja testauksenhallintatyökalun hankinnasta palveluna. Vuoren Matti pohdiskeli aihetta vähän enemmänkin ja kasasi 50 kohdan listan, joiden avulla hankintaa voipi pohtia.

Tämän blogin lukijoillekin dokkarista voipi olla hyötyä, joten Matin luvalla linkitän dokumentin myös tänne. Aika tanakkaa tavaraa. Dokumentti löytyy tästä.

Ohjelmistokehityksen alihnakinnassa ja softaratkaisuiden ostamisessa on vakiintunut käytäntö ostaa tuotekehitys ja testaus samalta palveluntarjoajalta. Näin saatetaan tehdä koska tuntuu työläältä pyörittää kahta toimittajaa yhdessä projektissa. Sehän tuplaa myös projektinhallinnan työmäärän. Toisaalta saatetaan nähdä asia myös tuotekehityksen etuna. Se on ketterämpää kun kehitys ja testaus tulevat saman katon alta.

Usein näin järkeillessä kuitenkin unohtuu karu totuus, joka avautuu taannoisessa Dilbert-stripissä hauskalla tavalla:

Olemme aikaisemminkin kysyneet että kenen etua testaus palvelee silloin kun toimittaja on myös tuotteen testaaja?

Ongelmakenttä ei kuitenkaan ole yksiselitteinen. Tuoreessa Kauppalehden jutussa käsitellään Solteqin toteuttaman kassajärjestelmäprojektin epäonnistumista. Tässä projektissa testaus laiminlyötiin erittäin vakavalla tavalla tilausketjun jokaisessa vaiheessa:

Toimittaja on syyllinen siksi että se ei suorittanut järjestelmän testausta tuotantoympäristössä. Toisaalta tilaaja on syyllinen siksi että se ei huolehtinut laadunvarmistuksen toteuttamisesta etujensa mukaisesti. Kaiken lisäksi tilaaja teki ensimmäisen inventaarion vasta puoli vuotta kassajärjestelmän päivityksen jälkeen.

Kokenut testausasiantuntija olisi muutaman päivän työllä laatinut turvallisen suunnitelman järjestelmän tuotantoon siirtämisestä. Jos vain tilaaja tai toimittaja olisi huomannut laadunvarmistuksen asiantuntijalta tällaista kysyä. Kaikki olisivat säästäneet pitkän pennin.

Aikaisemmin väitimme että ohjelmistohankkeiden tilaajan on syytä hoitaa itselleen laatupoliisi valvomaan hänen etujaan. Solteqin tapauksessa oikeus kuitenkin katsoi että täysimääräisessä korvausvastuussa onkin järjestelmähankkeen toimittaja. Oikeus katsoi toimittaja olevan vastuussa projektin kauppasumman lisäksi myös tilaajan arvioiduista tappioista. Softavirheen kokonaiskustannukseksi Solteqille tuli 8000 euron sijasta huimat 560.000 euroa.

Solteqilta oli rohkea veto tulla tämän tapauksen kanssa julkisuuteen. Uskon että he ovat läksynsä oppineet ja softatoimitusten laatu on jatkossa täysin eri tasolla. Suosittelen Solteqia.

Oikeuden päätöksestä viisastuneena myös Ohjelmistotestaus.fi korjaa väittämää:

Tilaaja ja toimittaja: Varmistakaa aina yhdessä että laadunvarmistus hoituu ammattimaisesti ja objektiivisesti. Se jos mikä, on kaikkien etu!

Tämän päivän Tietoviikko kertoo Googlen astetta suuremmasta projektista. Google aikoo nimittäin digitoida kaikki maailman n. 130 miljoonaa kirjaa. Vielä en tiedä Googlen ajattelemaa ansaintalogiikkaa, mutta eittämättä siellä raha liikkuu kuluttajilta Googlelle ja Googlelta kustantajille. Onko lukijoilla tietoa siitä, miten Google aikoo tuota kirjastoaan käyttää?

Täytyy olla kohtuullisen robusti järjestelmä, joka kykenee toimittamaan kymmenien miljoonien käyttäjien saataville a) kaikkien maailman kirjojen kirjastodatan (sivumäärät, kirjoittajat, ISBN-koodit jne), b) kirjojen sisällön, c) mainion käyttöliittymän kirjatietojen selaamista ja lukemista varten, d) maksusysteemit sekä kuluttajille että kustantajille ja e) linkitykset näiden tietojen välille. Siellä liikkuu bitti poikineen ja testaajilla on varmasti mielekäs työmaa hakea kriittisiä bugeja.

Samoihin aikoihin Suomessa: Viime viikolla Tampereella ilmestyvä Aamulehti uutisoi: “Kirjaston uudet nettisivut eivät toimi vieläkään”.

Muutaman tunnin käytön jälkeen palvelin ei kestänyt rasitusta vaan kyykkäsi. Perinteisesti asiaa käännetään parhain päin, että ulkoasu ja rakenne ovat kyllä hyviä, mutta kovasti hitaita. Vielä muistetaan sanoa, että sivut kyllä toimivat mutta kovin hitaasti.

Aamulehden uutisen ensimmäinen kommentti kiteyttää aika hienosti oleellisen:

Voisin suositella testauslähtöistä kehitystapaa mitä suurimmalla lämmöllä. Toki kattavien testien tekemiseen menee työtunteja, mutta onpahan tekijöillä varmuus siitä että kuinka kehitettävä järjestelmä pelaa myös tuotannossa.

Lähettäjä: Ammattilainen määkin | pe 6.8 klo 10:37

Empähän tuota paremmin osaisi itsekään sanoa.

Kesälomat alkaa pikkuhiljaa olemaan ohi, mutta helteet senkun jatkuu! Yrittäkäähän jaksaa siellä toimistoissa.

Kesätervehdys arvon lukijat. Näin kuumottavimpien helteiden päätteeksi on hyvä palata hetkeksi ohjelmistotestauksen ja virheidenhallinnan ihmeelliseen maailmaan.

Kesän ajan olen seuraillut kuumana käyvää keskustelua älypuhelinrintamalla liittyen matkapuhelinten antenniongelmiin. Tarkemmin ottaen iPhone 4:n ongelmaan ja sen käsittelyyn. Uuden iPhonen rungon oikeaan alareunaan koskettaminen nimittäin pudottaa matkapuhelinverkon kuuluvuuden olemattomiin, kuten oheisesta videosta voi todeta.

Kyseessä on selvästi bugi, joka näyttää päässeen läpi useista laadunvarmistuksen tasoista aina hw-testauksesta loppukäyttäjätesteihin asti. Ammattimaisesti toteutetusta testausprosessista tämän tyyppisen virheen ei kuitenkaan pitäisi päästä läpi. Ei Applella eikä muuallakaan.

Minä väitänkin että tämä kyseinen virhe saatiin kiinni aivan oikeassa vaiheessa tuotekehityksen elinkaarta. Virhe pääsi kuitenkin markkinoille asti virheidenhallintaprosessin takia. Liian usein olen nähnyt kuinka täysin selkeitä virheitä arvioidaan ja todetaan “works as designed”.

Todetaan että bugi onkin feature. Näinhän sen pitääkin toimia!

Applella osataan kuitenkin markkinointi. Tuote-esittelyt suorastaan pullistelevat ylisanoja. Tuotteet ovat uskomattomia ja mahtavia. iPhone 4:n tapauksessa Apple on päättäny hoitaa ongelman jakamalla kaikille viasta raportoineille asiakkaille ilmaiset suojakuoret puhelimeen. Kun suojakuori on välissä, käsi ei pääse koskettamaan puhelimen pinnassa olevaa kriittistä aluetta. Näin toimimalla rivien välistä voidaan lukea että:

Olemme tiedostaneet virheen, mutta emme osaa sitä korjata. Vika on siis hardiksessa.

Kuitenkin markkinointiviesti on väkevämpi:

Me olemme inhimillisä ja myös me teemme virheitä. Rakastamme käyttäjiämme ja haluamme korvata virheemme antamalla lahjaksi puhelimeen suojakuoren.

Tämä toki herättää kätevästi loppuasiakkaan myötätunnon. Näin bugista tehtiin perhonen.

Oikeasti virheiden pukeminen featureiksi on vaarallista. Se on uhkapeliä sekä tuotteesi, että yrityksesi maineella.

Jos siis markkinointisi ei toimi kuten Applella, mieti tarkkaan ennen kuin edes yrität sitä.

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.