How to Write a Bug Report with Examples

Mikä on Bug Report? Miksi tarvitset hyvän virheraportin?

Virheraportti on tärkeä dokumentti STLC:ssä, josta on useita etuja testaustiimille. Se pitää track kaikista ohjelmistotestauksen aikana löydetyistä vioista, useista bugeista, virheistä ja muista poikkeamista ja raportoi ne.

Tämän testauksen jälkeisen dokumentaation tarkoituksena on antaa asianomaiselle ammattilaistiimille tietoa testausprosessin aikana havaittujen virheiden tasosta.

Sinun ohjelmistokehitysinsinööri can be made aware of all the defects and issues present in the software using this type of report. It also lets you figure out what is wrong with a bug, so you can use the best method to fix it. It also helps you to save your time and money by helping huomaat bugeja ja ongelmia.

Miksi sinun pitäisi välittää hyvistä virheselityksistä?

Tässä on se kohta, joka sinun on otettava huomioon kirjoittaaksesi hyvän, yksityiskohtaisen ohjelmistovirheraportin:

• Se toimii oppaana, joka auttaa välttämään saman bugin tulevissa julkaisuissa.
• Säästä aikaa viestintään (sähköpostit, puhelut).
• Less työskentelemään kehittäjille (he tekevät juuri mitä haluat).
• Sinulla on vähemmän pullonkauloja projektissa; virheet korjataan nopeammin ja tehokkaammin.
• Modern teams using Jira, Linear, or Azure DevOps can also link bug reports to sprint tickets and release pipelines, ensuring traceability across QA and DevOps workflows.

Virheilmoituksen kirjoittaminen (Virheraporttimalli)

Tarkkaa vikailmoitusmallia ei ole, koska se riippuu vianmäärityksestäsi.tracking-järjestelmä. Mallisi saattaa olla erilainen.

Seuraavat yleiset kentät ovat kuitenkin aina tarpeen, kun haluat kirjoittaa virheraportin:

• Vian tunnus/otsikko.
• Vakavuus ja prioriteetti.
• Tuotetiedot
• ympäristö
• Vaiheet lisääntymiseen.
• Odotettu tulos.
• Todellinen tulos.
• Liitteet (kuvakaappaukset, videot, teksti)

Let us look at all these bug-tracking components one by one:

1) Otsikko/virhetunnus:

Jokaiselle bugille tulee antaa yksilöllinen tunnistenumero. Virheilmoitustyökalujen tulee olla yksilöiviä numeroita äskettäin esiin tulleille virheille, jotta voimme helposti tunnistaa vian.

Esimerkkejä:

❌ Huono: "En näe tuotetta, kun taas kerran, tyrp se ei näy."

• Epämääräinen
• Aggressiivinen
• Liian sanallinen

pyytää ratkaisun toteuttamista.

✅ Hyvä: "OSTOSORI – Ostoskoriin on lisätty uusia tuotteita, jotka eivät näy".

• Tällainen otsikko löytää välittömästi ongelman (CART)
• Se keskittyy varsinaiseen tekniseen ongelmaan.

2) Virheen vakavuus:

Virheen vakavuus on erittäin tärkeä tekijä virheraportissa. Se kuvaa vian vaikutusta sovelluksen suorituskykyyn.

• Estoaineet: Tämä virhe aiheuttaa sovelluksen epäonnistumisen.
• Suuri: Kriittinen virhe tarkoittaa suurta muutosta liiketoimintalogiikassa.
• Minor: Ongelma, joka ei vaikuta sovelluksen toimintaan, mutta vaikuttaa odotettuihin tuloksiin.
• Triviaali: Se ei vaikuta sovelluksen toimivuuteen tai toimintaan. Se voi olla kirjoitusvirhe.

3) Virheen prioriteetti:

Seuraava on yleinen asteikko virheen prioriteetin määrittämiseksi:

• Korkea: Se kattaa kaiken, mikä vaikuttaa virtaukseen tai estää sovellusten käytön.
• Medium: Se vaikuttaa haitallisesti käyttökokemukseen.
• Minor: Kaikki muut virheet, kuten (kirjoitusvirheet, puuttuvat kuvakkeet, asetteluongelmat jne.).

4) Ympäristö:

Virhe voi esiintyä tietyssä ympäristössä, ei muissa. Joskus esimerkiksi virhe ilmenee, kun verkkosivustoa käytetään Firefox, tai sovelluksen toimintahäiriö vain käytettäessä Android laite ja toimii hyvin iPhonessa.

