Avainsanat: ‘exploratory’

Testaaja samoilee sienimetsällä

maanantai, 23 huhtikuuta, 2012 | Kirjoittaja: Antti Niittyviita

Erittäin herkullisen, mutta kuitenkin myrkyllisen korvasienen satokausi lähestyy kovaa kyytiä. Sehän tarkoittaa samoilemista hiekkapohjaisissa kangasmetsissä. Kokenut korvasienestäjä tietää parhaat paikat ja löytää fiiliksellä myös uudet apajat.

Uuden kauden tullen Simo Sienestäjä ajelee jälleen tutun metsätien päähän ja lähtee patikoimaan saalisrepun kanssa. Tavoitteena on päästä makkaranpaistoon läheisen lammen rantaan, kuten aina keväisin. Simo samoilee kangasmaastossa bongaillen aktiivisesti reitillään olevia korvasieniä. Saalistakin löytyy ja reppu painaa mukavasti makkarapaikoille päästessä. Simo on tyytyväinen

Simon päivätyö on ohjelmistotestaus. Hän päättää kokeilla tällä kaudella työpaikalta tuttua menetelmää ja kirjaa reittinsä alla olevalle kartalle tarkasti. Askel askeleelta. Kun Simo on saanut edellisen saaliin ryöpättyä ja pataan, hän lähtee uudelle metsäretkelle. Vieläkö saalista mahtaa kertyä, jos Simo samoilee makkarapaikoille samoja jalanjälkiä?

 

Että näin. Toteaa Simo makkarapaikoilla. Toisella kerralla kuljetut kilometrit eivät tuottaneet odotettua tulosta. Sienimatkan dokumentointi vei kohtuuttomasti aikaa ja matkan uudelleen kulkemisen konkreettiset tulokset jäivät laihoiksi. Simo saattoi vain todeta itsestään selvyyden. Parhaat tulokset syntyvät, kun hän valitsee hieman uuden reitin jokaisella reissulla erikseen.

Aivan sama pätee ohjelmistojen testaukseen. Uusia bugeja ja uutta tietoa testattavasta tuotteesta löytyy joka kerta vähemmän, kun testaajalle puetaan ravihevosen silmälaput ja laitetaan kulkemaan samaa polkua kerran toisensa jälkeen.

Jos rahaa ja aikaa on rajallisesti käytettävissä, niin kannattaa keskittyä olennaiseen. Testien suunnittelussa tärkeintä on kuvata tavoite. Se, mitä tulee tulla testatuksi. Kun testaaja saa valita reitin itse, tuloksia syntyy varmasti enemmän.

Share

Mitä yhden virheen hinnalla olisi saanut aikaan?

keskiviikko, 11 tammikuuta, 2012 | Kirjoittaja: Antti Niittyviita

Cadillac SRX on jämäkän näköinen auto. Sitä valmistaa maailman suurin autovalmistaja General Motors. Vuoden 2011 mallin tullessa markkinoille ajoneuvon matkustajaturvallisuus oli ratkaistu ohjelmistolla, jossa kaikkien istuinpaikkojen ilmatyynyistä vastasi yksi järjestelmä.

Markkinoille tulon jälkeen GM:n insinöörit huomasivat kauhukseen hyvin perustavanlaatuisen virheen ilmatyynyjen hallintajärjestelmässä. Mikäli pelkääjän paikalla ei ajon aikana istu ketään, järjestelmä kytkee pois päältä myös takamatkustajien kattokiskossa olevan ilmatyynyn, joka suojaa päätä kuollettavalta iskulta.

Vian löytymisen jälkeen GM joutui kutsumaan Yhdysvalloissa 47,401 ja muualla Pohjois- Amerikassa 3,099 autoa huoltoon ja järjestelmäpäivitykseen. Siis yhteensä 50,500 autoa. Huoltokutsun toimenpiteet eivät takuulla olleet kovin yksinkertaiset.

Jos yhden auton softapäivitysprosessin läpivienti kutsun lähettämisestä huoltoon veisi yhden tunnin valmistajan ja huoltoyritysten työaikaa se kustantaa maltillisella 50 € tuntihinnalla 2,525,000 €. Puhumattakaan imagohaitasta tai asiakkaalle aiheutuneesta mielipahasta.

