Jasmo tietää paremmin

Tänään on opintorahan korotusta vaativia mielenosoituksia ympäri Suomea. Itse en pääse paikalle, mutta olen sitten mukana hengessä edes alla olevan videon verran. Videolle kerätty LTY:n opiskelijoiden kannattelemat kilvet.

Tajusin juuri, että valitukseni WEB-teknologioista ja Juha Puustjärvestä on aiheetonta. Opiskelen yliopistossa. Luennoilla ei ole pakko käydä. En siis saa valittaa siitä, että mies puhuu ympäripyöreitä, mutta yrittää silti opettaa eksaktia tekniikkaa. En saa valittaa siitä, että luennoilla esitetyt esimerkit ovat niin puutteellisia ja syntaktisesti väärin, että niistä yksikään ei varmasti todellisuudessa toimisi. En saa valittaa siitä, että yksinkertaisia asioita opetetaan ihan liian vaikeasti. En saa valittaa siitä, että harjoituksia pitää joku venäläinen, joka puhuu huonoa suomea kohti seinää, eikä puheesta saa mitään selvää.

En saa, koska luennoille tai harjoituksiin ei ole pakko mennä! Tästä lähtien en blogissa enää valita ainakaan tämän kurssin osalta mitään. Koska eihän niillä luennoilla ole pakko käydä.

En epäile etteikö opettaminen olisi vaikeaa. Olen paraikaa Juha Puustjärven luonnoilla Web-teknologiat. En oikein tiedä mihin täällä ollaan menossa. Kirjoitan tätä Nokian E70:llä WLANin yli.

Nyt käytiin juuri läpi predikaattilogiikkaa. Ok, se on järkevää, sehän on tietokoneen tapa ‘päätellä’. Aikaisemmin on puhuttu xml skeemoista, rdf:stä, rdf skeemoista ja owl:stä. Ilman yhtäkään esimerkkiä. Ei ainuttakaan. Itseäni vähän kiinnostaisi tietää mitä nuo hienot kirjainlyhennelmät on..

Fukseista tuli fukseja ja maailma jatkoi pyörimistään. Ts. ei mitään uutta auringon alla. Kahden viikon fuksiviikot on nyt vietetty ja nyt voi palata normaaliin aikatauluun. Ei henkilökohtaisesti tuo teekkarimeininki enää ihan hirveästi sytytä – jos on koskaan sytyttänytkään – mutta on tullut oltua kaikenlaisessa techmun vuoksi mukana.

Mutta ei siinä, sen kunniaksi voi istua perjantain ja lauantain intensiiveillä.

Usein teknillisessä maailmassa katsotaan humanisteja vähän kulmien alta. Joskus huumorilla, mutta usein myös tosissaan. Ero maailmoissa iski jälleen vasten kasvoja, kun FT Juha Puustjärvi luennoi kurssia WEB-teknologiat.

Ensimmäiset kolme tuntia menikin XML:n opetteluun. Kolme tuntia. Teknillisessä yliopistossa. Aihetta lähdettiin käsittelemään sellaisista abstraktiotasoista, että vaikka XML on melko tuttu jo aiemmista yhteyksistä, niin en ensimmäisen tunnin aikana tajunnut, että tässä nyt puhutaan XML:stä. Hienoja sanoja kuten ontologia ja taksonomia vilkkui kyllä säännöllisesti. No, sitähän tiede on. Hienolta kuulostavien englanninkielisten sanojen viljelyä ja niitä ymmärtämättömien alistamista.

Lopulta kahden ja puolen tunnin jälkeen pääsimme XML-markuppiin. Ideana tosiaan oli vain saada ihmiset ymmärtämään XML-merkkaus ja sen lukeminen. Se ei kuitenkaan estänyt lähtemästä sellaiselta abstraktitasolta, että sillä olisi voinut kuvata ihan mitä tahansa. Kolme tuntia.

