Arkisto: joulukuu 2010



Kannattaako bugia korjata?

23. joulukuuta, 2010 | Kirjoittaja: Jussi Niittyviita

Testausalalle vihkiytyneenä ihmisenä automaattinen vastaukseni tähän kysymykseen on ”ehdottomasti kyllä!”. Vastaus on hyvä yleisesti ajateltuna, mutta entäs sitten talous- ja mainenäkökulmasta katsottuna. Tältä kannalta virheen vakavuus ja sen toistettavuus näyttelevät pääroolia. Heitän esimerkkinä kaksi skenaariota:

1. Conan Barbaarin uudenkarhea kahden käden miekka osoittautuukin tylsäksi. Valmistusvirhe on selkeä ja toistettavissa jokaisella käden heilautuksella. Conan Barbaarin taistelutaitoihin tämä tuskin vaikuttaa, mutta tavallisen tusinataistelijan käsissä miekka koituu käyttäjänsä kuolemaksi.

2. He-Manin juuri pakasta vedetty yhden käden miekka on terävä ja leikkaa lihaa todella huonosti vain tietyssä osumakulmassa. He-Man on myöskin Conanin veroinen miekkamies, jonka taistelutaktista näkemystä yksittäiset huonot viillot eivät juuri horjuta, mutta se yksikin huono osuma voi muuttaa taistelun suunnan täysin odottamattomaan.

Conanin ja He-Manin yhteisellä miekanvalmistajalla on valinta edessä. Jatkaako tuotantoa samanlaisena vai korjatako virheet? Bisnesmiehenä miekanvalmistaja punnitsee valmistusvirheiden vakavuudet tarkoin ja päätyy korjaamaan Conanin tylsän miekan mutta jatkaa He-Manin terävän miekan tuotantoa normaaliin tapaan. Miekanvalmistajan mielestä korjauskustannukset ovat joskus huomattavasti suuremmat kuin kyseisestä virheestä aiheutuvat kustannukset.

Oikean elämän esimerkki tästä valinnasta on Joulupukin Hiace-reen viimeisin otsikoissa ollut valmistusvirhe SUA (sudden unintended acceleration). Virheen kuvaus lyhyesti: Petteri on käynyt salilla liian usein. Kysymys kuuluu onko rekivalmistajalla ollut kyseinen virhe tiedossa, kun reet ovat päästetty tuotantoon? Virheen esiintymismäärä eli toistettavuus on hyvin pieni verrattuna myytyihin rekiin. Tämän kaltaisten virheiden korjauskustannukset ovat lähes varmasti suuremmat kuin virheestä suoraan aiheutuvat kustannukset. Virheestä epäsuorasti aiheutuvat kustannukset ovat kuitenkin asia erikseen. Henkilövahinkoihin ja kuolemantapauksiin johtavat virheet nostavat sataprosenttisella varmuudella kunnon mediamylläkän, jonka seurauksena ihmiset eivät välttämättä enää luotakaan Joulupukkiin kuten ennen.

Olisiko sittenkin kannattanut korjata se mitättömän kokoinen pieni bugi?

Testausgurut toivottavat virheetöntä joulua ja kustannustehokasta uutta vuotta kaikille tasapuolisesti!

Mutta eihän se Agilea ole

20. joulukuuta, 2010 | Kirjoittaja: Antti Niittyviita
Kommentit: 2

David Devaaja paukuttelee koodia projektissa yhdessä Kari Koodarin kanssa. Parin viikon Sprinttiä on nyt painettu viimeiset päivät pitkillä ylitöillä. Kun poikien työ lopulta valmistuu, heivataan softa ja juuri valmistunut featurepaketti Tiina Testaajan käsittelyyn. Aika usein sitä sanotaan Agileksi.

Hirveän usein firmat kertovat tekevänsä softaa ketterästi. Siitä huolimatta tarkempi pureutuminen softakehityksen ytimeen paljastaa edellä kuvatun tilanteen. Yleensä kyseessä onkin inkrementaalinen tai iteratiivinen (IID) tapa tehdä softaa. Siinä devaajat vetäytyvät rakentamaan kierrokselle sovittujen vaatimusten näköistä softaa ja valmis setti testataan. Äkkiä Agileksi väitetty työ vaikuttaakin sarjalta pieniä vesiputouksia.

Speksaus-devaus-testaus,

speksaus-devaus-testaus,

speksaus-devaus-testaus.

