Miksi hyvä vikailmoitus?

Jos vikailmoituksesi on tehokas, sen korjausmahdollisuudet ovat paremmat. Virheen korjaaminen riippuu siis siitä, kuinka tehokkaasti raportoit siitä. Vikailmoitus ei ole mitään muuta kuin taito, ja selitän, miten tämä taito saavutetaan.

”Ongelmaraportin (vikailmoituksen) kirjoittamisen tarkoitus on saada virheet korjattua.” – By Cem Kaner. Jos testaaja ei raportoi virheestä oikein, ohjelmoija todennäköisesti hylkää tämän virheen todeten sen korjauskelvottomaksi.

Tämä voi loukata testaajan moraalia ja joskus myös egoa. (Suosittelen olemaan pitämättä minkäänlaista egoa. Egoja kuten ”Olen raportoinut vian oikein”, ”Voin toistaa sen”, ”Miksi hän hylkäsi vian?”, ”Se ei ole minun vikani” jne.,).”

Mitä ominaisuuksia hyvällä ohjelmistovikaraportilla on?

Kuka tahansa voi kirjoittaa vikaraportin. Mutta kaikki eivät osaa kirjoittaa tehokasta vikaraporttia.

Sinun pitäisi pystyä erottamaan keskiverto vikaraportti hyvästä vikaraportista. Miten erottaa hyvä ja huono vikaraportti toisistaan? Se on hyvin yksinkertaista, sovella seuraavia ominaisuuksia ja tekniikoita vikailmoitukseen.

Ominaisuuksiin ja tekniikoihin kuuluvat

#1) On selkeästi määritetty vikanumero: Anna jokaiselle vikailmoitukselle aina yksilöllinen numero. Tämä puolestaan auttaa sinua tunnistamaan vikailmoituksen. Jos käytät jotain automatisoitua vikailmoitustyökalua, tämä yksilöllinen numero luodaan automaattisesti joka kerta, kun ilmoitat vikailmoituksen.

Merkitse numero ja lyhyt kuvaus jokaisesta ilmoittamastasi virheestä.

#2) Toistettavuus: Jos vikasi ei ole toistettavissa, sitä ei koskaan korjata.

Mainitse selkeästi vaiheet, joilla vika voidaan toistaa. Älä oleta tai ohita mitään toistovaihetta. Vika, joka on kuvattu vaihe vaiheelta, on helppo toistaa ja korjata.

#3) Ole tarkka: Älä kirjoita esseetä ongelmasta.

Ole tarkka ja ytimekäs. Yritä tiivistää ongelma mahdollisimman vähin sanoin mutta tehokkaasti. Älä yhdistä useita ongelmia, vaikka ne vaikuttaisivat samankaltaisilta. Kirjoita eri raportit jokaisesta ongelmasta.

Tehokas vikailmoitus

Vikailmoitus on tärkeä osa ohjelmistotestausta. Tehokkaalla vikaraportilla kommunikoidaan hyvin kehitystiimin kanssa ja vältetään sekaannukset ja väärinkäsitykset.

Hyvän vikaraportin tulee olla selkeä ja ytimekäs, eikä siitä saa puuttua keskeisiä kohtia. Selkeyden puute johtaa väärinkäsityksiin ja hidastaa myös kehitysprosessia. Virheiden kirjoittaminen ja raportointi on yksi tärkeimmistä mutta laiminlyötyistä osa-alueista testauksen elinkaaressa.

Hyvä kirjoittaminen on erittäin tärkeää vikailmoituksen tekemisessä. Tärkein seikka, joka testaajan tulisi pitää mielessä, on se, ettei raportissa käytetä käskevää sävyä. Tämä rikkoo moraalia ja luo epäterveen työsuhteen. Käytä vihjailevaa sävyä.

Älä oleta, että kehittäjä on tehnyt virheen ja siksi voit käyttää kovia sanoja. Ennen raportointia on yhtä tärkeää tarkistaa, onko samasta virheestä jo raportoitu vai ei.

