Tik-76.115 Tietojenkäsittelyopin ohjelmatyö Tietotekniikan osasto Teknillinen korkeakoulu VIRHERAPORTOINTI LiKe Liiketoiminnan kehityksen tukiprojekti Versio: 1.1 Tila: hyväksytty Päivämäärä: 12.12.2000 Tekijä: Niko Tolvanen Kommentit: Hyväksyi: Maaret Pyhäjärvi, Katariina Ylinen
VERSIOHISTORIA Versio Päivämäärä Muutokset Muuttaja 0.1 22.11.2000 Alustava versio Niko Tolvanen 1.0 5.12.2000 Katselmointikorjaukset tehty Niko Tolvanen 1.1 12.12.2000 Asiakaskatselmoinnin korjaukset tehty Niko Tolvanen
1. JOHDANTO 1 1.1 MÄÄRITELMÄT, TERMIT JA LYHENTEET 1 1.2 TAUSTAA 1 1.2.1 MIHIN VIRHERAPORTOINTIA JA VIRHETIETOKANTAA TARVITAAN 1 1.2.2 OHJELMISTON VIRHERAPORTTIEN SEURANNAN VAATIMUKSET 2 2. KÄYTETTÄVÄ VIRHERAPORTOINTIJÄRJESTELMÄ 3 3. VIRHERAPORTOINTIPROSESSI 3 3.1 KOSKA VIRHERAPORTTEJA LUODAAN? 3 3.2 TOIMINTA VIRHEEN LÖYDYTTYÄ 4 3.3 VIRHEEN KORJAUSPROSESSI JA VIRHERAPORTIN SULKEMINEN 5 3.4 VIRHEIDEN KATEGORISOINTI OHJELMISTON ERI OSIEN SUHTEEN 5 4. KÄYTÄNNÖN TOIMINTA BURANAA KÄYTTÄEN 6 4.1 BURANA-JÄRJESTELMÄSSÄ KÄYTETTÄVÄT KENTÄT JA NIIDEN MERKITYS 6 4.2 VIRHEIDEN TILOJEN KUVAUKSET 8 4.3 TYYPILLISET TOIMINNOT JA NIIDEN SUORITTAMINEN BURANASSA 9 4.3.1 UUDEN VIRHEEN AVAAMINEN 9 4.3.2 VIRHEEN TARKASTELEMINEN 9 4.3.3 VIRHEEN OTTAMINEN KORJATTAVAKSI 9 4.3.4 VIRHEEN MERKITSEMINEN KORJATUKSI 9 4.3.5 VIRHEEN KORJAUKSEN TARKISTAMINEN JA SULKEMINEN TAI AVAAMINEN UUDELLEEN 9
1. JOHDANTO Tämä dokumentti on LiKe-järjestelmän virheraportointiprosessin kuvaus ja virheraportointiohje. Dokumentti on tarkoitettu n sisäiseen käyttöön, asiakkaalle ja kurssin henkilökunnalle. 1.1 MÄÄRITELMÄT, TERMIT JA LYHENTEET LiKe-projektissa käytetyt määritelmät, termit ja lyhenteet on selitetty projektin laatukäsikirjassa. 1.2 TAUSTAA Ohjelmistokehitys on prosessi, jossa asiat eivät aina mene kerralla oikein. Virheitä syntyy, ja niiden tehokas raportointi on olennainen osa kehitysprosessia. Eräs (ja usein käytetty) tapa raportoida ohjelmistossa olevia virheitä on kirjata ne tietokantaan. Näin tapahtuu tässäkin projektissa, jotta virheet on helppoa priorisoida, analysoida ja korjata. 1.2.1 Mihin virheraportointia ja virhetietokantaa tarvitaan Ohjelmistokehityksessä tapahtuvien virheiden korjaaminen on olennainen osa ohjelmiston kehitystä toimivaksi ja menestyväksi tuotteeksi. Virhetietokanta on tarpeellinen virheiden tehokkaan korjaamisen ja seurannan apuna. Virheiden käsittelyssä oleellista on, että virhe raportoidaan ja korjataan vain kerran. Virhetietokannalla on monia etuja muihin raportointimenetelmiin verrattuna, joista päällimmäinen on seurannan keskittyminen yhteen paikkaan, josta tiedot ovat kätevästi kaikkien prosessiin osallistuvien henkilöiden saatavissa. Tämän lisäksi tietokannassa olevat tiedot voidaan säilyttää koko projektin ajan ja myös sen jälkeen, jolloin ne ovat käytettävissä esimerkiksi ohjelmiston seuraavia versioita suunniteltaessa. Mikäli virheitä seurattaisiin vain esimerkiksi satunnaisten sähköpostien avulla, tämä ei olisi mahdollista. 1
1.2.2 Ohjelmiston virheraporttien seurannan vaatimukset Virheraportteja syntyy kaikissa ohjelmiston elinkaaren vaiheissa. Yleiskäyttöisen virheraporttien seurantajärjestelmän on tuettava uusien tuotteiden kehitystä, ylläpitoa ja lokalisointia. Seurannan toteutuksessa huomioitavat perusperiaatteet on lueteltu alla. Kaikkien virhetietojen on oltava samassa paikassa helposti kaikkien saatavissa. Kaikki ohjelmistossa olevat virheet on raportoitava ja mahdollisuuksien mukaan korjattava. Jotta turhalta työltä vältytään, virheet on voitava raportoida ja korjata vain kerran, mikä ei ole mahdollista, elleivät tiedot ole helposti haettavissa yhdestä paikasta. Erityyppiset virheet on voitava erottaa toisistaan tehokkaasti ja mahdollisimman yksikäsitteisesti. Kunkin virheen tila on oltava tiedossa kullakin hetkellä ja virheen korjaamisen edistymistä on voitava seurata. Tämän lisäksi virheiden korjaamiseen vaikuttaneet toimet ja niiden tekijä on oltava selkeästi näkyvissä. Kullekin virheelle on voitava määrittää henkilö/ryhmä, joka vastaa sen korjaamisesta. Tuotteen versio, jossa virhe esiintyy, on oltava tiedossa. Virhe on kuvattava siten, että siinä on kaikki ne tiedot, jotka tarvitaan sen toistamiseen, mieluiten siten, että virheen voi toistaa jopa ilman minkäänlaista ohjelmiston käyttökokemusta. Testausvaihe ja projektin vaihe, jolla virhe löydettiin, on yksilöitävä. Virheet on priorisoitava niiden vakavuuden ja korjaustarpeen mukaan, jota tiedetään, mihin virheisiin kehittäjien on keskityttävä ja mitkä virheet voidaan tarvittaessa jättää korjaamatta. Tietojen virheiden korjaamiseen käytetyistä keinoista on oltava samassa paikassa kuin itse virheen kuvaus, koska silloin tietoja voidaan käyttää apuna vastaavanlaisten virheiden korjaamisessa myöhemmin. 2
Raportointijärjestelmän on tuettava virheen korjauksen onnistumisen varmistamista: ei riitä, että virhe on merkitty korjatuksi vaan testauksen on myös varmistuttava siitä, että virhe on oikein korjattu. Eri testausvaiheissa löydetyt virheet on tallennettava myöhempää käyttöä varten, jotta tärkeimmät (vakavimmat) virheet voidaan tarkistaa uudelleen ennen palautuksia. 2. KÄYTETTÄVÄ VIRHERAPORTOINTIJÄRJESTELMÄ LiKe-projektissa käytettävä virheraportointijärjestelmä on kurssin Tik-76.115 Tietojenkäsittelyopin ohjelmatyö käytössä oleva Burana-virheraportointitietokanta. Tämä tietokanta täyttää edellä kohdassa 1.2.2 määritetyt vaatimukset, joten erillistä virheraportointijärjestelmää ei ole tarpeen luoda LiKe-projektia varten. Burana-järjestelmä on Web-pohjainen tietokanta, joka sijaitsee osoitteessa http://mordor.cs.hut.fi/tik-76.115/00-01/raportointi/burana/. Raportointijärjestelmään on kirjauduttava käyttäen projektin käyttäjätunnusta ja salasanaa. Järjestelmän omat käyttöohjeet ovat osoitteessa http://mordor.cs.hut.fi/tik-76.115/ohjeet/buranahelp.html. 3. VIRHERAPORTOINTIPROSESSI Seuraavassa on kuvattu virheraportointiin liittyvät prosessit pääpiirteissään. Eri vaiheissa tarvittava toiminta Burana-järjestelmän kannalta on kuvattu kohdassa 4. 3.1 KOSKA VIRHERAPORTTEJA LUODAAN? Virheraportteja voidaan luoda missä tahansa järjestelmäkehityksen vaiheessa, ja niiden luoja voi olla joku projektiryhmän jäsen, asiakas, opponenttiryhmän jäsen tai joku ulkopuolinen henkilö. Virheraportti luodaan tilanteessa, jossa käyttäjä havaitsee ohjelmassa virheen. Virhe on tilanne, jossa ohjelma ei käyttäydy odotetulla tavalla. Tämä odotettu tapa on ohjelman määrityksissä (vaatimusmäärittely, toiminnallinen määrittely tai tekninen määrittely) kuvattu tapa tietyn toiminnon toiminnasta. 3
On tärkeää huomata, että virheeksi käsitetään nimen omaan määritysten vastainen toiminta. Tämä erottaa virheraportin muutosehdotuksesta, johon Burana-järjestelmää voi myös käyttää: mikäli raportoitava virhe perustuu määrityksissä olevaan virheeseen, kyseessä ei ole ohjelmistossa oleva virhe vaan muutosehdotus, joka käsitellään muutosehdotusten käsittelyyn määritetyllä tavalla. Kuitenkin ennen määritysten hyväksymistä ja jäädyttämistä myös määrityksissä olevat virheet voidaan käsitellä virheinä eikä muutostenhakuprosessia tarvitse käyttää. Muutosten ja virheiden erottaminen määritysten ollessa lopulliset on kuitenkin tärkeää, jotta ohjelmiston kehityksessä voidaan keskittyä määritettyjen toimintojen toteuttamiseen oikein sen sijaan, että aikaa käytetään muutosehdotusten toteuttamiseen. Suurin osa virheraporteista syntyy todennäköisesti järjestelmän testauksen aikana. 3.2 TOIMINTA VIRHEEN LÖYDYTTYÄ Toiminta virheen löydyttyä jakaantuu neljään vaiheeseen, joista kukin käsitellään alla erikseen. 1. Varmistetaan, että kyseessä on virhe. Tämä tapahtuu ohjelmiston määrityksiä vasten. Jos ohjelman toiminta poikkeaa määritetystä toiminnasta, kyseessä on virhe, josta on luotava raportti. Mikäli virhe löytyy ohjelmiston testauksen aikana esim. jonkin testitapauksen perusteella, erillistä tarkistusta määrittelyihin ei tarvitse tehdä, sillä testitapaukset ja niiden odotetut tulokset on luotu ohjelmiston määrittelyjen perusteella. Mikäli kyseessä on muutosehdotus, noudatetaan tähän määritettyä prosessia. 2. Kun tiedetään, että kyseessä on raportoitava virhe, siirrytään Burana-järjestelmään. 3. Jotta voidaan varmistua, että löydettyä virhettä ei ole jo raportoitu, tehdään virhetietokantaan haku samankaltaisista virheistä. Mikäli virhe on jo raportoitu, jatkotoimenpiteisiin ei ryhdytä. Mikäli Buranasta löytyy samankaltainen virhe, mutta se ei vastaa täysin virheeseen johtanutta tilannetta, aiemmin luotua raporttia voidaan täydentää siten, että se kattaa myös uuden virhetilanteen. Tämä on mahdollista esim. silloin, jos järjestelmään on jo raportoitu virhe, joka on löydetty 4
jossain ympäristössä (esim. tiettyä selainohjelmaa käytettäessä), ja sama virhe toistuu myös jossain muussa ympäristössä. Tällöin aiempaa virheraporttia täydennetään tarvittavilla tiedoilla. Sama pätee kaikille virheille, ei vain avoimena oleville virheille: mikäli samankaltainen virhe on raportoitu aiemmin ja suljettu korjattuna, se avataan uudelleen, mikäli tähän on syytä. 4. Kun on varmistettu, että kyseessä on uusi aiemmin raportoimaton virhe, luodaan järjestelmään uusi virheraportti. Tämän jälkeen odotetaan, että virhe korjataan ja virheraportti voidaan sulkea. 3.3 VIRHEEN KORJAUSPROSESSI JA VIRHERAPORTIN SULKEMINEN 1. Kun kehittäjä havaitsee itselleen osoitetun virheen, hän ottaa virheraportin itselleen tarkasteltavaksi ja korjattavaksi. Mikäli kehittäjä tarvitsee lisätietoja virheen korjaamiseksi virheen kirjoittajalta, hän voi pyytää näitä lisätietoja Buranajärjestelmän avulla osoittamalla virheen takaisin sen kirjoittajalle. 2. Kun virhe on korjattu, kehittäjä/korjaaja merkitsee raportin korjatuksi. Raporttiin kirjoitetaan korjauksen kuvaus, koska tästä voi olla hyötyä myöhemmin vastaavia virheitä korjattaessa. 3. Virheraportin luoja tarkistaa, että virhe on korjattu, ja mikäli virhe on todella korjattu, hän merkitsee virheraportin käsitellyksi. Mikäli virhe ei ole korjattu, virhe osoitetaan uudelleen kehittäjälle mahdollisten lisätietojen kera. 3.4 VIRHEIDEN KATEGORISOINTI OHJELMISTON ERI OSIEN SUHTEEN Virheet on voitava kategorisoida ohjelmiston eri osien suhteen, jotta tiedetään, mihin toimintoon/moduuliin korjaus kannattaa kohdistaa. Kategorisoinnissa on lähdetty liikkeelle siitä, että virheiden raportoinnin on oltava asiakkaalle mahdollisimman helppoa. Näin ollen virheet jaotellaan taulukossa 1 esitettyihin kategorioihin, jotka perustuvat järjestelmän toimintojen tyyppeihin. 5
Taulukko 1. Virhekategoriat Kategoria Käyttöliittymä Selitys Ohjelmiston käyttöliittymään liittyvät toiminnot. Logiikka Tietokanta Ohjelmiston loogiset toiminnot, jotka eivät liity tietokantaan tai käyttöliittymään. Tietokantaan liittyvät toiminnot. Projektiryhmän sisäisessä virheraportoinnissa pyritään korkeampaan täsmällisyyden tasoon kuin yllä olevalla kategorisoinnilla on mahdollista saavuttaa. Tällöin virheraporttiin liitetään myös tieto moduulista/jsp-sivusta/komponentista, jossa virhe todennäköisesti sijaitsee. Asiakkaan kannalta ei ole kuitenkaan järkevää vaatia kategorisointia esim. moduulien perusteella, koska tämä johtaisi sekä virheraportoinnin hankaloitumiseen sekä mahdollisesti virheellisiin kategoriavalintoihin. Lisätiedot kirjoitetaan virheraportin Description-kenttään. 4. KÄYTÄNNÖN TOIMINTA BURANAA KÄYTTÄEN 4.1 BURANA-JÄRJESTELMÄSSÄ KÄYTETTÄVÄT KENTÄT JA NIIDEN MERKITYS Taulukossa 2 on esitetty Burana-järjestelmässä olevat kentät ja niiden käyttö LiKeprojektissa. Taulukko 2. Virheraportoinnissa käytettävät kentät Kenttä: Your name Your Organization Category of Selitys: Virheen luoneen henkilön nimi. Valitaan luettelosta. Käyttäjäryhmä: n jäsen, asiakas, tai opponenttiryhmän jäsen. Toiminto, johon virhe liittyy. Mahdolliset arvot tässä ovat: 6
Problem Projektitoiminnot Dokumenttitoiminnot Käyttäjätoiminnot Järjestelmään kirjautuminen Järjestelmänhallinta Käyttöliittymä Tiedonsiirto Tietokanta Web-palvelin Severity Virheen vakavuusaste: Minor: pienimerkityksinen virhe, joka ei haittaa järjestelmän käyttämistä tai joka voidaan ohittaa käyttämällä järjestelmää jollakin toisella tavalla. Normal: käyttöä häiritsevä virhe, joka ei kuitenkaan häiritse minkään kokonaisen toiminnon käyttämistä. Serious: virhe estää kokonaisen toiminnon/kokonaisten toimintojen käyttämisen. Critical: virhe, joka estää koko ohjelmiston käyttämisen (esim. järjestelmän kaatuminen tietyssä tilanteessa). Version/release Ohjelmiston versio, jossa virhe löydettiin Class Virheen tyyppi: Change request: muutosehdotus (ks. kohta 3.1) Documentation bug: virhe dokumentaatiossa (ei kuitenkaan määrittelyissä) Idea: kehitysajatus (ei virhe) Suggestion: ehdotus Support request: tukipyyntö (halutaan ohjeita jonkin toiminnon käyttämisestä) Software bug: oikea virhe (pääasiallisesti käytettävä luokka) Unknown: tuntematon; ei mikään yllä olevista vaan jonkin muun tyyppinen raportti Responsible Person Internal Priority Estimated effort Environment Synopsis Full Description Näistä käytetään vain Software bug- ja Change request vaihtoehtoja. Henkilö, jolle virhe osoitetaan käsiteltäväksi ja on kulloinkin vastuussa virheen käsittelemisestä. Aluksi testaaja osoittaa virheen sovelluksen vastuuhenkilölle, joka voi delegoida sen eteenpäin. Ratkaisemisen jälkeen virhe osoitetaan takaisin testaajalle suljettavaksi. Projektiryhmän tai asiakkaan määrittämä prioriteetti virheen korjaukselle. Määrittää, kuinka tärkeää virheen korjaaminen ja kuinka nopeasti sen olisi suotavaa tapahtua. Tätä ei tarvitse määrittää virheraporttia luotaessa. Arvio virheen korjaamiseen vaadittavasta työmäärästä (tunteina). Ei pakollinen. Ympäristö, jossa virhe havaittiin. Koneen laitteiston ja ohjelmistojen kuvaus. Vähintään koneen käyttöjärjestelmä ja käytetty selain kielitietoineen. Laitteistotietoja ei tarvita, sillä ohjelmiston toiminta ei riipu merkittävästi laitteistossa. Raportin otsikko, tiivis kuvaus virheestä. Testaajan tai virheen raportoijan kirjoittama yksityiskohtainen kuvaus siitä, miten virhe voidaan toistaa. Vaiheittainen toimintaohje siitä, mikä 7
sovellus käynnistetään, mitä valintoja valikoista tehdään ja mitä valintaikkunoihin syötetään. Virheen ratkaisemisen yhteydessä kenttään lisätään tietoa siitä, miten ja missä tiedostossa virhe korjattiin tai selitys miksi sitä ei korjata. Kentän avulla voidaan käydä tarkentavaa vuoropuhelua testaajien ja ohjelmistoinsinöörin (kehittäjä) välillä. How Can We Repeat This Problem? Suggested Fix Tarkat toisto-ohjeet, jos ei ole jo kuvattu Description-kentässä. Ehdotus virheen korjaamiseksi (jos sellainen on). Ei pakollinen. 4.2 VIRHEIDEN TILOJEN KUVAUKSET Raportointijärjestelmässä olevien virheiden tilat ja niiden kuvaukset on esitetty taulukossa 3. Taulukko 3. Virheraporttien tilat Tila Open Pending Analyzing Working Testing Suspended Closed Selitys Avoin virheraportti, joka odottaa korjaamista. Korjatuksi merkitty virheraportti, joka odottaa testaajan/virheen avaajan tarkistusta virheen korjauksesta. Ei käytetä. Virheraportti on korjausta varten vastuullisen kehittäjän käsiteltävänä. Ei käytetä Tila, johon virheelliseksi todettu virheraportti asetetaan. Tämän kuvaus voisi olla Not a bug. Virheraportti on suljettu, koska sen korjaus on verifioitu. 8
4.3 TYYPILLISET TOIMINNOT JA NIIDEN SUORITTAMINEN BURANASSA 4.3.1 Uuden virheen avaaminen Siirrytään Burana-järjestelmään ja luodaan uusi virheraportti täyttämällä tarvittavat kentät taulukon 2 mukaisesti. Tätä ennen etsitään järjestelmästä sen etsintätoimintojen ja virhettä kuvaavien sanojen perusteella, että samaa virhettä ei ole jo avattu. 4.3.2 Virheen tarkasteleminen Joko etsitään haluttua asiaa käsittelevä virhe hakutoiminnon avulla tai siirrytään suoraan tiettyyn virheraporttiin (jos sen numero on tiedossa). 4.3.3 Virheen ottaminen korjattavaksi Siirrytään käsiteltäväksi otettavaan virheeseen ja vaihdetaan sen tilaksi Working. 4.3.4 Virheen merkitseminen korjatuksi Merkitään halutun virheen tilaksi Pending ja osoitetaan se takaisin virheen avanneelle ihmiselle vaihtamalla virheen Responsible Person kentän arvo. Oletusarvoisesti virheet osoitetaan ensin projektipäällikölle, joka sitten osoittaa ne vastuulliselle ohjelmoijalle. 4.3.5 Virheen korjauksen tarkistaminen ja sulkeminen tai avaaminen uudelleen Siirrytään haluttuun virheraporttiin ja vaihdetaan sen tilaksi Closed, mikäli virhe on todella korjattu, sekä osoitetaan virhe projektipäällikölle. Mikäli virhettä ei ole korjattu, muutetaan sen tilaksi Open ja osoitetaan se takaisin virheen korjaajalle. 9