Tämä ajatusmaailmaero aiheutti keskustelua myös Oulussa järjestetyssä TestausOSY:n Agile-seminaarissa. Inkrementaalinen softakehitys ei nimittäin ole automaattisesti Agilea. Agile sen sijaan on luonteeltaan inkrementaalista.

Keskeisimmät erot tulevat tiimityön luonteesta ja nopean palautteen merkityksestä. Palaute ei ole nopeaa, jos työ tehdään vaiheissa ensin devaus, sitten testaus. Silloin ei myöskään ole kysymys tiimityöstä vaan kahden tiimin yhteistyöstä. Hämmentävää, eikö totta?

Minusta Agilen ero perinteiseen inkrementaaliseen softakehitykseen tiivistyy seuraaviin kohtiin:

  1. Tiimi on itseorganisoitu: ei managereita, ei pakotettuja prosesseja
  2. Palaute on aina nopeaa: testaajalta devaajalle, asiakkaalta tiimille
  3. Työ mukautuu pintautuviin vaatimuksiin: ei pitkiä inkrementtiplaneja
  4. Työkalut auttavat tavoitteen saavuttamisessa: ne eivät määrää miten se saavutetaan

Jotta inkrementaalisesta saadaan oikeasti Agilea, ihmisten täytyy oppia päästämään irti vanhasta ajatusmaailmasta ”hyvin suunniteltu on puoliksi tehty”. Täytyy lopettaa yritykset ennakoida onnistumista mittaroinnilla tai spekseillä. Täytyy oppia hyväksymään epävarmuutta ja ennakoimattomuuta. Asiat eivät aina mene kuten etukäteen oli suunniteltu. Ennen kaikkea ihmisten täytyy uskaltaa!

Työkalut ja prosessit tulevat ja menevät. Pääasia on, että tulosta syntyy ja softa toimii!

Mitä sertifikaatti kertoo testaajasta?

7. joulukuuta, 2010 | Kirjoittaja: Antti Niittyviita
Kommentit: 4

ISEB, ISTQB, CSQA, CSTE, CQIA, CTM, SSBB ja CSTP. No huh huh sanon minä. Testausalan sertifikaatteja on moneen junaan, mutta mitä ne oikeasti opettavat?

Tietysti sertifioinnista jää kouraan todistus. Todistus kertoo siitä että tietty testausosaamisen ja terminologian perustaso on saavutettu. Se kertoo että tentistä on päästy läpi ja kysymyksiin löytyi oikeat vastaukset.

Which of the following would you not use when choosing test techniques?

  1. Level and type of risk
  2. Time and budget
  3. Regulatory standards
  4. Recommendations from developers

Edellä on esimerkki ISEB serfitioinnin tenttikysymyksestä. Jos omaa edes vähän käytännön kokemusta muuttuu tähän tehtävään vastaaminen vaikeaksi ellei aivan mahdottomaksi(*). Testaustekniikoita valitessa on tietysti tärkeää miettiä riskejä, resursseja, lakeja ja standardeja. Ihan yhtälailla tärkeää on keskustella devaajien kanssa. Yksikään tiimi ei toimi jos joku sooloilee. Vastaavanlaisia, ristiriitaisia tunteita herättäviä kysymyksiä ovat kaikki sertifiointitentit pullollaan.

Ehkä juuri siksi minusta onkin pitkään tuntunut, että sertifikaatit eivät yksinkertaisesti sovellu nykyaikaiseen testaukseen. Niitä ei voi pitää testauksen hyvyyden mittarina, sillä ne yrittävät hieroa testaajat samaan ajatusmaailmaan ja muottiin. Kuitenkin parhaat tulokset testaustyöstä saavutetaan aina kun samaa asiaa katsotaan yhtä aikaa useammasta näkökulmasta. Erilaiset ihmiset eri suunnilta. Katvealueita jää vähemmän.

Sertifikaattikoulutukset ovat kuitenkin yleensä varsin asiallisia. Niissä on liikkumatilaa keskustelulle, kritiikille ja käytännön kokemuksellekin. Juuri siksi uskon, että sertifikaatit kaikesta huolimatta kertovat sen, mitä testaajan voi olettaa vähintäänkin tietävän. Tärkeimmän ne kuitenkin jättävät aina kertomatta.

Sertifikaatti jättää kertomatta sen, mitä testaaja oikeasti osaa.

(*) ISEB:in mukaan ainoa oikea vastaus tehtävään olisi ollut tuo viimeinen kohta 4.