FiSTB Testing Assemblyn satoa


2014-09-30, 10:16 Kirjoittanut Kimmo Hakala

Aiemmin tänä vuonna käsittelin blogissani testauksen trendejä ISTQB:n teettämän tutkimuksen tuloksiin perustuen.  Jatkan testauksen trendien parissa edelleen ja tavoitteena tässä blogikirjoituksessa on hahmotella ideaa ketterän kehityksen laatumallista. Mitä elementtejä siihen pitäisi ainakin kuulua ja mikä on niiden painoarvo, jotta saataisiin mahdollisimman hyvät perusedellytykset laadukkaalle lopputulokselle? 

FiSTB Testing Assembly järjestettiin 25.9. Sokos Hotelli Presidentissä Helsingissä ja tapahtuma keräsi runsaasi ohjelmistoalan ja ennen kaikkea testauksen ammattilaisia. Käytän ideoinnin apuna yhtä pääpuheenvuoroista, jossa James O. Coplien muun muassa kertoi erilaisten menetelmien tehokkuudesta vikojen poistamisessa. Tehokkain tapa esityksen mukaan on ylivoimaisesti muodollinen katselmointi 93% ja toisena on koodin staattinen analyysi 55%. Seuraavaksi tehokkaimmat tavat ovat systeemitestaus 36% ja toiminnallinen testaus 35%. Yksikkö- ja komponenttitestauksen tehokkuus on 32%. Vähiten tehokkaimpia esityksen perusteella ovat hyväksymistestaus 17% ja regressiotestaus 14%.  

Tehokkuus vikojen poistamisessa

Coplienin esityksessä kritisoitiin erityisesti yksikkötestausta ja automatisointia, koska sillä ei voida testata asioita, joilla on liiketoiminnallista arvoa ja toisaalta siinä ei välttämättä tiedetä mitä testataan, tai testataan sellaista mitä ei tarvitse testata. Yksikkötestauksessa on myös yksi perustavaa laatua oleva ongelma, koska siinä koodin tekijä itse laatii testit, eikä testaus ole näin ollen riippumatonta. Yksikkötestaus ei siis välttämättä kuulu nykyaikaiseen ketterään kehitykseen, tai se ei ainakaan ole sen keskeisimpiä rakennuspalikoita. Automatisoituihin testeihin liittyy yksi keskeinen testauksen haaste: kun samoja testejä ajetaan tai käytetään samoja menetelmiä yhä uudestaan ja uudestaan, niin voidaan löytää ainoastaan ns. helppoja vikoja ja todelliset ongelmat voivat jäädä piiloon.

Testaus on välttämätöntä vikojen löytämiseen ja niiden poistamiseen mutta se ei tuota lisäarvoa (ominaisuuksia) toimitettavaan tuotteeseen (ohjelmistoon), vaan sen tekee ohjelmistokehitys. Näin ollen testauksessa pitää keskittyä vain sellaisiin menetelmiin, jotka ovat tehokkaita vian löytämisessä. Automatisointi ei itsessään ratkaise mitään ongelmia ja sitä kannattaakin hyödyntää vain mekaanisissa, isoja toistomääriä vaativissa testeissä, joiden toteuttaminen manuaalisesti on aikaa vievää tai jopa mahdotonta. Tätä ennen on kuitenkin syytä rakentaa toimiva tutkiva testaus ja huolehtia muista laadunvarmistuksen toimenpiteistä. Ketterän projektin onnistumisen kannalta pehmeät arvot, kuten kommunikointi ja yhteistyö ovat keskeisessä roolissa. Näin ollen muodostetaan ketterän kehityksen laatumalli, joka muodostuu neljästä peruselementistä seuraavalla jaolla:

 Laatumalli

1.      Hyvä suunnittelu ja käyttäjäkeskeisyys, painoarvo 40%

Tässä aihealueessa korostaisin erityisesti sitä, että ohjelmiston suunnittelussa otetaan huomioon erilaiset käyttäjät (ja laitteet) väheksymättä erinomaista käytettävyyttä ja käyttökokemusta.  

2.      Kommunikointi ja yhteistyö, painoarvo 30%

Tiukasta kehityssyklistä johtuen yksi ketterän ohjelmistokehityksen perustoista on luottamus ja toimiva kommunikointi eri henkilöiden välillä.  Luottamus saavutetaan toimimalla yhteistyössä ja tämä edesauttaa tiedon jakamista.

3.      (Muodolliset) katselmoinnit ja staattinen analyysi, painoarvo 20%

Otsikko voisi olla yhtä hyvin ennakointi ja ennaltaehkäisy, koska katselmointien avulla pyritään nimenomaan ennaltaehkäisemään virheiden syntymistä mahdollisimman aikaisessa vaiheessa. Siksi onkin tärkeää, että katselmointeja tehdään ketterän kehityksen eri vaiheissa, ne aloitetaan varhain ja ne kuuluvat kaikille projektin jäsenille. Staattisen analyysin tavoitteena on löytää todellisia tai mahdollisia vikoja ohjelmakoodista ja järjestelmäarkkitehtuurista ja pyrkiä parantamaan niiden ylläpidettävyyttä. Staattisessa analyysissä käytetään yleensä apuna työkalua. Staattisen analyysin menetelmiä ovat mm. kontrollivuoanalyysi sekä tietovirta-analyysi.

4.      Tutkiva ja kokemusperäinen testaus, painoarvo 10%

Tutkivan testauksen perusta on testaajan korkean ammattitaito ja kokemus. Siinä testien suunnittelu ja niiden toteutus tapahtuvat samaan aikaan perustuen valmisteltuun testausohjeeseen. Testausohje tarjoaa testattavat tilanteet, jotka katetaan aikarajoitetun testaussession aikana. Tutkivan testauksen aikana viimeisimpien testien tulokset ohjaavat seuraavaa testiä.

Muodostamani malli on synteesi, jonka pohjana käytin Coplienin esityksessä joitakin esiin tulleita ajatuksia. Mallin painoarvot ovat viitteellisiä ja painotus voi vaihtua kehitettävän ohjelmiston tyypin ja riskitason mukaan. 

 

Lähteitä:

Beyond Agile Testing to Lean Development, James O.Coplien, Gertrud & Cope

Jatkotason sertifikaattisisältö - Testausasiantuntija (AL TA) 2012,

ISTQB® International Software Testing Qualifications Board                          



comments powered by Disqus