Lupasin taannoin myydä vain testauksen konkreettisimpia tuloksia – löytämiäni bugeja – hintaan 79 € / kappale. Tuohon hintaan minä olisin sitoutunut metsästämään GM:lle 31,962 bugia.

Share

Tarkistuslistapohjainen tutkiva testaus

keskiviikko, 2 maaliskuuta, 2011 | Kirjoittaja: Antti Niittyviita

Olemme vuosien varrella valittaneet ankarasti testaukseen liittyvistä asioista. On valitettu huonoista työkaluista, testitapausten suunnittelusta, jäykkäniskaisesta yrityskulttuurista, väärien asioiden tekemisestä ja tehottomuudesta. Valitusta on riittänyt, mutta nyt päätimme muuttaa testaustyön luonnetta heti kerralla. Päätimme kirjata ylös sen mitä useimmat testaajat huomaamattaan jo työkseen tekevätkin.

Me törmäämme yhä maailmalla liikkuessamme muka superhienoihin testispekseihin. Testien suunnitteluun on käytetty pirusti työaikaa ja se tuntuu maksajasta varmasti hyvältä. Yhteistä näille noin 80%:lle perinneprojekteista on törkeän huonot testitapaukset. Yleensä testitapaukset kertovat yksityiskohtaisesti MITEN testi suoritetaan. Silloin nus.. viilataan pilkkua.

En tietenkään sano, että viilaminen on mitenkään tylsää hommaa. Bisneksen tekemisessä paukkuja vain käytetään silloin ihan vääriin asioihin.

Testitapauksen tulee ensisijaisesti kertoa MITÄ tulee tulla testatuksi! Sen voi ihan oikeasti sanoa muutamalla lauseella. Oikeastaan Twitter on todistanut, että useimmat asiat voi sanoa vain 140:llä merkillä!

Testauksenhallintajärjestelmien käyttöä ja testaustyön dokumentointia puoltavia perusteluja on runsaasti. Mutta kuinka voitaisiin yhdistää nopea ja tavoitekeskeinen testaussuunnittelu, tutkiva testaus ja sopiva dokumentoinnin taso raportointia ajatellen?

Erittäin toimivaksi ratkaisuksi olemme huomanneet tutkivan testauksen jota tuetaan tarkistuslistoilla. Homma toimii siten, että testispeksit tehdään yksinkertaisena tarkistuslistana asioista mitä session lopussa tulee vähintään olla testattuna. Otsikointiin riittää helposti tuo 140 merkkiä ilman että järkeään käyttävälle testaajalle jää epäselväksi testin tavoite. Testitapauksen askelet ja muun oheiskrääsän olemme heittäneet mäkeen. Yleensä niiden kanssa säätäminen syö vain aikaa, eli rahaa.

Tarkistuslistaa voi käyttää testauksenhallintajärjestelmästä ja tuloksetkin voi kirjata sinne. Myös Excel toimii varsin helposti kun muistaa minimalistisen lähestymiskulman.

  • Testien suunnittelu ja speksaaminen on supernopeaa
  • Testien ajaminen ei aiheuta putkinäköisyyttä vaan on tutkivaa
  • Virheitä löytyy merkittävästi enemmän käytettyyn rahamäärään nähden
  • Pomokin tykkää kun pystytään lyömään statsit ja rapsat tiskiin
  • Tarkistuslistat kelpaavat myös esimerkiksi käyttöönottoinsinöörin työvälineeksi

Asiaa voi pysähtyä pohtimaan myös testausammattilaisen näkökulmasta. Hänen voi huomata tekevät töitä hyvin saman kaltaisilla menetelmillä jo valmiiksi. Ainoa ongelma on, että usein hän tekee sen kaiken jäykkäniskaisen, pysähtyneen ja muutosvastarintaisen prosessin kahlitsemana. Siksi tuloskaan ei aina tyydytä!

Saat enemmän vastinetta rahoillesi, kun uskallat antaa testausosaajasi hoitaa hommat kuten osaajan kuuluukin.

Share