Kuinka kirjoittaa virheraportti (+ ilmainen mallipohja ladattavaksi)

Tehokkaan vikailmoituksen laatiminen on tärkeä osa ohjelmistotestaajan työtä laadunvarmistuksen ylläpitämiseksi, joten käytämme paljon aikaa vikojen kirjaamiseen vikaseurantatyökaluihimme. Vian löytäminen voi tuntua jännittävältä, etenkin jos kyseessä on kiinnostava tilanne. Sen raportointitapa voi kuitenkin olla yhtä tärkeä kuin sen vaikutus järjestelmään.

Huonosti kirjoitettu vikailmoitus voi aiheuttaa paljon kitkaa tiimin jäsenten, erityisesti testaajien ja kehittäjien, välille. Tämä voi estää vikojen korjaamista ja lopulta heikentää käyttäjäkokemusta.

Tässä artikkelissa jaan olennaisia tietoja esimerkiksi siitä, miten:

• Hallitset vikailmoitukset: Opit keskeiset elementit, jotka jokaisen tehokkaan vikailmoituksen tulisi sisältää, jotta viestintä tehostuu ja korjaukset nopeutuvat.
• Parannat tiimihenkeä: Saat selville, miten hyvin kirjoitetut vikailmoitukset ehkäisevät testaajien ja kehittäjien välistä kitkaa ja johtavat sujuvampiin työnkulkuihin.
• Ilmainen ladattava mallipohja: Hanki ilmainen ladattava vikaseurannan mallipohja tehokkaan vikailmoitusprosessin käynnistämiseen.

Vikailmoituksen keskeiset elementit

Riippumatta testaamasi sovelluksen tyypistä – olipa kyseessä työpöytäsovellus, verkkosovellus, mobiilisovellus tai API-projekti – jokaisen hyvän vikailmoituksen tulisi sisältää tietyt keskeiset elementit. Useimmat vikaseurantaohjelmistot tarjoavat kentät näille elementeille, kuten:

• ID: Jos käytät projektinhallintatyökalua, kuten Jiraa, jokaiselle avatulle uudelle ongelmalle määritetään automaattisesti tunnus. Saatavilla on myös Jiran testienhallintatyökaluja vikaseurantaan
• Otsikko/kuvaus: Tämä on lyhyt kuvaus ongelmasta. Sen tulee olla riittävän ytimekäs, jotta se on helppo lukea, mutta samalla riittävän kuvaileva, jotta muut ymmärtävät, missä ongelma piilee. Esimerkiksi ”kohteiden lajittelu hinnan mukaan ei toimi, kun suodatin on käytössä.” 
• Toistamisen vaiheet: Sisällytä tähän mahdollisimman paljon olennaisia tietoja. Varmista, että kuka tahansa, joka yrittää toistaa ongelman tai varmistaa korjauksen, pystyy tekemään sen seuraamalla vaiheita. Älä jätä vaiheita väliin olettaen, että kaikki tietävät ilman eri mainintaa, että tietyt toimet on suoritettava; sisällytä ne vikailmoitukseen. 
• Odotetut tulokset: Älä taaskaan oleta, että ihmiset tietävät jo, miten sovelluksen pitäisi toimia. Jos käyttöliittymässä ilmenee poikkeus painiketta painettaessa, tiedät tietenkin, ettei sitä odoteta. En kuitenkaan sanoisi odotetuksi tulokseksi ”poikkeusta ei heitetä”, vaan kuvaisin mieluummin, minkä toiminnon painikkeen pitäisi suorittaa, esimerkiksi ”asetusikkuna avautuu.”
• Todelliset tulokset: Tämä on itsestään selvää – kuvaile, mitä sovelluksessa tapahtuu, kun kaikki toistamisen vaiheet on suoritettu.
• Vakavuus: Tämä kuvaa vian vaikutusta AUT:hen.
• Prioriteetti: Kuinka nopeasti vika tulisi korjata. Korkeampi prioriteetti tarkoittaa, että vika tulisi sijoittaa työjonossa korkeammalle ja korjata aiemmin.

Muita tärkeitä sisällytettäviä tietoja 

Edellä mainittujen elementtien lisäksi myös muut tiedot voivat olla olennaisia, erityisesti kun tietoja syötetään vikailmoitustyökaluun. Ne voivat riippua projektin tyypistä, projektin vaatimuksista tai jopa itse viasta:

• Ohjelmistoversio: Koontiversion numero, jossa vika tunnistettiin. Tämä voi auttaa rajaamaan koontiversiot, joissa ongelma mahdollisesti syntyi, ja tunnistamaan sen aiheuttaneen koodin.

• Liitteet: Niitä ei välttämättä aina tarvita tai ne eivät ehkä ole saatavilla, mutta niistä on yleensä paljon hyötyä. Harkitse ongelmasta otettujen kuvakaappausten tai tallenteiden, lokitiedostojen, pinonjäljitysten, verkkopyyntöjen ja -vastausten sekä muiden vastaavien tietojen toimittamista. 
• Testitiedot: Joskus löytämämme viat toistuvat vain tiettyjen tietojoukkojen yhteydessä. Jos näin on, muista sisällyttää ne joko toistamisen vaiheisiin (esimerkiksi ”kirjaudu sisään käyttäjänä andreea@theqalead.com”) tai vikaseurantatyökalun erilliseen kenttään.
• Ympäristön tiedot: Jos vika toistuu vain tietyssä käyttöjärjestelmässä, selaimessa tai kehitysympäristössä, mainitse se.  

Vinkkejä hyvän vikailmoituksen laatimiseen