Se kai humanistista ja teknistä maailmaa erottaakin. Toista kiinnostaa kuvailla mitä jollakin asialla voi tehdä, toisia kiinnostaa vain se, mitä sillä voi tehdä. Tämä kai erottaa yleisesti yliopistoissa ja teknillisissä yliopistoissa tapahtuvaa matematiikan opetustakin.

En epäile etteikö luennointi olisi vaikeaa, mutta tänään ainakin Puustjärvi epäonnistui kyllä.

Huomenna se sitten on. Tuomionpäivä. No ei sentään, koulu alkaa taas. Tänään oli vielä vapaapäivä. Huomenna kello kahdeksan pitäisi sitten olla koululla kattelemassa ja kuuntelemassa.

Kevään varaan en ole paljon laskemassa, joten pitää näin syksyllä yrittää. Aika paljon olisikin tekemistä, toivottavasti jaksan tehdä edes 95%.

Idoli sen sijaan ilmoitti lähtevänsä Australiaan. Selvä.

Techmu otti uudet fuksit (teknisestihän he eivät ole vielä fukseja) vastaan perinteisin tavoin Club Liikenteenjakajalla. Paikalle eksyi ihan mukavasti ihmisiä, muitakin kuin Techmulaisia. Hieman ennen varsinaista fuksien virtaa kuvattu video ihmisistä ja installaatiosta (kuvausväline Nokia E70):

Kandityönhän piti olla valmis jo vaikka kuinka kauan sitten. No, lopulta sen on valmis nyt, siis siinä määrin valmis, että se on arvosteltu, siitä on toimitettu opintotoimistoon tarvittavat tositteet, se on lisätty LutPub-tietokantaan (näkyy lähipäivinä), siitä on viety lappuja kirjastoon ja niin edelleen.

Eli se on kansissa. Paitsi, että kandidaatintyötä ei kansiteta. Tuoretta (tai teknisesti vasta tulevaa) kandia sen sijaan saatetaan kansittaa.

Nyt TTY:llä järjestetyt testauspäivät ovat siis ohi. Toinen päivä koostui seminaareista, eikä keskusteleva luonne ehkä korostunut niin paljoa. Kuitenkin, kaikki aiheet olivat melko kiinnostavia, mutta vain osasta (omaan mielenkiintooni osuvista) jaksoin tehdä muistiinpanoja (kännykkään).

Testiautomaation ongelmat ja niiden välttäminen

Päivä alkoi Tuula Jokiharjun ja Tuula Pääkkösen (Nokia) pitämällä seminaarin testiautomaation sudenkuopista ja niiden välttämisestä. En tehnyt muistiinpanoja. He kuvasivat aika perusasioita testausautomaation epäonnistumisesta ja onnistumisesta, mutta paljon ihan hyvää asiaa. He puhuivat siitä, kuinka kiistatta automatisoitu testaus tuo etuja silloin, kun se tehdään kunnolla ja suunnitellusti. Jos testitapauksista 30-50% voidaan automatisoida, ollaan automatisoinnissa onnistuttu. Ketterät menetelmät ja yksikkötestaus hyötyvät automatisoidusta testauksesta.

Ketterä testaus ja ohjelmistojen laatu

Ketterillä menetelmillä kehitetyt ohjelmistot saavat laatunsa muulla tavalla kuin perinteisellä tiukalla testaamisella. Listaan nyt muutamia näistä mekanismeista: Pyritään toimittamaan asiakkaalle nopeasti jonkinlainen (toimiva, mutta toiminnoiltaan vajaa) tuote ja toimitetaan uusia versioita usein. Tämä helpottaa kehityksen seuraamista ja asiakkaan on helppo nähdä mahdollisia heikkouksia. Myös julkaisun riskin määrä pienenee. Pyritään kommunikoimaan pääasiassa kasvotusten, ei siis esimerkiksi sähöpostin tai puhelimen välityksellä. Työskennellään yhdessä asiakkaan, kehittäjien, testaajien ja yrityksen bisnesjohdon kanssa. Pyritään välttämään featureviidakko, eli karsitaan turhat ominaisuudet minimiin.

