Tutkiva katselmointi (Exploratory review)

Käsittelen tässä vähän katselmointia. Tämä teksti on yritystämme varten tehty yhteenveto katselmoinnin tärkeydestä. teksti on johdettu osittain Rex Blackin "Advanced Software Testing vol.2 - Guide to the ISTQB Advanced Certification as an Advanced test Manager" -kirjasta.

Katselmointi tulee suorittaa projektin jokaisen vaiheen jälkeen ja ennen seuraavan vaiheen alkua. Mulkoilua voi suorittaa vaiheen sisällä, mutta virallinen katselmointi tulee suorittaa aina vaiheen päättyessä. Esim. koodikatselmointi tulee suorittaa, ennen kuin tuote luovutetaan testiin, jotta havaitut puutteet voidaan korjata, eikä testattavaan tuotteeseen pääse ylimääräisiä virheitä.

Miksi katselmoiminen on tärkeää? Oletetaan että luodaan sovellus, jossa on 1000 bugia. Ao. taulukon mukaan, jos käytetään epävirallisinta katselmointia (mutta kaikki tarvittava katselmoidaan), ennen testaamisen aloittamista on estetty 834 bugin pääsy testattavaan tuotteeseen. Testauksessa täytyy siis löytää ainoastaa 166 bugia. Jos taas katselmointi olisi suoritettu raskaimmalla mahdollisella tasolla (katselmoinnit on suoritettu tarkasti ja ammattitaitoisella ryhmällä), ennen testaamisen aloittamista on estetty 996 (!!!) bugin pääsy järjestelmään, jolloin testauksessa täytyy löytää ainoastaan 4 bugia!

Jos edes osa dokumenteista katselmoidaat/mulkoillaan voidaan estää suuri määrä bugeja testaukseen tai edes syntymään.

Katselmoinnin tehokkuus	Vähintään (mulkoilu)	Keskimäärin	Enintään (virallinen)
Vaatimusmäärittelyt	20%	30%	50%
Karkeat suunnitelmat	30%	40%	50%
Tuotantokelpoiset suunnitelmat	30%	45%	65%
Yksityiskohtaiset suunnitelmat	35%	55%	75%
Koodikatselmointi	35%	60%	85%

Taulukon luvut tarkoittavat prosenttiosuutta dokumentin virheistä, jotka katselmointi havaitsee.

Taulukko on poimittu Rex Blackin "Advanced Software Testing vol.2 - Guide to the ISTQB Advanced Certification as an Advanced test Manager"

Tämän mukaan siis katselmointia tulisi suorittaa kaikissa vaiheissa jollakin tasolla. Jos katselmointi suoritetaan waterfall mallissa, niin vaiheistus voisi jopa toimia nätisti. Ketterissä menetelmissä katselmointi onkin hieman hankalampi suorittaa. Jos joka kerta kun määrittely tai suunnitelma muuttuu, ne tulisi katselmoida. Eikös ketterissä menetelmissä katselmointi veisi siis järkyttävän paljon aikaa? Kuinka siis katselmointi toteutetaan ketterissä projekteissa?

Jos luodaan määrittelydokumentti, se täytyy versioida. Tämä versio katselmoidaan. Siitä löytyneet viat korjataan ja se annetaan eteenpäin. Tämän jälkeen muutokset määrittelyihin johdetaan versioinnin kautta, eli jokainen määrittelyn muutos merkataan muutoksena aiemmin päätettyyn. Tämä siis katselmoidaan ainoastaan muutosten osalta. Sanotaan, että ainoastaan yksi määrittely muuttu, jolloin tämä ainoastaan katselmoidaan.

Kun määrittelyä muutetaan, se vaikuttaa suoraan seuraavan vaiheen dokumentteihin, eli teknisiin määrittelyihin ja arkkitehtuuriin. Muutosten vaikutus tulee analysoida ja arvioida lisätyön määrä. Jos perusajatus muuttuu täysin määrittelyä muutettaessa, onko järkevämpi uudistaa koko arkkitehtuuri ja tekninen määrittely eikä vain tehdä yksittäisiä muutoksia? Voiko alkuperäisiä dokumentteja käyttää jotenkin hyväksi? Nämä täytyy varmistaa katselmoinnin muodossa. Aina täytyy muistaa, että kaikki voi vaikuttaa kaikkeen. Tulee siis sulkea pois ne alueet, jotka pysyvät muutumattomina työmäärän vähentämiseksi.

