Vanha sivusto

Tämä on vanha itQ.fi-sivusto, ja sisällön ylläpitäminen sille on lopetettu. itQ siirtyi WordPress-alustalle 6.6.2015.

maanantai 17. maaliskuuta 2014

Näin raportoit bugista, tavis

Oh­jel­mis­to­vir­heet eli bu­git ovat usein är­syt­tä­viä. Löy­tä­mäs­tään bu­gis­ta kan­nat­taa ker­toa seik­ka­pe­räi­ses­ti oh­jel­man te­ki­jäl­le, jot­ta vi­ka voi­daan kor­ja­ta.

Kuva: gotsumbeers: Broken Computer- Day 273. c nd 2.0
Jokaiselle on varmasti joskus käynyt niin, että työpöytä- tai websovellus "sekoaa" kesken käytön: ruudulle hyppii kryptisiä virheilmoituksia, toiminto aiheuttaa väärän lopputuloksen, ohjelma kaatuu vieden tallentamattomat työt mennessään... Käyttäjän kiusaajana on tällöin bugi eli ohjelmointivirhe.

Olen huomannut, että bugin osuessa omalle kohdalle suurin osa ihmisistä hakkaa päätä seinään, ja aloittaa alusta toivoen parempaa lopputulosta. Toiset taas kysyvät kaverilta apua, ja jos sekään ei auta, ottavat yhteyttä yrityksensä IT-tukeen tai ohjelmiston valmistajaan.

Havaitut ongelmat kannattaa aina raportoida eteenpäin, jotta ohjelmiston kehittäjä voi ne ratkaista. Yleensä oikea osoite on ohjelmiston valmistaja, mutta töissä on kannattavampaa lähestyä omaa IT-tukea. Yhteydenotto kannattaa tehdä kirjallisesti (eli sähköpostitse) ja huolella. Ohjelmiston kehittäjät eivät näet ole selvänäkijöitä tai velhoja, vaan tarvitsevat runsaasti tietoa voidakseen paikantaa ja korjata vian. "Tää ei toimi", "Siihen tuli joku ilmoitus" ja "Korjaa toi" -tyyppiset viestit kirvoittavat − vastaanottajan mielentilasta riippuen − joko ilkeämielistä naurua tai ärräpäitä.

Bugi-ilmoituksesta pitäisi selvitä neljä asiaa:
  1. Käyttöympäristö: Millä laitteella1 ongelma tapahtui? Mikä käyttöjärjestelmä2 siinä on? Mikä versio3 ohjelmistosta on käytössä?
  2. Toisto-ohjeet: Seikkaperäinen vaiheittainen kuvaus siitä mitä teit, ennen kuin ongelma ilmeni.
  3. Lopputulos: Mitä tapahtui edellisten vaiheiden tekemisen jälkeen? Virheilmoitusten sisältö kannattaa kertoa sanatarkasti. Myös kuvakaappaus havainnollistaa usein tilannetta.
  4. Haluttu lopputulos: Mitä olisi pitänyt tapahtua?
Esimerkiksi4:
Hei.

Yritin tänään avata CSV-muotoista tiedostoa Microsoft Office 2010 Excelillä. Käytössäni on pöytäkone, jossa on suomenkielinen Windows 7. Taulukko avautuu kyllä, mutta koko rivin sisältö on aina kunkin rivin ensimmäisessä solussa. Rivin sisällön pitäisi jakautua usealle sarakkeelle. Tiedostoa käsitellessä ei tule virheilmoituksia.

Ystävällisin terveisin,
Erkki Esimerkki
Vastaanottaja käsittelee viestisi, ja arvioi korjaustarpeen. Tyypillisesti bugin status voidaan jakaa johonkin seuraavista lokeroista:
  • Korjattava: Ohjelmiston kehittäjä on tunnistanut vian ja aikoo korjata sen5.
  • Toimii suunnitellusti: Olet ymmärtänyt jonkin toiminnon väärin, eli saavuttamasi lopputulos on oikea.
  • Tarvitaan lisätietoja: Viankuvaustasi täytyy tarkentaa, jotta ohjelmistokehittäjä voi paikallistaa virheen.
  • Ei voida toistaa: Virhettä ei pystytty toistamaan ohjeittesi mukaan. Tällaisia vikoja on hankala korjata, ja ne saattavat jopa olla lähtöisin muualta kuin ohjelmistosta itsestään6.
  • Ei korjata: Kehittäjä ei näe korjaamista järkeväksi. Se saattaa esimerkiksi esiintyä vain vanhentuneessa versiossa, tai koskea vain marginaalista osaa käyttäjistä.
Kannattaa myös varautua siihen, että joudut vastailemaan erilaisiin jatkokysymyksiin, jotta virhe voidaan paikallistaa. Paikallistaminen − saatikka sitten virheen korjaaminen7 − saattaakin sitten kestää, eikä hoputus yleensä auta. Henkeä ei siis kannata varsinaisesti pidätellä.

Parhaassa tapauksessa bugi kuitenkin ennen pitkää korjataan, ja loppukäyttäjän − sinun − elämäsi helpottuu. Turhaa ajanhukkaa virheiden ilmoittaminen siis ei ole, mutta huolellinen siinä kannattaa olla.

--
1) Yrityksen IT-tuki arvostaa koneen laitenimeä, muuten riittää laitteen tyyppi (kannettava, tabletti, kännykkä, pöytäkone).
2) Kannattaa olla niin tarkka kuin osaa.
3) Myös ohjelmiston kieli on hyvä mainita, jos ohjelmistosta on useita kieliversioita.
4) Tässä tietoja on vielä suppeahkosti. Enemmänkin kannattaisi kertoa, jotta välttyisi jatkokysymyksiltä.
5) Korjaus tulee ennen pitkää. Toiminnan kannalta kriittiset bugit korjataan nopeammin kuin marginaalista käyttäjäryhmää haittaavat pikkuongelmat.
6) Esim. viallisesta laitteistosta.
7) Hiukankin "ammattimaisemmissa" ohjelmistoissa muutoksia ei tehdä sormia napsauttamalla, vaan ne vaativat varsinaisen koodailun lisäksi mm. testausta ja erilaisia hyväksyntöjä.

Ei kommentteja :