Ketteristä menetelmistä ei testauksen perinteistä V-mallia löydy, eikä suunnitelmavetoinen testaus yksinkertaisesti onnistu. Testaus onkin siis erottamaton osa ketterästä ohjelmistokehityksestä. Yleensä yrityksessä, joka käyttää ketteriä menetelmiä, ei ole testaajia tai koodaajia, vaan kaikki tekevät kaikkea, mitä osaavat. Laatua parantavat myös pariohjelmointi (Nokialla ilmeisesti (Nokia käyttää Scrumia) toinen parista ohjelmoi ja toinen luo testejä), jatkuva integrointi, testaajien ja kehittäjien yhdessä työskenteleminen ja testivetoisuus. Huomattavaa on, että perinteisen softatestauksen lisäksi myös vaatimuksia voidaan testata, tai ainakin katselmoida, jolloin suurimmat ötökät saattavat tippua tai ainakin kaikki ymmärtävät, mitä haetaan.

Nokia ja Scrum

Yllätyksekseni sain kuulla, että Nokialla (ainakin joissain projekteissa) käytetään Scrumia + Extreme Programmingia. Harmikseni sain tiedon vasta nyt, kandidaatintyöni on mennyt juuri vähän aikaa sitten siihen vaiheeseen, ettei sitä voi enää muuttaa. Kandidaatintyössäni päädyin siihen tulokseen, että Scrum + Extreme Programming on hyvä ja tehokas tapa toteuttaa softakehitystä, tämä olisi ollut todella hyvä todiste siitä. Täytyyhän sen olla hyvä juttu jos Nokia sitä tekee!!

Olen Tampereella siis testauspäivien vuoksi. Tein päivän aikana muistiinpanoja ainoastaan kännykkääni ja ajatuksenani oli kirjoittaa myöhemmin illalla puhtaaksi ne muistiinpanot. No, ajattelin, että sama kai ne on kirjoittaa tähän blogiinkin. Jos joku haluaa vaikka lukea. Testauspäivät jatkuvat TTY:llä vielä huomennakin.

Ohjelmistojen testauksesta ja vähän muustakin meille oli puhumassa tällä hetkellä F-Securella työskentelevä Maaret Pyhäjärvi ja entinen Nokialainen, nykyinen Tietoenatorin työntekijä, Erkki Pöyhönen.

Testaus

Aluksi Pyhäjärvi puhui ketterästä testaamisesta. Siinä sovelletaan samoja asioita kuin ketterässä sovelluskehityksessä, mutta ketterä testaaminen ei välttämättä tarvitse ketterää sovelluskehittämistä ympärilleen toimiakseen. F-Secure on nyt toiminut hieman alle vuoden ketterässä ohjelmistokehityksessä, jota edelsi 18 kuukauden pilotointi. Myös testaus on siis ketteröitetty. Mitä tämä hieno, ehkä jopa hypetetty, termi siis tarkoittaa käytännössä? Monia asioita. Kaikki viestintä toimii vaivattomammin.

Perinteisesti on tiimejä, jotka kehittävät softaa ja kun on valmista, niin työ viedään toiseen kerrokseen tai taloon, jossa testaajat iskevät sovellukseen kiinni. Ketterässä testauksessa on muutamia avainkohtia, jotka eroattavat sen perinteisestä toiminnasta. Ensiksikin, ohjelmistokehittäjille viedään paljon testauspaineita. Se vastuunsiirto ei ole nopea, vaan se yksinkertaisesti pikkuhiljaa juontuu siitä keskustelusta, jota testaajat ja kehittäjät käyvät (vähintään kerran pari viikossa). Testaajat kertovat mitä aikovat testata, millaisia tyyppivikoja sen kaltaisissa jutuissa on ollut jne. Kehittäjä voi suoraan tiedostaa potentiaaliset ongelmat ja kirjoittaa koodin periaatteessa testiä vastaan. Ketterien menetelmien kirjallisuudessa kehoitetaankin luomaan testitapaukset ja varsinaiset testit (konkreettiset testit) ennen kuin tehdään yhtään koodausta. Se on ehkä mahdottumuus monissa tapauksissa, tai ainakin muutokseen menee aikaa. Tähän on F-Securella päädytty.