Kaksinkertainen virhe on rasite testaussyklissä. Tarkista koko tunnettujen vikojen luettelo. Toisinaan kehittäjät ovat saattaneet tietää ongelman ja jättää sen huomiotta tulevaa julkaisua varten. Myös Bugzillan kaltaisia työkaluja, jotka etsivät automaattisesti päällekkäisiä vikoja, voidaan käyttää. On kuitenkin parasta etsiä manuaalisesti kaikki päällekkäiset viat.

Vikailmoituksessa on kerrottava seuraavat tärkeät tiedot: ”Miten?” ja ”Missä?”. Raportin tulee vastata selkeästi, miten testi suoritettiin ja missä vika tarkalleen ottaen ilmeni. Lukijan tulisi helposti toistaa vika ja löytää, missä vika on.

Pitäkää mielessä, että vikaraportin kirjoittamisen tavoitteena on antaa kehittäjälle mahdollisuus hahmottaa ongelma. Hänen tulisi ymmärtää vika selkeästi vikaraportista. Muista antaa kaikki olennaiset tiedot, joita kehittäjä etsii.

Muista myös, että vikaraportti säilytetään tulevaa käyttöä varten, ja sen tulisi olla hyvin kirjoitettu ja sisältää tarvittavat tiedot. Käytä mielekkäitä lauseita ja yksinkertaisia sanoja kuvaillessasi vikoja. Älä käytä sekavia lauseita, jotka tuhlaavat tarkastajan aikaa.

Raportoi jokainen virhe erillisenä ongelmana. Jos yhdessä vikailmoituksessa on useita ongelmia, et voi sulkea sitä, ellei kaikkia ongelmia ole ratkaistu.

Siten on parasta jakaa ongelmat erillisiksi vikoiksi. Näin varmistetaan, että jokainen vika voidaan käsitellä erikseen. Hyvin kirjoitettu vikailmoitus auttaa kehittäjää toistamaan vian päätelaitteellaan. Tämä auttaa heitä myös diagnosoimaan ongelman.

Miten vikailmoitus tehdään?

Käytä seuraavaa yksinkertaista vikailmoitusmallia:

Tämä on yksinkertainen vikailmoitusmuoto. Se voi vaihdella käyttämästäsi vikailmoitustyökalusta riippuen. Jos kirjoitat vikailmoituksen manuaalisesti, jotkin kentät on mainittava erikseen, kuten vian numero, joka on annettava manuaalisesti.

Raportoija: Nimesi ja sähköpostiosoitteesi.

Tuote:

Versio: Tuotteen versio, jos sellainen on.

Component:

Platform: Mainitse laitteistoalusta, jolla löysit tämän virheen. Eri alustat, kuten ’PC’, ’MAC’, ’HP’, ’Sun’ jne.

Käyttöjärjestelmä: Mainitse kaikki käyttöjärjestelmät, joista löysit vian. Käyttöjärjestelmät kuten Windows, Linux, Unix, SunOS, Mac OS. Mainitse tarvittaessa myös eri käyttöjärjestelmäversiot, kuten Windows NT, Windows 2000, Windows XP jne.

Prioriteetti: Milloin vika pitäisi korjata? Prioriteetti asetetaan yleensä P1:stä P5:een. P1 tarkoittaa ”korjaa vika, jolla on korkein prioriteetti” ja P5 tarkoittaa ” Korjaa, kun aika sallii”.

Severity: Tämä kuvaa virheen vaikutusta.
Types of Severity:

• Esto: Testaustyötä ei voida enää tehdä.
• Kriittinen: Sovelluksen kaatuminen, tietojen menetys.
• Vakava: Merkittävä toimintojen menetys.
• Minor: Minor loss of function.
• Trivial: Some UI enhancements.
• Enhancement: Pyyntö uudesta ominaisuudesta tai jo olemassa olevan ominaisuuden parantamisesta.

Status:

=> Klikkaa tästä lukeaksesi lisää yksityiskohtaisesta bugin elinkaaresta.

