Arkisto: helmikuu 2012



Testauksen automatisointiko mullistaisi it-alan?

27. helmikuuta, 2012 | Kirjoittaja: Jussi Niittyviita
Kommentit: 13

Tietoviikon tammikuussa julkaisemassa artikkelissa puhutaan testauksen automatisoinnista ja it-alan muuttuvasta ilmapiiristä. Avasin artikkelin kiinnostuneena, mutta aivoni jäivät lyömään tyhjää heti ensimmäisen lauseen kohdalla:

Ohjelmistotestaajan työ ja koko testaaminen ovat muuttumassa.

Testauksen perimmäisenä tarkoituksena on nostaa esille ne virhekohdat tuotteesta, jotka haittaavat loppukäyttäjän käyttökokemusta. Vaikka testaaminen saattaisi lisääntyä tuotteiden monimutkaistuessa, testauksen tarkoitus ei muutu mihinkään. Onko siis tarkoituksenmukaista ajaa ohjelmistotestaajan työtä ja koko testaamista muutoksen tielle?

Tietoviikon artikkelin lisäksi useasta lähteestä kuulee nykyään samaa raitaa missä lauletaan, että pitäisi panostaa enemmän testauksen automatisointiin. Joillekin automatisointi tuntuu olevan uuden testamentin veroinen ohjenuora työelämän pitkospuille. Sen nimeen vannotaan ja siihen panostetaan aina vain enemmän ja enemmän. Liekköhän tässä ollaan muutoksen tiellä ohituskaistalla vai ajamassa rampilta alas hitaaseen ja tukkoiseen taajamaan…

Vaikka testauksen automatisointi kannattaakin tietyissä tilanteissa, mielestäni testauksen automatisoinnin yhteydessä ei voi puhua testauksesta. Kun testaustyö automatisoidaan, kyseessä on enää vain koneellinen tarkistus. Testauksen ja koneellisen tarkistuksen välillä on hurja ero. Niin pitkään kuin tuotteiden loppukäyttäjinä ovat ihmiset, ei varsinaista testausta kannata korvata koneellisesti. Koneet löytävät pieniä ja teknisiä nippelivirheitä, kun taas ihmiset löytävät fiilispohjaisia virheitä. Väitän, että olennainen osa virheistä löytyy jälkimmäisellä tavalla. Se on osa, joka vaikuttaa merkittävästi tuotteen myyntipotentiaaliin.

Jos testaamisen lisääntyessä testaajien määrä pienenee, ollaan ohjelmistokehityksessä hyvin vaarallisella tiellä. Tuolla tiellä merkittäviä virheitä jää löytymättä sitä mukaa kun rahaa palaa automatisoinnin suitsuttamiseen ja toteuttamiseen. Silloin kannattaa pysähtyä kysymään: Onko kyseinen yhtälö todellakin taloudellisesti kannattava?

Lissabonista Floridaan

14. helmikuuta, 2012 | Kirjoittaja: Antti Niittyviita
Kommentit: 4

Uusi manner löydettiin ja dokumentoitiin Eurooppalaisten toimesta ensikertaa vuonna 1492. Tuolloin tutkimusmatkailija Kristoffer Kolumbus löysi Amerikan etsiessään meritietä Intiaan. Löydöksen jälkeen alkoi tiivis merimatkailu Atlantin yli.

Merimatkojen tekemiseen sovelletut navigointimenetelmät olivat karkeita ja perustuivat suurelta osalta tähtien ja auringon aseman seuraamiseen. Määränpää saavutettiin onnistuneesti vain silloin kun kurssia korjattiin riittävän usein navigoinnin tulosten perusteella.

  1. Navigointi
  2. Kurssin korjaus

Se on totuus, jonka tiesivät jopa Viikingit 1000 vuotta sitten. Tästä huolimatta useat nykyaikaiset tietojärjestelmähankkeet lähtevät aina oletuksesta missä kurssi asetetaan yhden ainoan kerran suunnitteluvaiheessa. Sitten laitetaan silmät kiinni, peukut pystyyn ja toivotaan vain niin pirusti.

Kerta toisensa jälkeen mediasta saa lukea esimerkkejä hankkeista, jotka ovat kestäneet 5 vuotta ja sitten menneet pahasti pieleen. Maaliin osutaan vuosia myöhässä ja miljoonia euroja köyhempänä.

Navigointi ja kurssin korjaaminen

Navigointi ja kurssin korjaaminen

Ehdottaisinkin, että ne tietojärjestelmähankkeiden omistajat, jotka eivät uskalla luottaa sokeasti ajan ja rahan riittämiseen, tutustuisivat tähän kuvaan ja pysähtyisivät hetkeksi miettimään merimatkailun saloja.

Menestykseen ja maaliin voit siis päästä kahdella tavalla: Voit joko navigoida ja korjata kurssia riittävän usein, tai luottaa hyvään tuuriisi.