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.