Assign To: Kun kirjaat bugin mihinkään buginseurantajärjestelmään, bugin tila on oletusarvoisesti ’Uusi’.
Myöhemmin bugi käy läpi eri vaiheita, kuten Korjattu, Tarkistettu, Uudelleen avattu, Ei korjata jne: Jos tiedät, kuka kehittäjä on vastuussa kyseisestä moduulista, jossa vika ilmeni, voit määrittää kyseisen kehittäjän sähköpostiosoitteen. Muussa tapauksessa pidä kenttä tyhjänä, sillä tämä määrittää vian moduulin omistajalle, jos ei, Manager määrittää vian kehittäjälle. Lisää mahdollisesti managerin sähköpostiosoite CC-luetteloon.

URL: Sivun URL-osoite, jossa vika ilmeni.

Summary: Lyhyt yhteenveto virheestä useimmiten 60 sanalla tai alle. Varmista, että tiivistelmäsi heijastaa sitä, mikä ongelma on ja missä se on.

Description: Yksityiskohtainen kuvaus viasta.

Käytä seuraavia kenttiä kuvauskenttään:

• Toista vaiheet: Mainitse selkeästi vaiheet virheen toistamiseksi.
• Odotettu tulos: Miten sovelluksen pitäisi käyttäytyä edellä mainituissa vaiheissa.
• Todellinen tulos: Mikä on edellä mainittujen vaiheiden suorittamisen todellinen tulos eli vian käyttäytyminen.

Nämä ovat vikailmoituksen tärkeät vaiheet. Voit myös lisätä ”Raportin tyyppi” -kentän, joka kuvaa vian tyyppiä.

Raporttityyppejä ovat:

1) Koodausvirhe
2) Suunnitteluvirhe
3) Uusi ehdotus
4) Dokumentointiongelma
5) Laitteisto-ongelma

Tärkeitä ominaisuuksia vikailmoituksessasi

Alhaalla on lueteltu vikailmoituksen tärkeät ominaisuudet:

#1) Vian numero/id

Vian numero tai tunnistenumero (kuten swb001) helpottaa vikailmoitusta ja vikaan viittaamista huomattavasti. Kehittäjä voi helposti tarkistaa, onko tietty vika korjattu vai ei. Se tekee koko testaus- ja uudelleentestausprosessista sujuvampaa ja helpompaa.

#2) Vian otsikko

Vian otsikko luetaan useammin kuin mikään muu vikailmoituksen osa. Sen pitäisi kertoa kaikki siitä, mitä vikailmoitukseen tulee.

Vikailmoituksen otsikon pitäisi olla tarpeeksi vihjaileva, jotta lukija voi ymmärtää sen. Selkeä vian otsikko tekee siitä helposti ymmärrettävän ja lukija voi tietää, onko vika raportoitu aiemmin tai onko se korjattu.

#3) Prioriteetti

Vian vakavuuden perusteella sille voidaan asettaa prioriteetti. Vika voi olla estävä, kriittinen, merkittävä, vähäinen, triviaali tai ehdotus. Vikaprioriteetti voidaan antaa P1:stä P5:een, jotta tärkeät virheet nähdään ensin.

#4) Alusta/Ympäristö

Käyttöjärjestelmän ja selaimen konfiguraatio on välttämätön selkeän vikailmoituksen saamiseksi. Se on paras tapa kertoa, miten vika voidaan toistaa.

Ilman tarkkaa alustaa tai ympäristöä sovellus voi käyttäytyä eri tavalla, eikä testaajan päässä oleva vika välttämättä toistu kehittäjän päässä. Siksi on parasta mainita selvästi ympäristö, jossa vika havaittiin.

#5) Kuvaus

Vian kuvaus auttaa kehittäjää ymmärtämään vian. Siinä kuvataan kohdattu ongelma. Huono kuvaus aiheuttaa sekaannusta ja tuhlaa kehittäjien ja myös testaajien aikaa.

Kuvauksen vaikutuksesta on viestittävä selkeästi. On aina hyödyllistä käyttää kokonaisia lauseita. On hyvä käytäntö kuvata jokainen ongelma erikseen sen sijaan, että ne murennetaan yhteen. Älä käytä ilmaisuja kuten ”luulen” tai ”uskon”.

#6) Toistamisen vaiheet

Hyvässä vikailmoituksessa tulisi mainita selkeästi toistamisen vaiheet. Vaiheiden tulisi sisältää toimet, jotka aiheuttavat vian. Älä tee yleisiä lausuntoja. Ole tarkka vaiheissa.