Toisekseen ketterä testaus eroaa perinteisestä siinä, että testaus työntää lonkeroitaan kehittäviin tiimeihin. Joko tiimeissä on ihan joku testaaja-nimikkeellä toimiva henkilö tai sitten siellä on puoliagentti, joka käy ohjelmistokehityspalavereiden lisäksi myös testaajien keskinäisissä palavereissa. Näin kulkee informaatio paremmin siitä, mitä aiottuja muutoksia mahdollisesti tullaan implementoimaan ja jos jotain aiotaan muuttaa radikaalisti. En tarkoita tietenkään sitä, että jos näitä agentteja ei olisi, niin testaajat saisivat aina vaan mustan laatikon eteensä, mutta edellä mainitulla tavalla viestintää parannetaan. Viestintä on hyvin oleelinen osa ketteriä menetelmiä.

Tutkiva testaus (exploration). Tutkiva testaus ei varsinaisesti ole ketterän testauksen ominaispiirre, mutta siinä on monia ketterien menetelmien piirteitä, kuten formaaliuden puute (informaalius? :D). Tarkkojen testirajausten tekoa vältetään ja tutkitaan asioita testaajien kokemuksen ja paranoian ajamana. F-Secure luo kahdenlaisia testiä tukevia tietoja, käyttötapauksia (hyvin tarkkoja ja formaaleita) ja testiosa-alueita. Testin osa-alue voi olla esimerkiksi asennus. Tutkiva testaus mahdollistaa paremmin keskittymisen olennaiseen. Jos regressiotestausta saadaan vielä automatisoitua, kuten ilmeisesti F-Securella on tehty hyvin pitkälle, testaus on myös tehokasta. Tutkiva testaus ei ole mikään uusi hömpötys, vaan sillä on historiaa ainakin yli 20 vuotta.

Maaret antoi myös hyvän esimerkin käyttöliittymätestauksesta. Testaajan on osattava pysähtyä erilaisiin kysymysbokseihin ja valintatilanteisiin ja koitettava hahmottaa se tilanne, minkä hän olettaa seuraavan siitä, kun painetaan ok-näppäintä. Tätä demonstroidakseen hän kävi läpi Microsoft Powerpointista muutamia, jos ei bugeja niin epäloogisuuksia, jotka hyvin havainnollistivat sitä, mistä hän puhui.

Testauksen automatisointi

Ajatelkaapa kuinka kivaa olisi, kun kenenkään ei tarvitsisi testata ohjelmistoja. Koodarit koodaisivat ja tarkistusohjelma tarkistaisi ohjelmistot kaikkien mahdollisten virheiden varalta. Ei enää bugeja tuotteissa ja kuinka nopeaa se olisikaan! Pahaksi onneksi se on kuvitelmaa, fiktiota. Automatisoitua regressiotestausta voidaan nykyään tehdä kohtuullisen hyvin ja luotettavasti. Erilaisia API-rajapintoja voidaan testata automaattisesti. Mutta on paljon asioita, joita ei voida testata automaattisesti tai siinä ei ole järkeä. Automatisoitujen testausohjelmien toimittajat ovat kyllä eri mieltä. No, huomenna tästä aiheesta jatkaa ainakin pari luennoijaa, joten tästä varmaan lisää vielä huomenna.

