Tag: Suomi

Toimitusjohtaja Niittyviita kampanjoi ahkerasti voittaakseen Tieturin järjestämän Vuoden Testaaja 2012 -tittelin. Itsetuntonsa pönkittämiseksi Niittyviita valjasti oman yrityksensä blogin, lisäksi herra piti itsestään meteliä Facebookissa, Twitterissä, LinkedInissä, sähköpostilistoilla ja irkissä. Jakoipa jopa testauksen pikaopasta varmistaakseen voittonsa.

Tulokset julkistettiin eilen. Härskin kampanjoinnin ansioista oli kohtuullisen selvää, että Niittyviita voitti kilpailun. No onhan se kiva, mutta äänisaalis jäi surkeaan 25 %:iin kokonaisäänimäärästä. Voidaan puhua merkittävästä pettymyksestä.

“Näin kova kampanja, ja näin onneton tulos. Mun lapsetkaan ei varmaankaan rakasta mua enää” nyyhkii Niittyviita.

Niittyviitaa luonnehditaan kilpailusivustolla seuraavasti:

Antti on Suomen pitkäjänteisin testausbloggari ja pitää testausasiaa aktiivisesti näkyvillä sosiaalisessa mediassa. Hän on testauksen väsymätön puolestapuhuja ja antaumuksellinen valistustyöntekijä. Testausfirman toimitusjohtaja ja testausta aktiivisesti pohtiva ja siitä kirjoittava testausihminen. Yhdistelee erilaisia teemoja testaukseen ja pyrkii erityisesti vaikuttamaan johdon näkökulmaan tuoden esiin testauksen merkityksen ohjelmistoprojektien aikataulutuksessa ja liiketoimintariskien poistamisen ennen tuotteen julkaisua.

Kuvaus saa Niittyviidan mietteliääksi.

“Kauniita sanoja ja arvostan kyllä titteliä korkealle! Tavoittelin kuitenkin yksinkertaista ääntenenemmistöä, mutta itse asiassa samahan se on millä tavalla voitto tulee. Eihän niitä maaleja myöhemmin muista kukaan” Niittyviita jatkaa.

Niittyviita järjestää Oulussa paraatin voittonsa kunniaksi 30.4.2012 alkaen klo 12. Paraati lähtee liikkeelle Franzenin patsaan nurkilta. Paikalle odotetaan satoja iloisia juhlijoita.

“Hyvä fiilis itseasiassa. Kiitoksia kaikille äänestäjille!”

Mies on entisellään!

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.

Vuoden testaaja 2012 valitaan äänestämällä 11.4.2012 mennessä! Ehdokaslista ja äänestyslinkki löytyvät tästä. Käy siis antamassa äänesi nyt ehdokkaista parhaalle. Voittajan julkistus tapahtuu Tieturin järjestämässä Ketteryys & Testaus -tapahtumassa.

HUOM! Jotta ehdokasasettelusta saadaan mahdollisimman epäreilu, päätin jakaa vaalikamppanjassani 20 valikoitua opetusta testauksesta ilmaisen pikaoppaan muodossa. Törkeää ja halpamaista, tunnustan 🙂

Pikaopas on oikein mukavaa vessalukemistoa ja kulkee kätevästi mukana maailmalle myös läppärillä tai ipadissa! Se toimitetaan pikana suoraan sähköpostiisi. Pääset tekemään tilauksen tällä sivulla!

Enjoy!

Taide ei ole koskaan virheetöntä. Taide synnyttää teoksia, jotka ovat taiteilijan sisäisten ajatusten kanavointia konkreettiseksi ruumiillistumaksi. Näitä asioita ja taiteenlajeja on nykyään määriteltävissä lukematon määrä aina varhaisimmista luolamaalauksista muinaisen Egyptin eeppisten temppelien kautta moderniin audiovisuaaliseen hengentuotokseen. Kaikkia taiteenlajeja yhdistää yksi ainoa tekijä:

Taide herättää tunteita.

