Riskit vaikuttavat toteutuessaan haitallisesti projekteihimme. Riskienhallinta tarkoittaa sen pohtimista, mitä riskejä on olemassa, sekä toimien toteuttamista niiden todennäköisyyden pienentämiseksi, poistamiseksi tai niiden sidosryhmien tavoitteisiin kohdistuvien vaikutusten vähentämiseksi.
Joissakin yrityksissä riskienhallintaa harjoitetaan insinööritieteellisen ja matemaattisen tarkasti. Ohjelmistoalalla näin tarkka ei kuitenkaan voida olla. Useimmat organisaatiot eivät edelleenkään harjoita riskiperustaista testausta järjestelmällisesti. Tähän on kuitenkin hyvä syy: ohjelmistotuotteen riskien arviointi on usein tunnistamisen jälkeen erittäin vaikeaa.
Testauksen ja laadunvarmistuksen näkökulmasta riski on ”huolta aiheuttava vikaantumistapa”. Riskiperustainen testaus on käytäntö, jossa järjestelmän mahdolliset vikaantumistavat mallinnetaan tuotteen riskeiksi testauksen rajauksen, laajuuden ja priorisoinnin tueksi.
Tässä artikkelissa esittelen riskiperustaisen testauksen julistuksen. Tarkastelemme klassista riskienhallintaa ja sitä, miten voimme mukauttaa sitä testaajille hyödylliseksi. Lopuksi käsittelemme joitakin käytännön asioita ja näkökohtia, jotka auttavat sinua soveltamaan omaa riskiperustaista testausmenetelmääsi.
- Projekti-, prosessi- ja tuoteriski
- Riskiperustaisen testauksen julistus
- Klassinen lähestymistapa riskeihin
- Tuoteriski ja testaus
- Käytännön näkökohdat
- Testauksen rooli riskienhallinnassa
Projekti-, prosessi- ja tuoteriski
Riskistä ja riskienhallinnasta on satoja kirjoja, joissa kuvataan lukuisia lähestymistapoja riskien hallintaan projektitasolla. Tyypillisesti nämä lähestymistavat keskittyvät siihen, mitä kutsumme projekti- ja prosessiriskeiksi, ja niissä saattaa olla yksi riski, jonka nimi on esimerkiksi ”vaatimusten täyttämättä jääminen”. Yksi vaatimuksiin liittyvä riski ei ole kovin hyödyllinen, koska yksittäistä riskiä ei voi priorisoida testattavaksi.
Ohjelmistoriskejä on kolmea tyyppiä.
Projektiriski: Nämä riskit liittyvät projektiin sen omassa toimintaympäristössä. Projekteilla on yleensä ulkoisia riippuvuuksia, kuten osaamisen saatavuus, riippuvuus toimittajista, kiinteät määräajat tai rajoitteet, kuten kiinteähintainen sopimus. Ulkoiset riippuvuudet kuuluvat projektinhallinnan vastuulle.
Prosessiriski: Nämä riskit liittyvät ensisijaisesti projektin sisäisiin asioihin, ja projektin suunnittelu, seuranta ja hallinta joutuvat tarkastelun kohteeksi. Tyypillisiä riskejä ovat projektin monimutkaisuuden, työmäärän tai tarvittavan osaamisen aliarviointi. Projektin sisäinen hallinta, kuten hyvä suunnittelu, edistymisen seuranta ja ohjaus, kuuluu kokonaisuudessaan projektinhallinnan vastuulle.
Tuoteriski: Tuoteriski on testaajia ensisijaisesti kiinnostava riskialue. Nämä riskit liittyvät tuotteen määrittelyyn, vaatimusten vakauteen (tai sen puutteeseen), tuotteen monimutkaisuuteen ja teknologian alttiuteen vikaantumiselle.
Tästä eteenpäin keskitymme tuoteriskeihin. Käytämme tuoteriskin käsitettä seuraavasti:
Riskiperustaisen testauksen julistus
Projekteissa, joissa riskejä otetaan (eli mielestämme kaikissa projekteissa), testaajien on tuotava riskit johdon näkyville ja ehdotettava luotettavia testausmenetelmiä näiden riskien käsittelemiseksi projektin kaikissa vaiheissa.
Johdon tehtävänä on toteuttaa ja/tai valvoa seuraavia riskiperustaisen testauksen tehtäviä:
Klassinen lähestymistapa riskiin
Muunnelmia on monia, mutta klassisessa lähestymistavassa riskiä pyritään arvioimaan kvantitatiivisesti.
Have an account? Log In
Todennäköisyys, seuraus ja altistuminen
Tuotteen riskin arvioimiseksi meidän on ymmärrettävä, mikä kyseisen vikaantumistavan seuraus on. Jos vika ilmenee, sanomme riskin realisoituvan. Sitten kysymme: “kuinka vakava riski on?”, eli mikä on sen altistuminen.
Altistumisen määrittämiseksi arvioimme riskiä kahdessa ulottuvuudessa:
- Riskin realisoitumisen todennäköisyys. Tämä arvo ilmaistaan tyypillisesti prosenttiosuutena, joka on suurempi kuin nolla mutta pienempi kuin 100 prosenttia.
- Riskin realisoitumisen seuraus (tai vaikutus tai menetys). Tämä on vahingon mahdollinen kustannus, jos kyseinen vikaantumistapa ilmenee.
Riskin altistuminen – eli se, kuinka vakava riski on – lasketaan todennäköisyyden ja seurauksen tulona.
Klassisesta lähestymistavasta riskiin puuttuu usein tehokkaaseen hallintaan tarvittava teknologinen tuki. Nykyaikaiset testinhallintaratkaisut täyttävät tämän aukon tarjoamalla riskiperusteiseen testaukseen räätälöityjä ominaisuuksia.
Kvantitatiivinen tai kvalitatiivinen pisteytys
Mahdollisen vikaantumisen kustannuksia on usein vaikea ennustaa. Ilman lisätietoja on myös lähes mahdotonta ennustaa vikaantumisen todennäköisyyttä kovin varmasti. Siksi useimmat ammattilaiset käyttävät todennäköisyydelle ja seuraukselle puolikvantitatiivisia tai kvalitatiivisia asteikkoja.
On tavallista käyttää molemmille asteikoille numeerisia arvoja yhdestä viiteen, jolloin altistumisen mahdolliset arvot ovat yhdestä kahteenkymmeneenviiteen. Harvat testaajat, kehittäjät tai sidosryhmät kuitenkaan antavat näille numeroille arvoja kovin luottavaisesti, joten riskialtistuminen arvioidaan usein suoraan asteikolla 1–5 tai — vielä yksinkertaisemmin — punainen, keltainen, vihreä -arviona. Jotkut menevät jopa niin pitkälle, että sanovat riskien kuuluvan soveltamisalaan tai olevan sen ulkopuolella, mutta mielestämme tämä on jo liiallista yksinkertaistamista.
Riippumatta siitä, kvantifioitko riskit tai käytätkö niissä värikoodausta, riskinarviointien kriittinen asia ei ole pisteytys, vaan keskustelut ja väittelyt, joita käydään pisteitä määritettäessä ja niistä keskusteltaessa.
Jos sinua pyydetään pisteyttämään riskit tarkemmin kuin asteikolla yhdestä kolmeen (tai korkeintaan viiteen), sinun kannattaa vakavasti harkita, onko antamillasi numeroilla todellista arvoa.
Numeerinen pisteytys saattaa antaa vaikutelman tieteellisestä täsmällisyydestä, mutta jos numerot ovat arvailua, huijaat itseäsi. Jos numerot paljastavat mielipide-eroja, esimerkiksi käyttäjä sanoo “viisi” ja kehittäjä ”yksi!”, asiasta on syytä keskustella, koska odotukset tai käsitykset ovat selvästi erilaisia.
Varo käyttämästä riskeille yksinkertaista soveltamisalaan kuuluva / soveltamisalan ulkopuolinen -jaottelua. Saattaa olla selvää, mitkä huolta aiheuttavista riskeistä on käsiteltävä testaamalla. Projektit kuitenkin kehittyvät ajan myötä ja usein viivästyvät, joten kompromisseja on tehtävä. Jos riskejä ei priorisoida jollakin tavalla, sinun on käytävä läpi kaikki huolta aiheuttavat riskit päättääksesi, mitkä niistä on ehkä poistettava soveltamisalasta tai lisättävä siihen.
Käsittelemme soveltamisalan määrittämistä, priorisointia ja skaalausta tarkemmin tulevissa artikkeleissa, joten pysy kuulolla.
Tuoteriski ja testaus
Tuoteriskien käsittely tuo esiin sidosryhmien pelot siitä, että projektin tai järjestelmän kriittisillä alueilla ilmenee vika. Kun meillä on luettelo tuoteriskeistä, miten muutamme sen toiminnaksi ja konkreettisiksi testaussuunnitelmiksi? Ennen kuin voimme vastata tähän kysymykseen, meidän on ymmärrettävä hieman paremmin, miten testaus vaikuttaa riskinarviointeihimme tai ohjaa niitä.
Testaus ei vähennä riskiä – se antaa tietoa riskinarviointeihin
Kuulet usein ihmisten sanovan, että “testaus vähentää riskiä”. Se ei pidä paikkaansa — testaus voi joskus lisätä riskiä. Mantra siitä, että testaus vähentää riskiä, juontuu sekä riskien että testauksen puutteellisesta ymmärtämisestä.
Oletetaan, että olemme tunnistaneet riskin, jonka mukaan jokin ominaisuus tai toiminnallisuus saattaa vikaantua. Laadimme testin ja suoritamme sen. Testi saattaa onnistua tai epäonnistua. Miten testin onnistuminen tai epäonnistuminen vaikuttaisi riskinarvioomme?
Ensinnäkin testit eivät vaikuta ymmärrykseemme vikaantumisen seurauksesta. Vikaantumisen seuraus on mikä on, eikä testaus muuta sitä.
Testillä ja sen vaikutuksella riskin todennäköisyyteen on neljä merkityksellistä lopputulosta. Ne on tiivistetty tähän taulukkoon:
| Riskin todennäköisyys kasvaa | Riskin todennäköisyys pienenee | |
| Testi läpäistään | Ei. Testin läpäiseminen voi vain lisätä luottamustamme siihen, ettei vikatilaa ilmene. (Tämä edellyttää, että testimme ovat merkityksellisiä.) | Kyllä, lopulta. Kun suoritamme yhä useampia testejä, jotka läpäistään, ja tutkimme monipuolisia skenaarioita, vian ilmenemisen todennäköisyys pienenee. |
| Testi epäonnistuu | Mahdollisesti epäonnistumisen syystä riippuen. Todennäköisyys kuitenkin pienenee ajan myötä. Ennustimme tämän vikatilan ilmenevän, joten testivalintamme osoittautui oikeaksi. Onneksi voimme korjata tämän nyt ja kohdistaa testauksemme muiden samantyyppisten vikojen riskin pienentämiseen. | Ei todennäköisesti, ellemme arvioineet riskiä väärin. |
Suorittamalla tiettyyn riskiin liittyviä testejä saamme yhä enemmän tietoa riskinarviomme tarkentamiseksi. Jos testit epäonnistuvat, valintamme osoittautuu oikeaksi. Kun korjaamme vian ja testaamme uudelleen, riskinarviomme pitäisi pienentyä testien läpäisemisen myötä. Jos kuitenkin löydämme jatkuvasti uusia tai lisää virheitä, saatamme arvioida riskin uudelleen suuremmaksi.
Nyt kun ymmärrät testaamisen mahdollisuudet riskinarviomme tukena, voimme tarkastella testien määrittämistä riskikuvausten perusteella.
Riskiperusteinen testisuunnittelu
Testaajina meidän on tuotteen huolestuttavan riskin tunnistamisen jälkeen laadittava joukko testejä, jotka osoittavat kyseisen vikatilan olevan epätodennäköisempi. Testausmenetelmämme on luonnollisesti pyrkiä aiheuttamaan vikatila mahdollisimman monella tavalla, jolloin joko:
Testimme keskittyvät kokonaisuutena tapoihin, joilla valittu vikatila voi ilmetä. Oletetaan esimerkiksi, että riskinä oli ”moottoriajoneuvovakuutuksen vakuutusmaksun laskeminen väärin”. Tässä tapauksessa sopiva testitavoite voisi olla ”osoita syötemuuttujien kaikki parit -tekniikkaa käyttäen, että järjestelmä laskee moottoriajoneuvovakuutuksen maksun oikein”. Testaajalle voidaan antaa tämä testitavoite, jonka perusteella hän johtaa kaikki parit kattavan testitapausjoukon.
Käytännön näkökohdat
Seuraavaksi käsittelemme riskiperusteiseen testaukseen liittyviä käytännön näkökohtia.
Mitä jos sidosryhmät eivät ole kiinnostuneita osallistumaan riskinarviointiin?
Saatat huomata, että sidosryhmien aikaa on vaikea saada riskien tunnistamiseen ja arviointiin sekä testisuunnitelman laatimiseen.
Mitä jos tuotteen riskin testaamiseen on useita vaihtoehtoja?
Näin on tietysti lähes aina. Voit esimerkiksi testata huolestuttavaa ominaisuutta millä tahansa useista testien suunnittelutekniikoista tai mallintaa ominaisuuden jollakin ainutlaatuisella tavalla ja johtaa testit kyseisestä mallista. Voit käyttää tavoitteen asettamiseen useita kattavuusmittareita. Voit testata ominaisuuden manuaalisesti tai työkalun tai muun teknologian avulla.
Tarkastelemme seuraavassa artikkelissa ”Kuinka paljon testausta on riittävästi?”, miten voit tehdä valintoja.
Mitä jos testaus (riskin käsittelemiseksi) maksaa liikaa?
Koska vaihtoehtoja on lähes aina eikä riskin tutkimiseen ja riskinarvion tukemiseen sovellettavan testauksen määrälle ole ylärajaa, valinta on tehtävä. On sanomattakin selvää, että jotkin vaihtoehdot katsotaan liian kalliiksi. Kun siis esittelet vaihtoehtoja sidosryhmille, sinulla on oltava vähintään yksi kohtuuhintainen vaihtoehto ja yksi vaihtoehto, joka saattaa olla liian kallis.
Toistettakoon: tarkastelemme seuraavassa artikkelissa ”Kuinka paljon testausta on riittävästi?”, miten voit tehdä valintoja.
More Articles
Jos testaamme suuren riskin ominaisuuksia enemmän, testaammehan muita ominaisuuksia vähemmän?
Jos testauksen budjetti on määritetty tiimille etukäteen tai tiimin koko ja testaajien määrä on kiinteä, ihmisten suorittaman testauksen määrä on rajallinen (millä tahansa kiinteällä aikavälillä tai aikarajatussa jaksossa). Jos siis painotamme joitakin ominaisuuksia enemmän, muiden ominaisuuksien testauksen on vähennyttävä. Ominaisuuksien kattavuus tai vähintään niihin käytetty työmäärä vaihtelee riskin mukaan.
Tätä kannattaa tarkastella näin: kun testi epäonnistuu ja järjestelmästä löydetään virhe, virheelle määritetty vakavuus liittyy todennäköisesti läheisesti kyseisen vian seuraukseen (tuotannossa). Vakavammat virheet korjataan, koska ne ovat sidosryhmille yksinkertaisesti tärkeämpiä.
Tuotteen riskianalyysi tuo esiin alueet, joilla tärkeät virheet korjataan todennäköisemmin. Kun siis käytämme riskianalyysiä osoittamaan, missä testausta tehdään ja/tai missä testausta tehdään enemmän, löydämme todennäköisemmin tärkeitä virheitä ja epätodennäköisemmin virheitä ominaisuuksista, joista sidosryhmät eivät välttämättä välitä yhtä paljon.
Olisi mukavaa ajatella, että voisimme joskus testata kaikkea tasapuolisemmin. Mutta kun resurssit ja aika ovat rajalliset (ja niinhän ne aina ovat, eikö?), riskiperustainen lähestymistapa auttaa hyödyntämään testaajien aikaa tehokkaammin ja tarkoituksenmukaisemmin.
Entä jos testaaminen ei olekaan oikea ratkaisu?
Ennen kuin käytät aikaa tuotteen riskiin liittyvän testausmenetelmän yksityiskohtaiseen suunnitteluun, on tärkeää harkita myös muita kuin testaamiseen perustuvia vaihtoehtoja. Kuvitellaan esimerkiksi, että ollaan hyvin huolissaan siitä, ettei järjestelmäkomponentti ehkä suoriudu tuotannossa riittävän hyvin ja että vasteajat tai luotettavuus ovat heikkoja. Voisit tietenkin tehdä kuormitustestejä ja yrittää selvittää ongelmat virheenkorjauksen avulla. Muita vaihtoehtoja voisivat kuitenkin olla:
- Osta komponentti 3:nnen osapuolelta, älä rakenna sitä itse ja ota riskiä.
- Suunnittele ratkaisu uudelleen siten, että kuormitus jakautuu useiden komponentti-instanssien kesken.
- Siirrä käsittely eräajojärjestelmään, joka käyttää datan kopiota.
- Sen sijaan että kaikki käyttäjät otettaisiin käyttöön kerralla, toteuta asiakkaat vaiheittain alue kerrallaan ja seuraa suorituskykyä tarkasti.
- Ja niin edelleen.
Usein jokin muu toimintatapa ongelmien ennaltaehkäisemiseksi on tehokkaampi ja taloudellisempi kuin ongelmien etsiminen testaamalla myöhemmin.
Testauksen rooli riskienhallinnassa
Testaaminen voi vähentää julkaisemiseen liittyvää riskiä. Jos käytämme riskinarviointia testausaktiviteettiemme ohjaamiseen, testaajien tavoitteena on nimenomaisesti suunnitella testejä virheiden havaitsemiseksi, jotta ne voidaan korjata ja siten vähentää virheellisen tuotteen riskiä.
Virheiden havaitseminen vähentää tuotantokäytössä tapahtuvien häiriöiden jäännösriskiä, jolloin kustannukset kasvavat jyrkästi. Kun testi löytää virheen ja se korjataan, virheiden määrä vähenee ja näin ollen myös häiriön kokonaisriski pienenee.
Asiaa voi tarkastella myös näin: kyseisen virheen aiheuttama ”mikroriski” poistuu. On kuitenkin muistettava, ettei testaamisella voida löytää kaikkia virheitä, joten järjestelmään jää aina piileviä virheitä, joihin testaaminen ei ole antanut suoraa tietoa.
Jos kuitenkin keskitymme kriittisiin ominaisuuksiin ja löydämme niistä virheitä, havaitsemattomien virheiden todennäköisyys näissä kriittisissä ominaisuuksissa pienenee. Järjestelmän ei-kriittisiin ominaisuuksiin jääneiden virheiden seuraukset ovat vähäisempiä.
Vielä yksi huomio: riskianalyysiprosessi itsessään on riskialtis. Riskianalyysi voi sekä yliarvioida että aliarvioida riskit, mikä johtaa epätäydelliseen päätöksentekoon. Riskianalyysi voi myös edistää syyllistämisen kulttuuria, jos sitä viedään liian pitkälle.
Muiden riskianalyysiin liittyvien mahdollisten ongelmien lisäksi on ymmärrettävä, ettei ole olemassa sellaista absoluuttista riskiä, joka voitaisiin laskea projektin päätyttyä. Riskien luonteeseen kuuluu epävarmuus. Kuten testauksen tehokkuuden kohdalla, myös riskianalyysin arvo voidaan määrittää vasta jälkikäteen, projektin päätyttyä.
Siinä oli riskiperustaisen testauksen julistuksemme. Käsite palaa esiin koko Testauksen johtaminen -sarjan ajan, joten pysy kuulolla tulevien artikkelien varalta!
Tilaa The QA Lead -uutiskirje, niin saat ilmoituksen, kun sarjan uudet osat julkaistaan. Nämä kirjoitukset ovat otteita Paulin Testauksen johtaminen -kurssista, jota suosittelemme lämpimästi, jos haluat perehtyä tähän ja muihin aiheisiin syvällisemmin. Jos osallistut kurssille, käytä eksklusiivista kuponkikoodiamme QALEADOFFER ja säästä 60 dollaria kurssin täydestä hinnasta!
