Vianhallinta ja vian elinkaari Tässä esityksessä perehdytään testauksessa löydettyjen vikojen hallintaprosessiin ja eri osapuolten rooliin. Muutamia laajoja vian elinkaarimalleja tarkastellaan yksityiskohtaisesti. Huom. Käytännöt vianhallinnassa vaihtelevat eri organisaatioissa ja projekteissa tässä kuvatut tavat ovat enemmän suurten organisaatioiden arkea kuin pienten. 21.4.2009 1(37)
Sisällysluettelo 1/2 Viat ohjelmistokehitysprojekteissa 4 Vikojen korjaus on useiden osapuolten tehtäviä 5 Vikaraportin laadinta vika tulee projektin tietoon 6 Vikaraportointi on viestintää 7 Vika otetaan käsittelyyn 8 Error Manager koordinoi vikaviestintää 9 Vian korjaus integroidaan eli tuodaan seuraavaan sopivaan buildiiin 11 Kun vika on korjattu ja verifioitu 13 Vikojen elinkaari tarkemmin 14 Mitä tarkoittaa vian elinkaari 15 Elinkaari on sopimuskysymys 16 Milloin siirrytään vianhallintaan 19 Vian laaja elinkaari 20 Elinkaaren perusrunko vaiheet ja miten niissä toimitaan 22 21.4.2009
Sisällysluettelo 2/2 Optionaaliset vaiheet 26 Bugzillan käyttämä vian elinkaari 30 Bugzillan ratkaisutavat 35 IEEE-standardi 1044 ohjelmiston vikojen luokitteluun 37 21.4.2009
Viat ohjelmistokehitysprojekteissa Testatessa tuotteesta löytyy aina vikoja. Kehityskaaren alkupäässä enemmän ja loppupäässä vähemmän. Tuotteeseen yleensä jää valmiinakin joitain vikoja Osaa vioista ei missään vaiheessa korjata osa taas korjataan korkealla prioriteetilla. Miten toimitaan vian ilmettyä? Kuka korjaa? Mihin buildiin vika on korjattu? Kuka verifioi korjauksen? Ratkaistava viimeistään testausta suunniteltaessa. Mahdolliset ulkoistamisen tuomat tietoturvaan ja liikesalaisuuksiin liittyvät rajoitukset. 21.4.2009 4(37)
Vikojen korjaus on useiden osapuolten tehtäviä Testaaja löytää vian ja tekee raportin. Raportti ohjataan suoraan tai välikäsien kautta ohjelmamoduulista vastaavalle ohjelmistokehittäjälle. Hän korjaa vian ja liittää korjauksen ohjelmakoodiin. Testaaja saa tästä tiedon ja testaa korjauksen onnistumisen. Jos korjaus onnistuu, vika "suljetaan" ja voidaan vähäksi aikaa unohtaa. Näin pääpiirteissään seuraavassa katsellaan tarkemmin näitä tapahtumia. 21.4.2009 5(37)
Vikaraportin laadinta vika tulee projektin tietoon Tehdään vikaraportti. Testausprosessin aikana raportin tekee testaaja, joka löytää vian. Puhutaan "vian tekemisestä". Yleensä raportti tehdään kirjallisesti vikatietokantaan. Vikatietokanta "ilmoittaa" uusista vioista asianosaisille tai he huomaavat sen uusien vikojen listalla. 21.4.2009 6(37)
Vikaraportointi on viestintää Vikatietokanta on merkittävässä roolissa eri organisaation osien välillä kehittämisen kuluessa. Isoissa tai hajautetuissa organisaatiossa tarvitaan viestintään kaikki mahdolliset keinot! Testaajat käyttävät joskus vikatietokantaa selvittämään epätietoisuutta ohjelman suunnitellusta toiminnasta, ellei tietoa muuten saada. Kun epäselvästä toiminnasta "tehdään vika", siihen saadaan nopeasti vastaus, koska vikojen käsittelyä seurataan sähköpostitiedustelulla vastausta ei kenties saada koskaan. 21.4.2009 7(37)
Vika otetaan käsittelyyn Vastuuhenkilö hoitaa asian eteenpäin koordinoi tai korjaa. Ohjelman kehittäjä. Error Manager (EM). Vikojen esitarkastus onko kaikki tiedot kunnossa? Erityisesti tuoteversio ja buildi, joihin vika liittyy. Tukena, jos testaajat ovat kokemattomia (esim. true testers). Vikojen priorisointi. Vikojen edelleenohjaus. Error Managerilla siis oltava tarkat tiedot vastuualueista. 21.4.2009 8(37)
Error Manager koordinoi vikaviestintää 1/2 Usein projekteissa on nimetty joku henkilö Error Manageriksi. Ei välttämättä tällä termillä: tehtävät voivat olla integroidut projektipäällikön, build managerin tehtäviin tai projektilla voi olla vaikkapa "koordinaattorin" tehtävä. Vastuu vikojen hallinnasta. Koordinoi vikaraporttien jakelua oikeiden henkilöiden välillä. Valvoo vikaraporttien ja vikatietokannan laatua. 21.4.2009 9(37)
Error Manager koordinoi vikaviestintää 2/2 Luottamuksellisuuden varmistaminen (liike- yms. salaisuudet) yksi Error Managerin tehtävä: Toimii suodattimena hajautetussa ohjelmistohankkeessa eri osapuolten välillä esimerkiksi katsoo, että ulkoistetulle testausryhmälle ei siirry sille kuulumattomia tuotetietoja. He eivät välttämättä saa edes tietää, kuka ohjelmistokehittäjä/yritys vastaa kyseisestä ohjelman osasta ja vian korjauksesta. Voi toimia oman työnsä ohella tai päätoimisena. Valinta riippuu projektin laajuudesta. Yhden tuotteen kehittäminen vs. useita tuotteita tuottava ohjelmistokehitys, johon saattaa liittyä useita alihankkijoita suunnittelijoista testaukseen. 21.4.2009 10(37)
Vian korjaus integroidaan eli tuodaan seuraavaan sopivaan buildiiin 1/2 Ohjelman suunnittelija tai ylläpitäjä tekee korjauksen. Korjaus liitetään seuraavaan buildiin. Korjauksen jälkeen vika on ohjattava jälleen eteenpäin Testaaja tarkistaa, onko vika korjaantunut. Jos vika on korjaantunut, vian saa "sulkea" tai Jos vika ei ole korjaantunut, se osoitetaan uudelleen suunnitelijalle tai ylläpitäjälle 21.4.2009 11(37)
Vian korjaus integroidaan eli tuodaan seuraavaan sopivaan buildiiin 2/2 Error Manager voi koordinoida korjausta. Isoissa projekteissa. Tarvitaan näkemystä kokonaisuudesta ja buildien kokoamisesta. Korjattujen komponenttien integrointi tehtyihin buildeihin. Kun vika on saatu integrated tai corrected -tilaan, siinä tulisi ilmetä missä buildissa korjaus on toteutettu. 21.4.2009 12(37)
Kun vika on korjattu ja verifioitu Korjatut ja verifioidut viat ovat Error Managerin vastuulla. Näitäkään vikoja ei tulisi poistaa vikatietokannasta. Sama vika voi ilmetä uudelleen tuotteeseen myöhemmissä kehitysvaiheissa. Tilastointi esimerkiksi buildeittain. Error Manager vastaa siis vioista koko vian elinkaaren ajan. Arvokasta tietoa niin käynnissä olevalle projektille, kuin uusillekin projekteillekin. 21.4.2009 13(37)
Vikojen elinkaari tarkemmin Äskeisessä kuvauksessa tutustuttiin pääpiirteissään vian elinkaareen. Nyt tarkastellaan sitä yksityiskohtaisemmin. 21.4.2009 14(37)
Mitä tarkoittaa vian elinkaari Vian elinkaari tarkoittaa uuden vian eri vaiheita sen hallinnoinnissa löytämisestä korjatun vian kuittaamiseen pois seurantajärjestelmästä. Elinkaari konkretisoituu niihin statustietoihin elinkaaren vaihe tai elinjakso joita vikatietoon liitetään sen käsittelyn kuluessa vikatietokannassa. Jokaisessa vaiheessa vika on jonkin osapuolen vastuulla vian tunnistavat usein testaajat, jonka jälkeen "pallo" siirretään jollain menettelyllä ohjelmistokehittäjille ja korjausten jälkeen taas testaajille, jotka varmistavat korjauksen onnistumisen. 21.4.2009 15(37)
Elinkaari on sopimuskysymys 1/3 Elinkaari on aina organisaation ja projektin sopimuskysymys. Siihen on olemassa tiettyjä malleja, joista valitaan tilanteeseen sopivan tyyppinen ja laajuinen malli. Mallien sopivuus riippuu ohjelmistokehityksen organisoinnista. Päämiehellä ja alihankkijoilla on tärkeää olla sama malli. Teollisuuden yleiset perusmallit ovat suositeltavia, koska ne voivat olla jo alihankkijoilla ja kumppaneilla käytössä ja niiden soveltamiseen löytyy tukiaineistoa. 21.4.2009 16(37)
Elinkaari on sopimuskysymys 2/3 Yksinkertaiset elinkaarimallit ovat yleensä sopivia yhteistyöhön, koska: Niissä on mallin oikea soveltaminen varmempaa ja virheettömämpää. Malli on jokaisen osapuolen helppo oppia ja opastaa (uudet työntekijät ja alihankkijat). Vain yksinkertainen malli voidaan muistaa. Termien ymmärrettävyys ja käytännöllisyys (arkikieli!) on tärkeää muuten tulee sekaannuksia. Kypsässä, harjaantuneessa ja osaavassa organisaatiossa voidaan käyttää monimutkaisempia malleja. 21.4.2009 17(37)
Elinkaari on sopimuskysymys 3/3 Mallien laajenemista pitää varoa. Jokaisessa organisaatiossa tulee kiusaus lisätä uusia luokkia erilaisille käsittelyn detaljeille ja toiveille vähitellen prosessi alkaa olla jokaisen vian yhteydessä kuin veroilmoituksen käsittelyä. Elinkaarimallin pitäisi kuitenkin yksinkertaistaa tuotekehitystä, eikä monimutkaistaa sitä! Ylläpitovaiheessa muuttuu organisaatio ja vikojen luokittelulle tulee uusia tehtäviä. Mm. tukipalvelujen pitää pystyä kirjaamaan ja käsittelemään vikatietoja. 21.4.2009 18(37)
Milloin siirrytään vianhallintaan Kehittämisen alkuvaiheessa kehittäjät vastaavat itse vioista ja tuotetason vianhallinta ei ole enää mielekästä se olisi ajan ja resurssien haaskausta, koska vikoja on valtavasti ja ne ovat koodaajilla koko ajan työn alla. Vianhallintaa ei siis oteta käyttöön heti projektin alussa. Vianhallintaan siirrytään vaiheittain. Kun ohjelmiston osioiden koodi "valmistuu" ja ne siirretään ulkopuolisen testaamisen piiriin. Siis yksikkötestauksen jälkeen. 21.4.2009 19(37)
Vian laaja elinkaari Seuraavan sivun kuvassa on laaja elinkaarimalli, joka on suunniteltu testausryhmän tekemään testaustyöhön. Se toimii käytännön projektien suunnittelun taustalla olevana mallina, josta valitaan kullekin projektille tarkoituksenmukaiset laatikot. Olennaista on mallin keskiosan jouheva kulku. Ne vaiheet ovat lähes kaikissa elinkaarimalleissa. Termit ovat elinkaarimalleja käyttävissä organisaatioissa poikkeuksetta englanniksi, johtuen vikatietokantojen englanninkielisyydestä. Kaaviossa olevat käännökset ovat siis toissijaisia, epävirallisempia termejä. 21.4.2009 20(37)
1. Detected / Tunnistettu 1.2 To be ignored / Ehdotetaan ignoroitavaksi 2.1 Pending / Odottaa käsittelyä 2. Acknowledged / Tunnustettu 1.3 Reproduce / Toistakaa 1.4 To be postponed / Siirretään seuraavaan versioon 3. In progress / Käsittelyssä 4. Corrected / Korjattu 8.1 Non reproducable / Ei toistettavissa 7. Ignored / Ignoroidaan 8. Postponed / Siirretty seuraavaan versioon 5. Verified / Varmistettu 6. Closed / Suljettu 7.1 Duplikate / Vika on jo kirjattu (duplikaatti) 21.4.2009 21(37)
Elinkaaren perusrunko vaiheet ja miten niissä toimitaan 1/4 Seuraavassa on lueteltu suuri määrä erilaisia vikatiloja ja niiden merkityksiä. Testausprojekteissa ei läheskään aina ole käytössä kaikkia lueteltuja vikatiloja. Riippuen vikakannasta saattavat myös vikatilojen nimet vaihdella, vaikka niiden merkitys sinänsä pysyisikin samana. Vikatilojen numerot viittaavat aiemmin esitettyyn vian elinkaarimalliin. Vikatilojen nimen perään on kirjoitettu vian tyypillinen vastuuhenkilö ko. tilassa. Tämä määritellään konkreettisesti yritys- ja projektikohtaisesti. 21.4.2009 22(37)
Elinkaaren perusrunko vaiheet ja miten niissä toimitaan 2/4 Detected / Tunnistettu (1) (testaaja) Kun uusi vika on havaittu viedään se detected-tilaan ja ohjataan oikealle vastuuhenkilölle. Kaikki yllä mainitut tiedot kirjataan vikaraporttiin. Kun vika on vastuuhenkilöllä, detected-tilaiselle ei ole tehty vielä mitään. Acknowledged / Tunnustettu (2) (ohjelmistokehittäjä, Error Manager) Vian vastuuhenkilöksi on määritelty oikea henkilö ja vika on oikeassa paikassa vikakannassa. Kun vian korjaaminen alkaa, siirretään vika tilaan in progress. 21.4.2009 23(37)
Elinkaaren perusrunko vaiheet ja miten niissä toimitaan 3/4 In Progress / Käsittelyssä (3) (ohjelmistokehittäjä) Vian korjaaminen on käynnissä. Kun vika on korjattu, siirretään se tilaan corrected ja asetetaan vastuuhenkilöksi vian raportoija (testaaja). Corrected (Integrated) / Korjattu (4) (testaaja) Kun vika on oletettavasti korjattu, vika on tilassa corrected. Vikaan on lisätty buildin numero ja mahdollisesti muita tietoja missä ja miten vika on korjattu. Jos vika on korjaantunut, siirretään se tilaan verified ja asetetaan vastuuhenkilöksi Error Manager (EM). Muussa tapauksessa se asetetaan tilaan acknowledged ja asetetaan vastuuhenkilöksi ohjelmistokehittäjä, jonka vastuulla vika on. 21.4.2009 24(37)
Elinkaaren perusrunko vaiheet ja miten niissä toimitaan 4/4 Verified / Varmistettu (5) (testaaja) Vika viedään tilaan verified, jos korjaus on tapahtunut. Vika on valmis sulkemista varten. Closed / Suljettu (6) (Error Manager) Yleisin ilmenemistila silloin, kun vika on verifioitu eli se on korjaantunut. Joskus vika voidaan laittaa tähän tilaan, kun se on katsottu aiheettomaksi. 21.4.2009 25(37)
Optionaaliset vaiheet 1/4 Reproduce / Toistakaa (1.3) (testaaja) Viasta vastuussa oleva henkilö ei pystynyt toistamaan vikaa, joten vastuu virheestä siirtyy vian raportoijalle, jonka odotetaan pystyvän toistamaan vian ja määrittelemään sille toistettavuusproseduurin. Jos vian raportoija pystyy toistamaan vian, asetetaan vika acknowledged tilaan. Muussa tapauksessa asetetaan vika tilaan to be ignored. (Reproduce tilassa testaaja). Pending / Odottaa käsittelyä (2.1) (ohjelmistokehittäjä) Vika viedään tilaan pending, jos sitä ei pystytä korjaamaan ennen jonkin toisen vian korjaamista. Vika siirretään tilaan in progress, kun korjaustyö aloitetaan. 21.4.2009 26(37)
Optionaaliset vaiheet 2/4 To be ignored / Ehdotetaan ignoroitavaksi (1.2) (testaaja) Vika viedään tilaan to be ignored, kun on kirjattu vika mutta huomattu se jälkeenpäin aiheettomaksi. Vika ohjataan vastuuhenkilölle kommenttien kera, joka päättää vian ohittamisesta. Joskus projektilla ei ole vikakannassa kyseistä tilaa ja tällöin voidaan vika esimerkiksi laittaa takaisin vastuuhenkilölle ja esittää pyyntö, jossa vika jätetään huomiotta. To be postponed / Siirretään seuraavaan versioon (1.4) (Error Manager / ohjelmistokehitys) Vika on analysoitu ja päätetty siirtää käsiteltäväksi seuraavassa suuressa versiossa (milestone). 21.4.2009 27(37)
Optionaaliset vaiheet 3/4 Ignored / Ignoroidaan (7) (Error Manager / ohjelmistokehitys) Vika on päätetty jättää ottamatta huomioon. Tällaisia tilanteita voivat olla esimerkiksi seuraavat: Vika on testaajan väärinymmärrys. Vika on mitätön. Vikaa ei saada toistettua. Duplicate / Vika on jo kirjattu (duplikaatti) (7.1) (Error Manager / ohjelmistokehitys) Vika on duplikaatti. Toisin sanoen, vian raportoija on kirjannut kantaan vian, joka jo on kannassa. Postponed / Siirretty seuraavaan versioon (8) (Error Manager / ohjelmistokehitys) Kirjattu vika ei ole sen laatuinen, että siihen tarvitsisi panostaa. Vika on siirretty korjattavaksi myöhäisimpiin julkaisuihin. 21.4.2009 28(37)
Optionaaliset vaiheet 4/4 Non reproducable / Ei toistettavissa (8.1) (testaaja Error Manager / ohjelmistokehitys) Vikaa ei ole saatu toistettua. Vikaa on täten mahdotonta korjata. Todennäköisimmin mitään vikaa ei olekaan, vaan kertaluonteinen ongelma menee elektronisten ja digitaalisten laitteiden normaalien häiriöiden piikkiin. 21.4.2009 29(37)
Bugzillan käyttämä vian elinkaari 1/5 Vikakanta Bugzilla käyttää hieman erilaista elinkaarta. Ohjelmiston yleisyyden vuoksi se on hyvä esitellä tässä yhteydessä. Osa Bugzillan käyttämästä elinkaaresta selittyy sillä, että elinkaarta käytetään hajautetussa open source -ohjelmistokehityksessä jossa esimerkiksi viat täytyy todentaa ennen niiden hyväksymistä. Testausyksikön tekemässä testauksessa tähän ei ole tarvetta. 21.4.2009 30(37)
Bugzillan käyttämä vian elinkaari 2/5 Unconfirmed / Vahvistamaton New / Uusi Assigned / Osoitettu Reopened / Uudelleen avattu Resolved / Ratkaistu Ratkaisutavat Verified / Varmistettu Closed / Suljettu 21.4.2009 31(37)
Bugzillan käyttämä vian elinkaari 3/5 Unconfirmed / Vahvistamaton Vika on juuri viety vikakantaan. Kukaan ei ole vahvistanut, että vika on tosi. Tätä käytetään yleensä vain tilanteissa, joissa vikailmoituksia tulee suurelta yleisöltä ja niiden luotettavuus on heikko. New / Uusi Vika on lisätty vastuuhenkilön vikalistalle ja ne pitää käsitellä. Tästä vaiheesta viat siis siirtyvät "osoitettujen" luokkaan, kun vastuuhenkilö ottaa vian vastuulleen tai siirretään jollekin toiselle henkilölle uusi-tilassa. 21.4.2009 32(37)
Bugzillan käyttämä vian elinkaari 4/5 Assigned / Osoitettu Vikaa ei ole korjattu, mutta se on osoitettu oikealle henkilölle tai vikaraportin vastaanottaja on ottanut sen itselleen. Vika voidaan vielä ohjata toiselle henkilölle tai korjata, jolloin tulos on resolved / korjattu Reopened / Uudelleen avattu Vika oli jo kuitattu korjatuksi, mutta avataan uudestaan. Resolved / Ratkaistu Vika on korjattu, mutta odottaa varmistusta laadunvarmistuksesta (testauksesta). Tässä vaiheessa vikaan liitetään tieto sen ratkaisutavasta (ks. tilojen listan lopusta) 21.4.2009 33(37)
Bugzillan käyttämä vian elinkaari 5/5 Verified / Varmistettu Testausyksikkö / laadunvarmistus on tarkastanut vian ja todennut, että se on korjattu korrektisti. Viat pysyvät tässä tilassa, kunnes tuote julkaistaan. Silloin viat suljetaan. Closed / Suljettu Vika on todettu "kuolleeksi" ja se on oikein korjattu. 21.4.2009 34(37)
Bugzillan ratkaisutavat 1/2 Resolved-vaiheessa vikaan liitetään jokin seuraavista ratkaisuista: Fixed / Korjattu: Vika on korjattu ja korjaus on testattu. Invalid / Ei vika: Kuvattu ongelma ei ole vika. Wontfix / Ei korjata: Kuvattu ongelma on vika, mutta sitä ei tulla koskaan korjaamaan. Vikaa ei kenties ole mahdollista korjata tai korjaus tuottaisi enemmän uusia ongelmia. Later / Myöhemmin: Vika korjataan myöhemmässä versiossa. 21.4.2009 35(37)
Bugzillan ratkaisutavat 2/2 Remind / Muistuta: Vika tullaan todennäköisimmin korjaamaan vasta seuraavassa versiossa, mutta saatetaan korjata jo tässäkin versiossa, jos ehditään. Duplicate / Duplikaatti: Vika on todellinen, mutta se on toisen vian duplikaatti. Worksframe / Epätoivoinen: Vikaa ei kyetä toistamaan. Ohjelmakoodista ei saa pienintäkään vihjettä, miksi virheellinen käyttäytyminen voisi tapahtua. Jos viasta saadaan lisätietoa, se avataan uudestaan, mutta nyt se laitetaan "mappi ö:hön". 21.4.2009 36(37)
IEEE-standardi 1044 ohjelmiston vikojen luokitteluun IEEE Std 1044-1993(R200) Standard Classification for Software Anomalies. Suurten ja monimutkaisten järjestelmien vianhallinnassa kannattaa käyttää järeitä luokitusjärjestelmiä. IEEE:n standardi 1044 tarjoaa sellaisesta yhden mallin. Standardista on oma referaattinsa. 21.4.2009 37(37)