Hyvä esimerkki hyvin kirjoitetusta menettelystä on alla

Vaiheet:

• Valitse tuote Abc01.
• Klikkaa Lisää koriin.
• Klikkaa Poista poistaaksesi tuotteen ostoskorista.

#7) Odotettu ja todellinen tulos

Vikakuvaus on epätäydellinen ilman odotettuja ja todellisia tuloksia. On tarpeen hahmotella, mikä on testin tulos ja mitä käyttäjän tulisi odottaa. Lukijan tulee tietää, mikä on testin oikea lopputulos. Mainitse selkeästi, mitä testin aikana tapahtui ja mikä oli lopputulos.

#8) Kuvakaappaus

Kuva kertoo enemmän kuin tuhat sanaa. Ota kuvakaappaus vikatapauksesta, jossa on asianmukainen kuvateksti, joka korostaa vikaa. Korosta odottamattomat virheilmoitukset vaaleanpunaisella värillä. Tämä kiinnittää huomion tarvittavaan alueeseen.

Joitakin lisävihjeitä hyvän vikaraportin kirjoittamiseen

Alhaalla on vielä lisävihjeitä hyvän vikaraportin kirjoittamiseen:

#1) Ilmoita ongelmasta heti

Jos havaitset vian testauksen aikana, sinun ei tarvitse odottaa yksityiskohtaisen vikaraportin kirjoittamista myöhemmin. Sen sijaan kirjoita vikailmoitus heti. Näin varmistat hyvän ja toistettavissa olevan vikaraportin. Jos päätät kirjoittaa vikaraportin myöhemmin, on suuri todennäköisyys, että tärkeitä vaiheita jää raportistasi huomaamatta.

#2) Toista vika kolme kertaa ennen vikaraportin kirjoittamista

Vikaraporttisi tulisi olla toistettavissa. Varmista, että vaiheesi ovat tarpeeksi vankkoja, jotta vika voidaan toistaa ilman epäselvyyksiä. Jos vikasi ei ole joka kerta toistettavissa, voit silti tehdä vikailmoituksen, jossa mainitaan vian ajoittainen luonne.

#3) Testaa saman vian esiintyminen muissa samankaltaisissa moduuleissa

Joskus kehittäjä käyttää samaa koodia eri samankaltaisissa moduuleissa. Näin ollen on suurempi mahdollisuus, että yhdessä moduulissa esiintyvä vika esiintyy myös muissa samankaltaisissa moduuleissa. Voit jopa yrittää löytää vakavamman version löytämästäsi bugista.

#4) Kirjoita hyvä bugin yhteenveto

Bugin yhteenveto auttaa kehittäjiä analysoimaan nopeasti bugin luonnetta. Huonolaatuinen raportti lisää tarpeettomasti kehitys- ja testausaikaa. Kommunikoi hyvin vikaraporttisi yhteenvedossa. Muista, että vikayhteenvetoa käytetään viitteenä vian etsimisessä vikaluettelosta.

#5) Lue vikailmoitus ennen Lähetä-painikkeen painamista

Lue kaikki vikailmoituksessa käytetyt lauseet, sanamuodot ja vaiheet. Katso, aiheuttaako jokin lause epäselvyyttä, joka voi johtaa väärintulkintaan. Harhaanjohtavia sanoja tai lauseita tulisi välttää, jotta vikailmoitus olisi selkeä.

#6) Älä käytä loukkaavaa kieltä

On mukavaa, että teit hyvää työtä ja löysit bugin, mutta älä käytä tätä krediittiä kehittäjän arvostelemiseen tai hyökkäämiseen ketään henkilöä vastaan.

Johtopäätös

Ei ole epäilystäkään siitä, että vikaraporttisi pitäisi olla laadukas dokumentti.

Keskity hyvien vikaraporttien kirjoittamiseen ja käytä aikaa tähän tehtävään, koska se on tärkein kommunikaatiokohta testaajan, kehittäjän ja johtajan välillä. Johtajien tulisi luoda tiimilleen tietoisuus siitä, että hyvän vikaraportin kirjoittaminen on jokaisen testaajan ensisijainen vastuu.