Tag: Suomi

  • Vuoden 2011 kalleimmat bugit listattu

    Test Magazine on listannut vuoden 2011 kalleimmat softabugit.

    Kalleimman bugin ykköspaikan valloitti rahoituspalveluita tarjoavan yrityksen softavirhe, joka aiheutti sijoittajille 217 miljoonan dollarin tulonmenetykset. Lisäksi USA:n arvopaperimarkkinoita valvova elin SEC lätkäisi päälle 25 miljoonan dollarin sakon. Näin ollen yhden bugin hinnaksi yritykselle tuli 242 miljoonaa Yhdysvaltain dollaria eli n. 185 miljoonaa euroa.

    Koko listauksen voit lukea täältä.

    On jälleen hyvä hetki muistuttaa:

    Testaus on investointi. Investoinnin tarkoituksena on löytää virheet siinä vaiheessa, kun niiden korjaaminen on halvinta.

    Hyvää vuotta 2012 kaikille!

  • Illuusio ainutlaatuisuudesta

    Keskustelen paljon tuotekehitystä ammatikseen tekevien ihmisten kanssa. Jotkut tekevät monimutkaisia suunnittelujärjestelmiä. Toiset taas hankalia verkkosovelluksia. Kolmannessa yrityksessä työskennellään tuotannonohjausjärjestelmien kanssa. Kaikki kuulostavat niin kovin erilaisilta. Minusta on ollut kiinnostavinta huomata, että näissä keskusteluissa on poikkeuksetta yksi yhteinen tekijä. Kaikki nimittäin kertovat kuorossa:

    Meidän tuotteemme ja toimialamme on niin ainutlaatuinen, että uusien kavereiden sisäänajo vie vuosia

    Höpö höpö, sanon minä. Teidän toimialanne ja bisneksenne varmaankin on ainutlaatuista, mutta teidän tuotteenne on softa muiden joukossa. Siellä pyörii aina samat ohjelmointikielet, rajapinnat, serverit ja clientit kuin kaikilla muillakin. Softakehityksenne tavat ovat ihan samanlaiset kuin sadassa muussakin softaa tekevässä firmassa. Samanlaiset bugit toistuvat järjestelmästä toiseen oli kysymys kuluttaja-asiakkaiden web-palvelusta tai teollisuusyrityksen valvontasoftasta.

    Toimialaosaaminen on toki kaikilla aloilla tarpeellista, mutta tiedättekö mitä ne ihmiset ihan jokaisessa firmassa ovat ammatiltaan? He kuuluvat ohjelmistojen kehitystiimeihin. He ovat ihan tavallisia koodaajia, testaajia, speksaajia ja managereita. Heillä kaikilla on hyvin samankaltainen tausta. Ja loppupeleissä he osaavat hommansa perhanan hyvin.

    Toimivaa koodia syntyy, bugeja löytyy ja designikaan ei ole mikään ongelma. Toimialan ymmärtäminen karttuu kyllä vuosien varrella, mutta ihan yhtä kovaa kyytiä tekijät urautuvat ja kuppikuntaistuvat. Halutaan kiihkeästi uskoa omaan ainutlaatuisuuteen. Lopulta uusia ideoita syntyy vähemmän ja hommia paiskitaan jääräpäisesti samalla tavalla kuin niitä on “meillä aina tehty”.

    Väitän, että toimialasi ainutlaatuisuus on illuusio mikä syntyy, kun istut kavereinesi samalla hiekkalaatikolla liian pitkään. Välillä kannattaa käydä tuulettumassa ulkona. Katsoa avoimin mielin, miten muut tekevät sitä ihan samaa työtä kuin sinäkin.

    P.S. Onko sinun tuotteesi ainutlaatuinen? Eikö sitä voi testata ilman vuosikausien kokemusta? Ilmoitta asiasta minulle, niin lähetän täysin ummikon testaajan paikalle. Väitän, että kahdessa viikossa kaverista tulee hyödyllinen testaustiimin jäsen. Jos näin ei käy, saat rahasi takaisin ja tarjoan nöyränä poikana kostean illallisen.

  • Avoin työpaikka: Kivireen vetäjä

    Prove on kotimainen talo täynnä ohjelmistotestauksen guruja. Ammattitaitomme salaisuus löytyy tuskasta ja pitkistä työpäivistä! Ruoskimme itseämme ja toisiamme päivästä toiseen kohti suurempia voittoja. Gurumme metsästävät bugeja ympäri Suomen (mm. Oulussa, Tampereella ja Helsingissä). Pitsinnypläys ja tyhjänpäiväinen papereiden pyörittely ei meitä kiinnosta. Me tähtäämme todellisiin tuloksiin.

    Proven guruilla on jo muuten Suomi hyppysissä, mutta viimeinen sokea pisteemme löytyy etelästä. Siksi etsimme testauksessa gurunviittaa jo kantavaa hengellistä johtajaa julistamaan testauksen ilosanomaa pääkaupunkiseudulla. Liikevaihtomme (2011 reilu miljoona) on kasvanut 100%:n tahdilla viime vuosina ja haluamme ylittää itsemme puristamalla kaikista vielä pikkuisen enemmän.

    Barona IT hakee Provelle siis jämerää ja kaukonäköistä vetäjää Helsinkiin perustamaan ja johtamaan pääkaupunkiseudun toimintoja. Nykyinen Proven pääkaupunkiseudun henkilöstö siirtyy heti yksikönvetäjän alaisuuteen. Hävytön ote sekä hyvät puheenlahjat ovat avaimia tehtävässä menestymiseen.

    Prove tarjoaa:

    • Vaarallista ja kovaa menoa sekä tuskantäyteisiä työtunteja!
    • Juuri ja juuri riittävää palkkaa
    • Jos homma onnistuu, luvassa on mainetta ja mammonaa

    Edellytämme, että:

    • Osaat puhua testauksesta aivan kuin tietäisit siitä jotain
    • Et puuhaile joutavia vaan osaat keskittyä olennaiseen
    • Osaat rohkeasti olla eri mieltä etkä pelkää sanoa sitä
    • Pärjäät ainakin yhden erän painissa toimitusjohtajamme Antin kanssa

    Tärkeimmät tehtäväsi ovat:

    • Rekrytä hyvän Auran omaavia uusia Guruja(tm) Proven riveihin
    • Viedä testauksen ilosanomaa uusille asiakkaille

    Jos meininki tuntuu hyvältä ja muut reunaehdot täyttyvät, olet etsimämme henkilö! Työpaikka täytetään välittömästi oikean henkilön löydyttyä. Lisätietoja tehtävästä antaa HR-konsultti Kristiina Aksberg, 050 413 1441 tai kristiina.aksberg@barona.fi

    Hae paikkaa viimeistään 02.01.2012 mennessä klikkaamalla tästä.

    Lisätietoja tehtävästä: kristiina.aksberg@barona.fi , +358504131441

  • Nyt olemme myös Facebookissa

    Ohjelmistotestaus.fi löytyy nyt myös Facebookista. Käy siis tykkäämässä ja tilaa tuoreimmat päivitykset suoraan seinältämme! Samalla saat juttuvinkit kuumimpiin testausaiheisiin uutisiin maailmalta.

  • Auvoisa automaatio

    Nurmikko vihersi ensimmäisen hallayön jälkeen aamukasteesta raikkaana ja aurinko oli jo noussut pilvettömän horisontin ylle. Hörppäilin aamukahvia terassillani ja kuuntelin, kuinka linnut vielä lauloivat lähimetsässä. Rauhallisen lauantaiaamun rikkoi hento, suriseva ääni, joka vahvistui tasaisesti. Tunnistin toki äänen, sillä olinhan joutunut jo useamman kerran kuuntelemaan samaa, naapurin uudesta robottiruohonleikkurista tulevaa ääntä.

    Jotain oli tällä kerralla kuitenkin pielessä. Näin kuinka leikkuri suuntasi suoraan pihan keskellä olevaan omenapuuhun. Törmäys oli välttämätön. Rimpuilustaan huolimatta, tämä puutarhatekniikan taidonnäyte jäi lopulta kiinni puun juurakkoon, eikä päässyt enää omin neuvoin irti. Naapurini oli sopivasti reissun päällä, joten kävin ystävällisesti irrottamassa robotin ja jatkoin aamukahvin parissa. Pohdin syvällisiä. Jopa filosofisia.

    Entäpä jos tuo nurmikko olisi voinut edustaa testisettiä, ja jokainen heinä olisi ollut testitapaus. Automaatti niittää testitapauksia ihan rauhassa ja kaikki näyttää menevän hyvin, kunnes jotain ennalta arvaamatonta tapahtuu. Hyvin usein automaatti ei itse tokene virheestä. Se vaatii aina ihmisen väliintulon. Varsin yleinen harhakäsitys on, että automaatti voi korvata ihmisen. Siksi usein kuvitellaan, että testausautomaatio tarkoittaa myös halpaa testausta.

    Mitä hyötyä automaatiotestauksesta sitten on? Toki viisi työntekijää leikkaisi saman nurmikon huomattavasti nopeammin kuin robotti. Hankkimalla robotin, voidaan kuitenkin vapauttaa nämä viisi henkilöä tekemään jotain tärkeämpää. Sillä aikaa he voivat esimerkiksi parantaa nurmikentän kattavuutta ja kitkeä rikkaruohot.

    Kun ominaisuus on kerran todettu toimivaksi, komennetaan robotti huolehtimaan siitä, että se ei enää mene huomaamatta rikki.

    Oikein käytettynä automaatio on erinomainen apuväline, joka vapauttaa testaajan kädet niihin todella olennaisiin töihin! Anna siis automaatin tarkistaa ja ammattilaisen testata.

  • Voiko tunnetta mitata?

    Antti kirjoitteli viime viikolla tunteeseen luottamisesta testaustoiminnasta. Kommentointi antaisi ymmärtää, että ammattilaisten perstuntuma osuu usein oikeaan, mutta kun ei ole olemassa sitä raakaa dataan, niin mitenkäs sen todistat. Joku metriikka pitäisi olla, jotta tunne muuttuu todeksi!

    Monissa ravintoloissa on ulko-ovella kolme nappia. Asiakasta pyydetään napsauttamaan lähtiessä iloista, neutraalia tai surullista naamaa. Ehkä väritkin ovat mukana. Tästä voidaan päätellä päivän jälkeen, että mitenkäs ravintola tänään onnistui.

    Voisiko tätä lähestymistapaa hyödyntää myös projekteissa? Jokainen projektiin osallistuva napsattaa nettisivulla yhtä kolmesta napista. Jos kaikki näyttää virheältä ja iloiselta, niin projektilla saattaa olla hyvät mahdollisuudet onnistua. Jos keskiarvo lähtee liikkumaan kohti punaista päätä, niin projektipäällikkö herätys!

    Näin se voisi esimerkiksi toimia:

    Kuten kuvasta näkyy, en ole käyttöliittymäsuunnittelija, mutta kyllä tuosta idean pitäisi selvitä. Kun projektipäällikkö näkee tällaisen kuvion, niin syytä olisi mennä juttelemaan punanaaman painajan kanssa. Onko ollut paha päivä vai tietääkö tämä oikeasti jotakin, mitä muut eivät ole vielä huomanneet.

    Ohjelmistojen kehityksessä ja testauksessa perstuntuma osuu usein oikeaan. Heivaa ylimääräiset ja turhat mittarit kuikkaan ja mittaa sitä minkä kaikki tietävät. Mutta mitä aikaisemmin ei ole ikinä kysytty.

  • Hyödyntämättä jätetty tilaisuus

    Olen pitkään ihmetellyt kaikille softaprojekteille yhteistä ja outoa tapaa heittää uudet osaajat projektiin sisään. Tyypillisesti homma hoituu lyömällä kouraan aivot turruttava nippu dokumentaatiota ja odottelemalla työvälineitä tietohallinnolta. Jokainen projekti jättää poikkeuksetta väliin yhden tärkeimmistä tilaisuuksista testata työn alla olevaa tuotetta. Mistä on siis kysymys?

    Syyskuussa 1983 taidekauppias Gianfranco Becchina lähestyi J.Paul Getty -museota Kaliforniassa. Hänellä oli hallussaan kreikkalainen, hämmästyttävän hyvin säilynyt, nuorta miestä esittävä marmoripatsas. Sen iäksi arvioitiin noin 600AD.

    Getty eteni asiassa hyvin varovaisin askelin ja käynnisti patsaasta mittavat tutkimukset. Sitä testattiin puolentoista vuoden ajan erilaisin tieteellisin menetelmin. Kaikki testit osoittivat patsaan todellakin olevan ikivanha ja lopulta kaupat syntyivät karvan verran alle 10.000.000 dollarin hintaan.

    Patsaassa oli kuitenkin jotain hämmentävää. Italialainen taidehistorioitsia Frederico Zeri oli ensimmäinen, joka toi asian esille. Nähdessään patsaan ensikertaa Zeri huomasi vain tuijottavansa patsaan kynsiä. Ne eivät tuntuneet sopivalta.

    Seuraavaksi tuli Evelyn Harrison. Hän oli yksi kreikkalaisen veistostaiteen kärkinimistä ja sattui olemaan vierailulla Los Angelesissa. Museon kuraattori vei Harrisonin katsomaan patsasta museon kunnostamoon. Kuraattori veti kankaan patsaan päältä ja sanoi “Tämä ei aivan vielä ole meidän, mutta muutaman viikon päästä kaupat on tehty”. Harrisonin ensimmäinen vastaus oli vain “Olen pahoillani”.

    Muutamaa kuukautta myöhemmin patsasta tuli katsomaan Thomas Hoving, museonjohtaja New Yorkista. Hovingin tapana on painaa mieleen ensimmäinen sana, joka uusista asioista tulee mieleen. Patsaan nähdessään Hoving muistaa painaneensa mieleen sanan “tuore”.

    Outojen yhteensattumien johdosta Getty päätti käynnistää tutkimukset uudestaan. He kutsuivat koolle suuren joukon kreikkalaisen taiteen asiantuntijoita ja kysyivät ryhmän ensivaikutelmaa patsaasta. Enemmistö oli sitä mieltä, että patsas tuntuu oudolta. Voisiko siis olla mahdollista, että mittavat tieteelliset tutkimukset olivatkin väärässä. Ehkä patsas ei ollutkaan aito?

    Jonkin aikaa vastaus ei ollut selvä. Taidegurujen tunne ja tieteellinen tutkimus olivat napit vastakkain. Patsaasta kiisteltiin konferensseissa. Lopulta patsaan tarina alkoi kuitenkin murentua vähä vähältä Gettyn lakimiesten ponnistelujen tuloksena. Kävi ilmi, että patsas oli peräisin taideväärentämöstä Roomasta, jostain 80-luvun alkupuolelta.

    Patsaan alkuperä ei olisi ikinä selvinnyt, mikäli ammattilaiset eivät olisi osanneet tai uskaltaneet kertoa epämiellyttävästä tunteesta ääneen. Ensivaikutelma patsaasta oli hämmästyttävän voimakas ja kieli selvästi jonkin olevan pielessä. Kukaan ei vain osannut raportoida yksityiskohtaisesti tuntemuksistaan. Taidegurun mielestä patsaasta tuli yksinkertaisesti epämiellyttävä olo.

    Ensivaikutelma oli se tilaisuus, johon Getty uskoi. Jokainen ohjelmistoprojekti kuitenkin lyö täydellisesti laimin juuri ensivaikutelmien tallentamisen. Se on korvaamaton hetki saada uutta tietoa tuotteen hyvyydestä. Hoida homma ja sovi tavasta, jolla uudet ihmiset tutustuvat ensimmäisen kerran tuotteeseen!

  • Mitä kannattaa hankkia, kun lähtee testausostoksille?

    Pysähdyimme perjantaina pohtimaan testaajan työtä höyryävän tuoreen kahvikupin äärellä. Siinä syvällisiä pohtiessa päätimme tarkentaa siihen, mikä on testaajan työn tärkein tulos?

    Vastauksia löytyy toki yhtä paljon, kuin testaajia. Toisen mielestä testauksessa on kysymys laadun parantamisesta, toisen mielestä homman nimi on mittaustulosten tuottamisessa. Kolmas taas väittää, että testaaja rakentaa luottamusta tuotteen laatuun ja neljännen mielestä testaaja taas tuhoaa luottamusta.

    Vastauksia sateli ihan liikaa siinä stormatessa, joten päätimme yksinkertaistaa ongelmaa tässä valinnan paikassa.

    Jos testauksen budjetti asetetaan tuskallisen tiukaksi ja kulutasoa pitäisi vielä entisestään leikata, niin mitä jäisi jäljelle?

    • Testispeksit ja caset? Roskiin
    • Testitulosten mittarointi? Roskiin
    • Testaussuunnittelu? Roskiin
    • Automaatio? Roskiin
    • Tarkistustyöt? Roskiin
    • Testauksenhallintajärjestelmät? Roskiin

    Aika suuri siivu siitä testaajan päivittäisestä työstä päätyi meidän pöydässä roskikseen, mutta yksi juttu siihen jäi. Mikäpä luulette sen olleen?

    Niinpä: Bugithan siihen jäivät. Ne kertovat mitä vikaa softassa on. Ne kertovat miksi se maksava loppuasiakas saattaa valittaa tai olla tyytymätön. Ne kertovat mitkä sudenkuopat kannattaa julkaistessa välttää. Kaikessa yksinkertaisuudessaan ne ovat

    Things that Bug you

    Entäpä jos ensikerralla testausta ostaessasi päättäisitkin hankkia vain sen konkreettisimman tuloksen? Osta ensikerralla vain bugit!

  • Ilmiselvää, mutta vain minulle

    Vierailin syyskuussa teknologiayrittäjyyspäivillä Oulussa. Ensimmäisen päivän lounaan jälkeen siirryimme salin puolelle valmistautumaan henkisesti iltapäivän puheenvuoroihin. Minä istuin innokkaana kuulijana tietysti eturiviin. Taakseni istui nainen jakkupuvussa.

    Kaupunginteatterista seminaarille varatussa salissa oli hämärää ja ilmanvaihtokin toimi aivan kiitettävästi. Mielestäni oli sopivan viileää. Takana istuva nainen ei ilmeisesti ollut samaa mieltä, sillä hän heitti takin jalkojen suojaksi.

    Tuliko kylmä? -minä kysyin

    Nainen nyökkäsi.

    Olipa tyhmä kysymys. Sehän on tietysti ilmiselvää, kun ilmanvaihtokin on niin kovalla. -minä vastasin

    Oikealla puolellani istuva mies ei ollut testausguru, mutta hän onnistui kuitenkin sillä hetkellä saamaan minut kiinni perustavanlaatuisesta ennakkoasenteesta.

    Mistä tiesit, että hänellä on kylmä? Ehkäpä hän halusikin vain peittää kauniit säärensä takilla?

    Vaikka puhelias kaveri olenkin, niin se veti hiljaiseksi. Testausammattilaisen tulisi automaattisesti pyrkiä eroon ennakkoasenteiden ikeestä. Sanoihin kuten “ilmiselvä” pitäisi tarttua projektipalavereista herkästi, sillä niihin pätee yleensä sama sääntö:

    Ilmiselvä sinulle ei välttämättä ole ilmiselvää minulle.

  • Ulkoistaminen kostautuu kympillä

    Ohjelmistotestaus.fi tarinoi jokin aika sitten miten testausta ei pitäisi kutsua laadunvarmentamiseksi, sillä testauksella ei ole valtaa tehdä muutoksia koodiin, tai oikeastaan mitään muitakaan päätöksiä projektin hallintaan liittyen. Asia on tosi, mutta poikkeus vahvistaa säännön.

    Tiedän projektin, jossa kustannussyistä tilaaja vähensi projektinhallinnastaan väkeä. Lopulta laadunvarmistuksen vastuu valui testaukselle.

    Voisi kuvitella että tässä on totaalisen kaaoksen merkit ilmassa, eikä siinä loppujen lopuksi hyvin käynytkään, mutta täysin eri syistä kun voisi kuvitella.

    Projekti lähti käyntiin ja kaikki valmistelut oli tehty viimeisen päälle hyvin. Testaus ja testipäällikkö oli otettu hyvissä ajoin mukaan ja ne oli ostettu kokonaan ulkopuoliselta taholta. Kaikki työ tapahtui asiakkaan tiloissa.

    Ensimmäinen 6 kuukautta meni hyvin ja homma toimi loistavasti, tilaaja oli tyytyväinen. Kuitenkin sattui niin, että asiakkaan mielestä kyseisen projektin tärkeyttä piti tarkistella. Niin johtoa siirrettiin muihin tehtäviin. Projektin tuote oli kuitenkin pakollinen, joten sitä ei keskeytetty.

    Kului toiset puoli vuotta, ja asiakkaan nimittämä projektivetäjä jäi pois. Testauspäällikkö veti projektipäällikön hatun päähänsä. Käytännössä se tarkoitti sitä, että testauspäällikkö vastasi uusista ominaisuuksista, parannusehdotuksista, sekä niiden hyväksynnästä. Tässä vaiheessa tilaaja myös aloitti suunnittelut kehityksen siirrosta Aasiaan. Kuluja oli vähennettävä.

    Kun projektia oli kulunut noin vuosi, devaus siirrettiin kokonaan alihankkijalle. Aasiasta ryhdyttiin kouluttamaan tiimiä testaamaan ja koodaamaan työn alla ollutta tuotetta. Suomessa testaajia ja devaajia tippui vähän kerrallaan pois. Lopuksi jäljellä oli kolme kaveria: Testaus-/projektipäällikkö, testaaja ja devaaja.

    Tehdessä oppii, näin sanotaan, eikä kyseinen tiimi tehnyt ollenkaan huonoa jälkeä, tilaaja oli edelleen tyytyväinen. Laatu pysyi kasassa suhteellisen pienillä kuluilla.

    Kun projekti oli ollut käynnissä kaksi vuotta ja toimituksiakin tehty ihan kiitettävästi, tilaaja päätti lopettaa projektin kehityksen Suomessa kokonaan. Siitä alkoivat ongelmat: Vikoja tehtiin enemmän kuin ehdittiin korjata, testaus oli samojen testitapausten toistamista viikosta toiseen ja loppuasiakas reklamoi. Projektin johto oli täysin kahvilla. Yksi toimitus saatiin tehtyä, joka sekin toimi huonosti.

    Lopulta tilaaja joutui ottamaan ohjat jälleen omiin käsiinsä. Valitettavasti siinä vaiheessa tuote oli muuttunut jo niin paljon, että työtunteja kului 600 pelkästään tuotteen uudelleenopetteluun. Hukkareissu kesken projektin maksoi puoli vuotta rahaakin arvokkaampaa aikaa! Lisäksi vaiva tiimin uudelleen kasaamisesta oli valtava ja kustannukset tuplaantuivat aivan vahingossa.

    Halpa työvoima ei ole pahasta, mutta kannattaa tarkkaan miettiä miten siirto tehdään, mitä siirretään ja ennenkaikkea milloin? Älä päästää koko projektia lipsumaan käsistä, sillä ongelmien ratkominen käy mahdottomaksi.

    Vieraileva kirjoittaja: Jarkko Tauriainen ottaa testauksen vakavasti. Jopa niin vakavasti, että sana ‘vakava’ kuulostaa vähättelyltä. Testausalalla nopeasti kehittynyt Jarkko, on itse opiskelemalla sisäistänyt testauksen perimmäisen kysymyksen ja omaksuu nopeasti uusien ympäristöjen vaatimukset. Parhaan hyödyn Jarkosta saa irti kun ei höpöttele turhan dokumentoinnin ja prosessien maailmassa, vaan tähtää tuloksiin! Mitä vaativampi projekti, sen parempi.