Nämä virheraportit voidaan tunnistaa vain selaimen tai laitteiden välisellä testauksella. Joten virhettä raportoidessaan laadunvalvontaviranomaisten tulisi pystyä määrittämään, tuleeko vika havaita yhdessä vai useammassa tietyssä ympäristössä.

5) Yhteenveto:

However, adding only the Title in the bug report does not serve the purpose. So, if your Title is not enough, you can add a short report summary.

Yhteenveto mahdollisimman pienellä sanalla, mukaan lukien milloin ja miten virhe tapahtui. Otsikkoasi ja virhekuvaustasi tulee myös käyttää hauissa, joten sinun on varmistettava, että olet kattanut tärkeät avainsanat.

Esimerkit:

• huono: "Yritin lisätä asioita testiin, mutta mitään ei näkynyt, kun tein sen tai napsautin painiketta."
• Hyvä: "Kun yritin lisätä [TUOTETTA] kauppaanping ostoskoriin, mutta mitään ei tapahtunut, kun napsautin 'Lisää'-painiketta tietyn tuotteen yleiskatsaussivulla.”

6) Toistamisvaiheet:

When reporting a bug, it is important to specify the steps to reproduce it. You should also include actions that may cause the bug. Here, do not make any generic statements.

Ole tarkka seuraavissa vaiheissa:

Tässä on esimerkki hyvin kirjoitetusta menettelystä:

Vaiheet:

1. Valitse tuote X1.
2. Klikkaa Lisää ostoskoriin.
3. Poista tuote ostoskorista napsauttamalla Poista.

7) Odotettu tulos:

Virheraporteissa on tärkeää kuvata odotettu tulos teknisen tehtävän, testitapauksen tulosten suunnittelun tai testaajan mielipiteen mukaan. Kaikki tämä auttaa kehittäjiä keskittymään tarvittavan tiedon nopeaan löytämiseen.

Esimerkiksi:

Pakolliset kentät tulee korostaa punaisella "Lähetä"-painikkeen painamisen jälkeen.

8) Todellinen tulos:

Kuten nimestä voi päätellä, tämä kenttä kuvaa vian todellista vaikutusta. On erittäin tärkeää kirjoittaa selkeä kuvaus todellisesta tuloksesta.

Esimerkiksi:

Pakolliset kentät on korostettu vihreällä "Lähetä"-painikkeen painamisen jälkeen.

9) Liitteet (kuvakaappaukset ja videot):

Virheraporteissa on parasta liittää tiedostoja virheraportteihin, mikä helpottaa tietojen havaitsemista, kun haluat näyttää ne visuaalisesti:

Esimerkiksi:

• Kuvakaappaus: Näyttökaappaukset voivat helposti kehittää ohjelman virheitä; on kätevää, kun vika on korostettu tietyllä merkinnällä, ympyrällä tai nuolella).
• Video: Sometimes, it is difficult to describe the bug in words, so it is better to create a video so that developer can rectify the defect in the program).

10) Versio, jota asia koskee:

Se on ohjelmistoversio, jossa vika ilmoitetaan.

11) Korjausversio:

Se on ohjelmistoversio, jossa vika on korjattu. Joten kun virheestä ilmoittanut laadunvalvontaviranomainen tarkistaa, onko se korjattu, hän käyttää oikeaa ohjelmistoversiota.

12) Target versio:

Kohdeversio, johon virhe tulisi kohdistaa korjattavaksi. Joten kun kehitystiimi työskentelee virheen korjaamiseksi, ne kohdistavat enimmäkseen tiettyyn sovellusversioon.

13) Sulkemispäivä:

Se on päivämäärä, jolloin ohjelmistotestaustiimi sulkee virheen. Virheen sulkeminen on tärkeä ja olennainen osa ohjelmistotestausta.

14) Tila:

Kun uusi bugi luodaan, sen tilan tulee olla avoin. Sen jälkeen se käy läpi vaiheita, kuten käynnissä, korjattu, käynnissä, uudelleen avaaminen jne.

Vinkkejä virheraporttien kirjoittamiseen

Tässä on muutamia tärkeitä vinkkejä, jotka sinun tulee muistaa, kun kirjoitat tehokasta virheraporttia:

