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.
Ostin pari viikkoa sitten neljälläkymmenellä eurolla (!!) minihiiren tuollaisella jojo-johdolla. Merkki on Targus ja hiiri on ihan paska. Noin niinkuin jos jollekin muulle tulee tarve vastaavanlaiselle hiirelle, niin ei ainakaan Targusta.
SDP on ollut vallassa aina kuin minä vaan muistan. Vallassa ololla tarkoitan sitä, että on suurin tai melkein suurin eduskuntapuolue. Silloin luulisi olevan painava sana sanottavana. [tilasto] Ja varmaan ennen sitäkin. SDP on siis ollut muutamaa poikkeusta lukuunottamatta aina suurin eduskuntapuolue, tosin juuri tällä hetkellä Keskusta on vielä suurempi.
Silti tuloerot kasvavat, kansalaisista huolehditaan yhä huonommin – samaan aikaan valtion verotulot ovat suurempia kuin koskaan. Mihin nämä SDP:n ajamat arvot sitten oikein menevät? Miksei kaikille voida taata hyvää terveydenhuoltoa? Miksi tuloerot kasvavat? Miksei SDP ole tehnyt näille asioille mitään, vaikka on voinut hyvin voimakkaasti vaikuttaa koko ajan Suomen suuntaan?
Minusta suomalaisten olisi syytä tulevissa vaaleissa ottaa järki käteen ja katsoa mihin suuntaan Suomea voitaisiin saada menemään jos SDP jätettäisiin suosiolla keskisuureksi puolueeksi. Niin ja että unohtaisi äänestää Tanja Saarelaa (ex. kampela).
Kaikki ovat varmaan nähneet elokuvan Minority Report, jossa Tom Cruise käyttelee vähintäänkin futuristista käyttöliittymää käsillään. Microsoft esittelee demoa, joka on samankaltainen. Aika hieno.
Ekonomit arvostelevat Heinäluoman esitystä ja pitävät sitä temppupolitiikkana. SEFE tietäisi ainakin 20 paikkaa mihin rahaa pitäisi laittaa.. Mutta entä mistä nämä rahat tulisivat tai mistä ne olisivat pois? Siitä ei yleensä viitsitä puhua.
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).
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.
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.
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.
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.
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.
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.
Täytyy myöntää huonouteni. Olen tällä hetkellä ensimmäistä kertaa elämässäni hotellissa. Tamperevierailuni ajan minut majoittaa upouusi Scandic. Hotellin palveluihin kuuluu mm. avoin WLAN, jota juuri käytän. Kun kräkkerit nyt salakuuntelevat avointa yhteyttäni ja varastivat blogini salasanan, niin ei se mitään, onpahan enemmän ylläpitäjiä..
Ostin vähän aikaa sitten loistavan tanskalaisen bändin Carpark Northin levyn All Things To All People. CDON ei ilmoittanut sen kopiosuojausstatuksesta mitään, mutta koska muissa levyissä oli merkitty kopiosuojaus erikseen, oletin että tässä sellaista ei ole.
Oletin väärin. Firmana Emi Music Denmark ja CopyControlled. Selvä. Enää tähän taloon ei tule yhtäkään ison levylafkan levyä. Se on nyt saletti. Suorastaan vituttaa, kun huolellisen tutkimisen jälkeenkin rahani sujahtivat yritykselle, joka tunkee kopiosuojauksia meidän maksavien asiakkaiden niskoille. Mutta ei enää. Ei. Koskaan.
Onneksi on Beatport, Audiojelly ja Finrg.
Ikäväähän asia on sen vuoksi, että ostin levyn tukeakseni bändiä, josta tykkäsin. Mutta jos bändi antaa levy-yhtiönsä huijata asiakkaitaan, niin ei tarvitse odotella minun senttejäni.
PS. Levyn rippaaminen ei tuottanut minkäänlaisia vaikeuksia. Ilmeisesti juuri tein pahimman luokan rikoksen.
Voiko mikään olla epäilyttävämpi tai epätarkempi termi kuin eräs bloggaaja? Eikö sama olisi sanoa joku jossain? Digitodaytä se ei tunnu haittaavan.