Taiteilijalla on lähes aina teostensa taustalla vakaa pohjavirta, vaikka pinnalla näyttäisi kuohuavankin. Tuo pohjavirta on se Fiilis, jonka taiteilija haluaa teokseensa ruumiillistuvan. Se ohjaa siveltimen liikettä pellavakankaalla, mustekynän reittiä paperilla ja sormien tanssia pianon koskettimilla. Se pitää tanssijan askeleen vakaana ja kapellimestarin tahtipuikon sulavassa liikkeessä. Kukaties se ohjaa runoilijankin kättä viinapullolle palkkapäivänä.

Fiilis on se kokonaisuus, joka heijastaa pienimmänkin valonpilkkeen taideteoksen pinnasta tarkastelijan silmään ja sitä kautta hermoratoja pitkin aktivoimaan ja kutkuttelemaan aivojemme tunnekeskusta. Fiiliksestä emme löydä emmekä edes tarkoituksella etsi mitättömiä virheitä; vain kokonaisuus merkitsee. Tuosta kokonaisuudesta joko nautimme tai emme nauti. Kun taideteos herättää Fiiliksen, on se tehnyt tehtävänsä.

Unohtakaa turhat tilastot virheitten määristä, tuotteen maturiteetista, pass-fail-suhteista ja vaatimusten täyttämisestä. Kokeilkaa joskus löytää projektinne koukeroista ja maallisesta vilskeestä Fiilis. Ehkäpä testauksenkaan tarkoitus ei ole valmistaa virheetöntä tuotetta vaan pikemminkin tuote, josta kanavoituu se suunnittelijan, arkkitehdin, koodaajan ja taiteilijan hengen syvin tuotos: Tunne.

Ohjelmistoprojekti koostuu kolmesta olennaisesta kuluerästä. Juuri rakkaudella säveltämäni loru kertoo, mistä tässä kolmen kärjessä on kysymys.

Mistä on pienet ohjelmistoprojektit tehty,

mistä on pienet ohjelmistoprojektit tehty?

Koodauksesta, testauksesta, teknisen velan mittauksesta.

Niistä on pienet ohjelmistoprojektit tehty!

Jos tällaista pientä, noin miljoonan euron, ohjelmistoprojektia pysähtyy hetkeksi ajattelemaan tarkemmin, niin sen kulurakenne voisi näyttää tältä:

1. Koodaus. 600k€: Ohjelmiston kehittäjällä on tarve saada softa toimitusvalmiiksi. Softan kaikkien haluttujen ominaisuuksien kehittäminen vie karkeasti ajatellen saman määrän työaikaa ja rahaa kaikissa tapauksissa. Featuret vaan pitää saada valmiiksi. Sitä faktaa ei voi paeta.
2. Testaus. 50k€: Ohjelmistoprojektin toinen oleellinen kuluerä on testaus. Tyypillisesti tavoitellessa kovaa tulosta softaprojektista testaus on se paikka mistä leikataan kustannuksia. Useimmiten testauksen kulut ovat luokkaa 5-10% kehityksen kokonaiskuluista, kun suositus olisi 20-40%.
3. Tekninen velka. 350k€: Kaikissa ohjelmistoprojekteissa muodostuu teknistä velkaa. Se koostuu lopputuotteeseen päätyvistä virheistä ja ongelmista, jotka aiheuttavat toimituksen jälkeen kustannuksia reklamaatioiden, takuukorjausten ja päivitysten muodossa. Lisäksi se voi aiheuttaa tulonmenetyksiä, kun maine laatutuotteiden toimittajana kärsii.

Kun tällainen projekti tuottaa liikevaihtoa 1.200k€ tulos on tasolla 200.000€ (20%). Hyvin toteutettu testaus voi kuitenkin säästää ohjelmiston elinkaaren kuluja suhteella 1:3.