Kylmiä faktoja ovat kuitenkin seuraavat: Kun testausohjelman käyttöönotosta on kulunut 3 vuotta, se on edelleen käytössä ainoastaan muutamassa prosentissa tapauksia (lähde: jokin tutkimuskeskus, kuten Gartner tai IDC). Toinen tärkeä fakta on, että kolmessa vuodessa testaustyökalujen kokonaishinnasta 75% koostuu ylläpidosta.

F-Securen ketterät menetelmät

Olin jokseenkin yllättynyt, kun Maaret kertoi, että F-Secure käyttää Scrum -menetelmää ketterässä kehityksessään. Se on tunnettu menetelmä ja sen ei olisi pitänyt olla yllätys, mutta mielestäni menetelmä on sen verran rohkea, että en olisi uskonut.. Mutta niin vain on. Maaret itsekin oli ollut itse Scrum-guru Ken Schwaberin opissa, joka oli kuulemma kehottanut hänen pomoaan antamaan hänelle kenkää. No kenkää ei tullut, vaan Certified Scrum Master -plakaati.

F-Secure tosiaan pyörii kuten oppikirjoissa sanotaan. Päivittäin pidetään kehittäjäpalaveri (testauspuolella ilmeisesti 2 kertaa viikossa, näin käsitin), jossa kerrotaan mitä kukin on tehnyt, tekee seuraavaksi ja jos on ongelmia tai mielipiteitä. Projektipäälliköt ovat muuttuneet enemmän projektisihteereiksi – henkilöiksi jotka vastaavat tiimin tarpeista, mutta eivät niinkään siitä, mitä tehdään. Suunnittelijoilla ja ohjelmoijilla (joka on lopulta todennäköisesti sama asia) on enemmän valtaa ja vapautta kuin koskaan, mutta samalla myös enemmän vastuuta (samalla palkalla) kuin koskaan. Kysyinkin Maaretilta, ovatko työntekijät tyytyväisiä. Hän vastasi että suurin osa, varsinkin kehittäjistä, on erittäin tyytyväinen uuteen menetelmään, joka antaa heidän toteuttaa itseään paremmin. Toisaalta kaikille ketterät menetelmät eivät vaan toimi, esimerkiksi voimakkaan kommunikoinnin korostamisen vuoksi, mutta heitä on selkeä vähemmistö. Testaus on F-Securella noussut arvostetuksi asiaksi yrityksen keskuudessa (se ei todella ole itsestään selvää) ja osittain sen takia testaajatkin ovat pääasiallisesti tyytyväisiä ketterään menetelmään, vaikka muissa yrityksissä juuri testaajat voivat kaikkein huonoimmin. F-Secure on parantanut tulostaan ketterien menetelmien käyttöönoton jälkeen, mutta menetelmät ovat olleet vasta niin vähän aikaa käytössä, että selkeiden implikaatioiden muodostaminen on ehkä turhan aikaista.

F-Securella oli ketterien menetelmien pilotointivaiheessa ja sen jälkeenkin ongelmia, jotka johtuivat uuden menetelmän käyttöönotosta ja ilmeisesti myös ihmisistä. Suuri osa ongelmista on kuitenkin saatu ratkaistua, mutta niitä kuitenkin edelleenkin on. Kuitenkin vaellus kohti ketteriä menetelmiä on vääjäämätöntä. Ketterät menetelmät eivät ole vallankumous. Ne ovat ohjelmistokehityksen evoluution tulos, kehitystä vanhoihin työtapoihin. Yrityksissä on huomattu, että nykyisillä työkaluilla on mahdollista saada ohjelmistoversio ulos esimerkiksi joka 2. kuukausi. Sitä myös halutaan, koska siten ohjelmistokehitykseen panostetut rahat saadaan nopeammin takaisin. Paluuta vanhaan ei monella tapaa ole. Täytyy kuitenkin muistaa, että ketterät menetelmät perustuvat vanhoihin periaatteisiin, joita on vain hiottu. Mitään pelättävää ei siis pitäisi kenelläkään olla.

Switch to our mobile site