Tämä jatkuu aina hierarkisesti aina käyttöohjeeseen asti, joten muutokset täytyy siis katselmoida niiltä osin, mitenkä ne vaikuttavat dokumentin muihin osiin sekä hierarkiassa alempana oleviin dokumentteihin.

Miten voidaan varmistaa, että yhden määrittelyn/suunnittelukohdan/koodirivin muutos ei vaikuta muihin määrityksiin? Pitääkö katselmointia siis laajentaa? Entäs bisnesmäärittelyn muutoksen vaikutus NFR:iin? Koodimuutoksen vaikutus testausautomaatioon? GUI muutoksen vaikutus käyttöohjeeseen? Analysoimalla muutoksen vaikutus voidaan arvioida muihin määrityksiin tehtävät muutokset. Voidaanko suorittaa ns. tutkiva katselmointi, jossa arvioidaan määrittelyn muutoksen vaikutus muihin määrityksiin?

Otetaan tilanne, jossa ketterässä kehityksessä on tilanne, jossa ollan päästy jo pilotointi vaiheeseen, jossa kaikki dokumentit on tehty ja katselmoitu "oikeaoppisesti" tai parhaaksi katsotulla tavalla tarpeeseen nähden. Jos tässä vaiheessa määrittely muuttuu, se täytyy ensin analysoida muita määrittelyita vasten. Tämän jälkeen arvoidaan lisätyö muutoksissa muihin määrittelyihin ja hierarkiassa samalla tasolla oleviin dokumentteihin. Tämän jälkeen analysoidaan näiden muutosten vaikutus hierarkiassa alempana oleviin dokumentteihin ja koodiin ja arvioida muutoksen vaatima lisätyö. Näiden lukujen varjossa ketterän kehityksen tuoma "vapaus" muuttaa määrittelyitä saattaakin olla kallis temppu.

Kuitenkin kun katselmoidaan ajoissa voidaan saada ajatuksia esiin, joilla estetään turhat muutokset loppuvaiheessa (eli korjataan lakuperäisien määrittelyn bugi, joka on päässyt tuotantoon asti). Ketterästi katselmoimalla tai tutkivasti katselmoimalla voidaan vähentää katselmointien määrää tekniikkaa muuttamalla. Tämä vaatii tietenkin asiantuntemusta sekä kokemusta ja lisäksi eri näkökulmia. Jos katselmoidaan tutkivasti määrittelymuutosta tilaisuudessa tulisi olla mukana hierarkisesti alemman vaiheen dokumentoijat (arkkitehti, suunnittelija, koodati, jne.), joka pystyy arvioimaan oman työnsä kautta vaikutuksia saman dokumentin muihin määrittelyihin ja seitä kautta hierarkisesta alempana olevien dokumenttien muutostarpeisiin.

Voidaan siis ottaa käyttöön ns. tutkiva katselmointi (Exploratory Review) jossa tutkitaan muutoksen vaikutusta muihin määrittelyihin ketterästi. Tämä voi siis olla esisuunnittelematonta "kyseenalaistamista", jossa mietitään muutoksen vaikutusta kokonaisuuteen. Tämän tarkoitus on siis lisätä katselmoinnin syvyyttä tai keskittyä ainoastaan muutosten katselmointiin. Jos tutkivaa katselmointia on mukana tavallisissa katselmointitilaisuuksissa, voidaan ehkäistä alueita, joita ei välttämättä ole kunnolla määritelty/suunniteltu/koodattu mutta joka tulisi hierarkisesti olla hyvin määritelty/suunniteltu/koodattu. Onko kenelläkään kokemusta "tutkivasta katselmoinnista" tai onko se olemassa jollakin toisella nimellä? Löytyykö tällaisesta dokumentaatiota?