Oikein suunnitellun testauksen avulla 100k€ lisäinvestointi laatuun voisi auttaa löytämään jopa 1000 bugia enemmän projektin aikana. Tekninen velka jäisi näistä ongelmista syntymättä ja ne voitaisiin korjata jo tuotekehityksen aikana. Lisäinvestoinnin avulla mainittu kolmen kuluerän summa onkin vain 800k€, mutta mitä se sitten tarkoittaa?

No tietysti lisää rahaa! Ohjelmistotuotteen tulos kaksinkertaistuu ja laadukkaampi tuote tekee myös varmasti paremmin kauppansa!

Tietoviikko pohdiskelee aihetta, että voiko julkisella sektorilla huonosta IT-hankkeesta kieltäytyä. Siellä puhutaan hienoja sanoja ja kerrotaan, että hieno strategia ict-hankintoihin pitäisi olla. Minä uskon, että IT-strategiatyöryhmistä ei löydy ratkaisua tähän ongelmaan.

Toimikoon tämä kirjoitus enemmän hahmotelmana ja keskustelunavauksena, kuin ilmiselvänä faktana. Kirjoituksen tarkoituksena pohdiskella, minkä vuoksi julkiset it-hankkeet epäonnistuvat niin usein. Aluksi käyn lyhyesti läpi lähteiden it-hankkeiden onnistumisten ja epäonnistumisten syytä. Sitten kuvataan lyhyesti julkisten it-hankkeiden kilpailutusmenettelyt. Voi olla, että nuo kaksi asiaa liittyvät toisiinsa.

Googlettamalla “Why software projects fail” löytyy sivustokaupalla syitä, miksi it-projektit ylipäätään voivat mennä pieleen. Listoilla on hieman eri painotuksia, mutta jokaisessa nousee esille loppukäyttäjän näkökulman puute. Siis se, että hankkeen speksaa, kilpailuttaa, tilaa ja hyväksyy jokin aivan muu taho, kuin loppukäyttäjät. Lisäksi johdon tuki oli usein puutteelista tai jopa olematonta. Oleellista on huomata, että teknologiset haasteet tai henkilöiden “epäkurantti” osaaminen eivät olleet lähellekään yhtä merkityksellisiä tekijöitä.

Onnistuneille projekteille ominaista on, kuten edellisen kappaleen perusteella arvata saattaa, että loppukäyttäjät ovat alusta asti osallisena projektiin. Tämä auttaa paitsi tekemään toimivamman softan, helpottaa se myös käyttöönottovaihetta, kun ohjelmisto on tuttu. Loppukäyttäjien mukanaolo puolestaan johtaa väistämättä siihen, että ohjelmiston vaatimuksia lisätään, muutetaan ja poistetaan kehitystyön edetessä. Tämä vaatii joustavia kehittäjiä ja projektipäälliköitä, jotka oikeasi haluvat saada asiakkaan tyytyväiseksi ja tuotteen erinomaiseksi.

Julkiset IT-palveluiden kilpailutukset etenevät kutakuinkin seuraavasti:

1. Julkinen yksikkö päättää, että tarvitaan Järjestelmä.
2. Julkinen yksikkö saattaa tehdä tietopyynnön, missä potentiaalisilta toimittajilta pyydetään kommentteja.
3. Hankittavan Järjestelmän vaatimusmäärittely tehdään parhaan kyvyn ja osaamisen mukaan. Mukana arvailemassa saattaa olla myös tulevia käyttäjiä
4. Toimittajat kilpailutetaan ja valitaan kokonaistaloudellisesti edullisin

Valitulla Toimittajalla on speksi, jonka perusteella ohjelmisto pitää toteuttaa kiinteään hintaan. Muutosten tekeminen on hankalaa, koska se muuttaa Toimittajan aikataulutusta ja sitä kautta kasvattaa kuluja tai vaihtoehtoisesti Julkisen yksikön tulisi kasvattaa budjettia. Se on aika hankalaa julkisella sektorilla, joten mennään alkuperäisen suunnitelman mukaan.