• Be specific when creating bug reports. Make sure you do not include any useless or irrelevant facts.
• Sinun tulee ilmoittaa virheestä heti, kun se havaitaan.
• Valmistele raportti yksityiskohtaisesti, jotta kehittäjä voi käyttää tosiasioita ja tietoja ongelman korjaamiseen.
• Sinun tulisi testata samaa bugiesiintymistä muissa vastaavissa moduuleissa validointia varten.
• Revkatso vikaraportti vähintään kerran ennen sen lähettämistä.
• Varmista, että vikaraportti sisältää vain yhden virheen kuvauksen.
• Lopuksi, sinun ei pitäisi pelätä pyytää apua projektipäälliköltä, jos jokin asia tuntuu epäselväksi.
• Use AI-assisted triage features in Jira or Linear to auto-classify severity, suggest duplicates, and route the report to the right component owner.

Virheilmoitustyökalut

Manuaalisesti suoritettava virheraportointiprosessi suoritetaan nyt erilaisilla markkinoilla olevilla virheraportointityökaluilla.

• JIRA
• Lineaarinen
• Azure DevOps
• Zoho-virhe Tracker
• Bugzilla

Voit tarkistaa yksityiskohtaisen arvostelumme paras bugiraportointityökalu.

Yleinen ongelma ja ratkaisu vikaraporttia kirjoitettaessa:

Tässä on joitain yleisiä ongelmia ja niiden ratkaisuja virheraporttia kirjoitettaessa:

Esimerkki virheilmoituksesta	Ongelma
Kun kerrotaan 2 kolmella, vastaus on myönteinen.	Ilmoita malli, älä esimerkki.
Luettelo järjestetään aakkosjärjestyksessä, kun lisäät uutta tuotetta tämän välttämiseksi.	Do not only describe what is wrong
Esimerkiksi: Avataksesi selaimesi ja kirjoittaessasi sivuston URL. You will find the first field, ‘username,’ misspelled.	Aina suoraan asiaan (älä koskaan kerro tarinaa!).
Asiakkaan nimi raportissa on kirjoitettu väärin. Prioriteetti: korkea, vakavuus: korkea	Älä koskaan sekoita tärkeysjärjestystä ja vakavuutta.
Veron laskentakaava on VÄÄRIN !!??	Ei käytä isoja kirjaimia, punaisia ​​kirjaimia, punaisia ​​ympyröitä, '!',
I do not think that the home page Ul design is good.	Do not use your judgment.
Esimerkki epäselvästä kuvauksesta: Tee tämän sivun edellyttämät toimet tämän päivän keskustelustamme.	Tee kuvauksestasi ymmärrettävä kaikille.
Sivun taustan tulee olla sininen, oranssi tai vihreä, tai voit tehdä sen mustaksi tai valkoiseksi. Tämä ei ole hyvä, koska on epäselvää, mitä web-kehitys- ja suunnittelutiimiltä tarvitaan	Minimoi vaihtoehdot
Veron laskentakaava ei toisinaan toimi odotetulla tavalla.	The golden rule: Do not use the word ‘Sometimes’.

Esimerkki virheraportista

Tässä pieni esimerkki virheraportista:

[OMA TILI] Alleviivaus näkyy, kun hiiren osoitin viedään Päivitä-painikkeen päälle.

Descriptioni: Meidän on poistettava alleviivaus vietäessä hiiren osoitin Oma tili -osion Päivitä-painikkeen päälle.

Linkki: http://test.com/mv-account/

Selain/käyttöjärjestelmä: Chrome 25. OSX Yosemite 10.10.2

Toistamisvaiheet:

1. Siirry osoitteeseen www.test.com

2. Kirjaudu sisään kirjautumistiedoilla

3. Siirry kohtaan Oma tili

4. Vie hiiri Päivitä-painikkeen päälle

Todellinen tulos: on alleviivaus.

Odotettu tulos: ei alleviivausta.

Sisäänkirjautumistiedot: test@test.com / mysecretpass12

Virheitä tulee välttää virheraporttien kirjoittamisessa

Tässä on joitain tärkeitä virheitä, joita sinun tulee välttää virheraporttia kirjoittaessasi:

• Do not write about your dissatisfaction, and never include your personal feelings.
• Se ärsyttää ihmisiä, jotka haluavat keskittyä tehtävään, kun ylikuormitat viestisi monilla hymiöillä.
• Älä koskaan ylikuormi viestiäsi huutomerkeillä; se ei nopeuta työtä.
• Kukaan ei halua olla loukkaantunut. Se tuhoaa motivaation ja hidastaa ongelman oivaltamista.

UKK