• Rajoita raporttisi koskemaan vain yhtä bugia. Jos löydät samoilta alueilta lisää bugeja, voit linkittää ne tehtävien seurantajärjestelmääsi. Useamman kuin yhden vian sisällyttäminen voi aiheuttaa sekaannusta ja viivästyttää mahdollisia bugikorjauksia.
• Tarkista seurantajärjestelmästäsi, ettei bugia ole jo ilmoitettu. Jos se on jo avattu, lisää kaikki löytämäsi olennaiset tiedot, joita ei toimitettu alkuperäiseen bugiraporttiin.
• Yritä toistaa bugi useammin kuin kerran. Voit yrittää löytää lyhimmän tavan toistaa sen eli käyttää mahdollisimman vähän vaiheita.
• Älä eksy epäolennaisiin yksityiskohtiin. Bugiraportin ja vaiheiden tulisi olla helppolukuisia ja helposti seurattavia.
• Älä tee oletuksia siitä, miksi bugi ilmenee (ellet ole täysin varma, että tiedät, mikä sen aiheutti).

Bugiraportin malli

Nyt haluan jakaa kanssasi muutamia bugiraporttimalleja. Voit kopioida tai muokata niitä projektisi tarpeiden mukaan.

Jiran bugiseurannan malli

Jira on Atlassianin erittäin yleinen tehtävien seurantatyökalu. Jos tiimisi käyttää sitä, bugitehtävätyyppi on todennäköisesti jo määritetty. Testaajana tai ohjelmistokehitystiimin johtajana voit määrittää bugien elinkaaren bugiseurannan työnkulun (tämä ominaisuus on yksi monista tehtävien seurantaohjelmistojen hyödyistä). 

Voit myös lisätä Jiraan mukautettuja kenttiä, esimerkiksi ympäristöä varten tai yksilöllisen kentän, johon lisätään testattu toiminnallisuus. Voit myös lisätä oletuskuvauksen, joka sisältää kaikki tiedot, jotka haluat sisällyttää jokaiseen bugiraporttiin. Tässä on luomani esimerkki:

Kun haluan nyt luoda uuden bugin, nämä tiedot ovat valmiiksi täytettyinä. Tässä on Jiran bugimallini, jossa käytetään mukautettuja kenttiä ja oletuskuvausta:

Se sisältää tärkeät tiedot, jotka bugiraporttiin tulee sisällyttää:

• Otsikko (”Esimerkkibugi”)
• Kuvauksessa esitiedot, toistamisen vaiheet sekä odotetut ja todelliset tulokset
• Mukautettu ympäristökenttä
• Vakavuus ja prioriteetti, jotka valitaan ennalta määritettyjä arvoja sisältävistä pudotusvalikoista
• Jätin vastuuhenkilön tyhjäksi. Projektisi käytännöistä riippuen uudet bugit voidaan määrittää automaattisesti tietylle tiimin jäsenelle, tai työn aloittava henkilö voi määrittää sen itselleen
• Tunniste – tästä voi olla hyötyä esimerkiksi silloin, kun haluat seurata, mihin toiminnallisuuteen vaikutus kohdistuu
• Määräpäivä – tehtävää ei välttämättä voida suorittaa ennen kuin työlista on priorisoitu
• Ilmoittaja (tässä tapauksessa kenttä täytetään automaattisesti bugion luoneen Jira-käyttäjän tiedoilla)

Jirassa on myös useita valinnaisia integraatioita, ja bugi voidaan linkittää testitapauksiin, Git-haaroihin tai jopa yhdistämispyyntöihin.

Voit myös käyttää heidän bugiseurannan malliaan projektimallina, jos tarvitset Jiraa vain vikojen seurantaan etkä työskentele ketterässä ympäristössä.

Excelin bugiseurannan malli

Jotkin tiimit saattavat käyttää taulukoita bugiseurantajärjestelmänään. Mielestäni ne ovat hyödyllisiä hyvin pienissä projekteissa, joissa tehtävien seurantatyökalun käyttöönotto ei yksinkertaisesti ole vaivan arvoista, tai uusien, vielä kehitysvaiheessa olevien ominaisuuksien bugien ilmoittamiseen. 

Voit käyttää Google Sheetsia/Docseja tai Microsoft Exceliä/Wordia – joka tapauksessa bugimalli voi näyttää tältä:

Sarakkeet kuvaavat tietoja, jotka raportin tulisi sisältää:

• Tunnus (Excel osaa kasvattaa arvoa automaattisesti aina, kun uusi rivi lisätään)
• Otsikko
• Toistamisen vaiheet
• Odotetut ja toteutuneet tulokset
• Ilmoittajan nimi
• Vakavuus ja virheen prioriteetti—tässä käytin avattavia valikoita, koska arvot pitäisi määrittää etukäteen
• Ympäristö
• Lisätiedot: Tämä on tarkoitettu kaikelle muulle mainitsemisen arvoiselle, joka ei sovi muihin sarakkeisiin

Lopuksi

Hyvän ohjelmistovirheraportin kirjoittaminen on ohjelmistotestaajille olennainen taito, joten kiinnitä erityistä huomiota edellä selitettyihin parhaisiin käytäntöihin. Voit myös hyödyntää tarjoamiani esimerkkejä virheseurannan mallipohjista. Niitä voi muokata käyttämiesi eri työkalujen, kuten Trellon tai Asanan, tarpeisiin.

Jos pidit tästä sisällöstä, tilaa The QA Lead -uutiskirje pysyäksesi ajan tasalla ohjelmistotestausprosessin uusimmista uutisista ja trendeistä!