Näin ollen, julkisissa hankinnoissa on rasitteena kilpailutuksesta ja kilpailulainsäädännöstä johtuva rakenteellinen ongelma. Loppukäyttäjien tiedon ja asiantuntemuksen hyödyntäminen projektin kuluessa on tehty kutakuinkin mahdottomaksi. Ja kuten aikaisemmin todettiin, on se suurin yksittäinen syy, miksi IT-hankkeet epäonnistuva.

En tunne kilpailulainsäädäntöä kovin hyvin. Jos kilpailutuksen voisi hoitaa siten, loppukäyttäjät saadaan järkevästi mukaan hankkeeseen, niin lakimuutoksia ei silloin tarvittaisi. Ainoastaan osaamista ostoihin. IT-järjestelmän kilpailutusta ei voida tehdä samoilla menetelmillä, kuin lumen aurausta tai lämpöpumppujen asennusta.

Avaan keskustelun!

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?

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ä.

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.

Akku irti todellakin. Paras ohje, mitä kannattaa ensimmäisenä noudattaa ohjelmistovian sattuessa. Kuinka monta kertaa olet nykypuhelimien aikana joutunut käyttämään akkua pois paikaltaan? Kuinka monta kertaa olet käynnistänyt tietokoneesi kun yksittäinen ohjelma jarruttaa koko konetta? Oletko joskus joutunut sammuttamaan autosi bugisen ajotietokoneen temppuilun takia? Mikä parasta, joissakin automalleissa on nykyään pikakiinnikkeet akun johdoille ainoastaan siitä syystä, että ohjelmistovian sattuessa voidaan käyttää “akku irti”.

Mistä johtuu, että nykyaikana ollaan hyväksytty tiettyjä alkujaan negatiivisia asioita lähes arkirutiineiksi? Kun itse ostan kännykän kaupasta haluan kuvitella, että se toimii ilman mitään maagisia akunirrotuksia tai 8 sekunnin virtanappirituaaleja. Enkä todellakaan halua liata käsiäni moottoritien varrella auton akkupiuhoja irroittaessani taikka hakata läppärini reset-nappia, kun MS Office alkaa hyppimään silmille. (Tähän Applemies sanoisi, että osta Mac. – En osta.)

Aikani mietiskeltyäni päättelin, että tämä kaikki johtuu siitä koska niin on aina ollut. Ilmiö on sama kuin normaalin tupakan käytössä. Jos tupakka tulisikin vasta nyt uutena tuotteena markkinoille, se luultavasti kiellettäisiin vakavana terveyshaittana. Mutta koska tupakka on ollut markkinoilla jotakuinkin niin pitkään kuin ihminen on tulta käyttänyt, se hyväksytään arkipäiväsenä vaikkakin yleisesti negatiiviseksi miellettynä asiana. Kun akkua ollaan irroiteltu jo ties kuinka pitkään, se hyväksytään yhtälailla negatiivisin tuntein.

Sama hyväksyminen on syöpynyt jopa niin pitkälle, että suuri osa puhelinvalmistajien testaajista eivät koskaan pidä testattavassa laitteessa “takakantta” paikallaan. Tämä ainoastaan sen takia, että akku olisi helpompi irrottaa ongelmatilanteen sattuessa ja lisäksi sen takia, että puhelimen tekninen tarkastelu tietyin apulaittein on vaivattomampaa, kun akun saa poistettua käden käänteessä. Tämä tuskin on tarkoituksenmukaista loppukäyttäjätestausta. Kukahan oli se suuri testaajanero, joka ensimmäisen kerran huomasi, että vian saa korjattua akun irroittamisella.

Nykyaikainen yhteiskunta perustuu virrankulutukseen. Minkä ihmeen takia pitäisi yksittäisestä laitteesta katkaista virta saadakseen sen taas toimimaan?

Akku irti! Kuten sanonta kaikuu vieläkin mielen pimeimmissä syövereissä vuosia sitten äijäporukalla toteutetun lasketteluviikonlopun jälkeen saavuttaen yhden ainoan kerran ihmiskunnan historiassa hetken häivähdyksen positiivisesta merkityksestä…

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.