How to Write a Bug Report with Examples

Hvad er fejlrapport? Hvorfor har du brug for en god fejlrapport?

Fejlrapporter er et vigtigt dokument i STLC, der tilbyder forskellige fordele for testteamet. Det holder track over alle defekter, flere bugs, fejl og andre uoverensstemmelser, der findes under softwaretest, og rapporterer dem.

Formålet med denne post-testdokumentation er at give information til det pågældende team af fagfolk om niveauet af fejl, der er stødt på under testprocessen.

Din softwareudviklingsingeniør 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 du opdager fejl og problemer.

Hvorfor skal du bekymre dig om gode fejlforklaringer?

Her er det punkt, du skal overveje for at skrive en god, detaljeret softwarefejlrapport:

• Det fungerer som en guide til at hjælpe med at undgå den samme fejl i fremtidige udgivelser.
• Spar tid til kommunikation (e-mails, opkald).
• Less arbejde for udviklere (de vil gøre præcis, hvad du vil).
• Du vil få færre flaskehalse i projektet; fejl vil blive rettet hurtigere og mere effektiv måde.
• 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.

Sådan skriver du fejlrapport (skabelon for fejlrapport)

Der er ingen præcis skabelon til fejlrapportering, da det afhænger af din fejl-trackongesystem. Din skabelon kan være anderledes.

Følgende almindelige felter er dog altid nødvendige, når du vil skrive en fejlrapport:

• Fejl-id/titel.
• Sværhedsgrad og prioritet.
• Beskrivelse
• Miljø
• Trin til at reproducere.
• Forventet resultat.
• Faktisk resultat.
• Vedhæftede filer (skærmbilleder, videoer, tekst)

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

1) Titel/fejl-id:

Hver fejl skal have et unikt identifikationsnummer. Fejlrapporteringsværktøjer bør være unikke numre for de nyligt rejste fejl, så vi nemt kan identificere fejlen.

eksempler:

❌ Dårligt: ​​"Jeg kan ikke se produktet, når jeg igen, tyrp det gør det ikke."

• Vag
• Aggressive
• For ordrig

anmoder om, at en løsning implementeres.

✅ Godt: “CART – Nye varer tilføjet til kurven, der ikke vises”.

• Denne form for titel lokaliserer øjeblikkeligt problemet (CART)
• Den fokuserer på det faktiske tekniske problem.

2) Sværhedsgrad af fejl:

Sværhedsgraden af ​​fejl er en meget vigtig faktor i fejlrapporten. Den beskriver virkningen af ​​defekten på applikationens ydeevne.

• Blokere: Denne fejl får appen til at fejle.
• Major: En kritisk fejl indikerer en større ændring i forretningslogikken.
• Mindre: Et problem, der ikke påvirker applikationens funktionalitet, men som påvirker de forventede resultater.
• Trivielt: Det påvirker ikke appens funktionalitet eller drift. Det kan være en typografisk fejl.

3) Fejlprioritet:

Følgende er den generelle graduering for at bestemme fejlprioritet:

• Høj: Det dækker alt, der påvirker flowet eller blokerer app-brug.
• Medium: Det påvirker brugeroplevelsen negativt.
• Mindre: Alle andre fejl som (tastefejl, manglende ikoner, layoutproblemer osv.).

4) Miljø:

En fejl kan dukke op i et specifikt miljø og ikke i andre. For eksempel opstår der nogle gange en fejl, når du kører hjemmesiden på Firefox, eller en app-fejl, kun når den kører på en Android enhed og fungerer fint på iPhone.

Disse fejlrapporter kan kun identificeres med test på tværs af browsere eller på tværs af enheder. Så når man rapporterer fejlen, bør QA'er kunne specificere, om fejlen skal observeres i et eller flere specifikke miljøer.

5) Resumé:

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.

Dit resumé med så få ord som muligt, herunder hvornår og hvordan fejlen opstod. Din titel og fejlbeskrivelse bør også bruges i søgninger, så du skal sikre dig, at du har dækket vigtige søgeord.

Eksempler:

• Bad: "Jeg prøvede at tilføje ting til testen, og der dukkede intet op, da jeg gjorde det eller klikkede på knappen."
• Godt: "Da jeg prøvede at tilføje [PRODUKT] til butikkenping indkøbskurven, men der skete ingenting, da jeg klikkede på knappen 'tilføj' på websiden med den specifikke produktoversigt.”

6) Trin til at reproducere:

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.

Vær specifik med de trin, du skal følge:

Her er et eksempel på velskrevet procedure:

Trin:

1. Vælg produkt X1.
2. Klik på Tilføj til indkøbskurv.
3. Klik på Fjern for at fjerne produktet fra indkøbskurven.

7) Forventet resultat:

I fejlrapporter er det vigtigt at beskrive det forventede resultat i henhold til den tekniske opgave, design af testcaseresultater eller ifølge testerens mening. Alt dette hjælper udviklere med at fokusere på hurtigt at finde den nødvendige information.

For eksempel:

Påkrævede felter skal fremhæves med rødt efter klik på knappen "Send".

8) Faktisk resultat:

Som navnene antyder, beskriver dette felt den faktiske effekt af fejlen. Det er meget vigtigt at skrive en klar beskrivelse af det faktiske resultat.

For eksempel:

Påkrævede felter er fremhævet i grøn farve efter klik på "Send"-knappen.

9) Vedhæftede filer (skærmbilleder og videoer):

I fejlrapporter er det bedste praksis at vedhæfte filer til fejlrapporter, hvilket gør det nemmere at opfatte information, når du skal vise den visuelt:

For eksempel:

• Screenshot: Skærmbilleder kan nemt uddybe fejl i programmet; er praktisk, når fejlen er fremhævet med en specifik anmærkning, cirkel eller pilbillede).
• 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) Berørt version:

Det er den berørte softwareversion, hvor fejlen rapporteres.

11) Rettelsesversion:

Det er softwareversionen, hvor fejlen er løst. Så når QA, der rapporterede fejlen, tjekker, om den er rettet, bruger han den korrekte softwareversion.

12) Target version:

Målversionen, hvor en fejl skal målrettes for at blive rettet. Så når udviklingsteamet arbejder på at rette en fejl, målretter de for det meste en bestemt applikationsversion.

13) Lukket dato:

Det er den dato, hvor fejlen lukkes af softwaretestteamet. Lukning af en fejl er en vital og integreret del af softwaretest.

14) Status:

Når en ny fejl oprettes, bør dens status være åben. Derefter går det gennem stadier som Igangværende, Fixed, Running, Reopen, etc.

Tips til fejlrapportskrivning

Her er nogle vigtige tips, som du bør huske, mens du skriver en effektiv fejlrapport:

• Be specific when creating bug reports. Make sure you do not include any useless or irrelevant facts.
• Du skal straks rapportere fejlen, så snart den bliver opdaget.
• Forbered rapporten i detaljer for at give udvikleren mulighed for at bruge fakta og oplysninger til at fejlsøge problemet.
• Du bør teste den samme fejlforekomst på andre lignende moduler for validering.
• Revse fejlrapporten mindst én gang, før du sender den.
• Du bør sikre dig, at fejlrapporten kun indeholder beskrivelsen af ​​én fejl.
• Endelig skal du ikke være bange for at bede projektlederen om hjælp, hvis du føler dig uklar omkring noget.
• Use AI-assisted triage features in Jira or Linear to auto-classify severity, suggest duplicates, and route the report to the right component owner.

Værktøjer til fejlrapportering

Fejlrapporteringsprocessen, der udføres manuelt, udføres nu med forskellige fejlrapporteringsværktøjer, der er tilgængelige på markedet.

• Jira
• Lineær
• Azure DevOps
• Zoho-fejl Tracker
• Bugzilla

Du kan tjekke vores detaljerede gennemgang af bedste fejlrapporteringsværktøj.

Almindelig problem og løsning under skrivning af en fejlrapport:

Her er nogle almindelige problemer og deres løsninger, mens du skriver en fejlrapport:

Eksempel på fejlrapport	Problem
Når du multiplicerer 2 med 3, vil svaret være positivt.	Rapporter mønsteret, ikke et eksempel.
Listen vil blive ordnet alfabetisk, når du tilføjer et nyt element for at undgå dette.	Do not only describe what is wrong
For eksempel: For at være det skal du åbne din browser og indtaste webstedets URL. You will find the first field, ‘username,’ misspelled.	Altid direkte til sagen (fortæl aldrig historien!).
Klientens navn i rapporten er stavet forkert. Prioritet: Høj, Sværhedsgrad: Høj	Bland aldrig prioritet og alvor.
Skatteberegningsformlen er FORKERT !!??	Bruger ikke CAPS, røde bogstaver, røde cirkler, '!',
I do not think that the home page Ul design is good.	Do not use your judgment.
Eksempel på uklar beskrivelse: Om vores diskussion i dag, bedes du gøre den nødvendige handling for denne side.	Gør din beskrivelse forståelig for alle.
Sidens baggrund skal være blå, orange eller grøn, eller du kan gøre den sort eller hvid. Dette er ikke godt, da det er uklart, hvad der er behov for fra webudviklings- og designteamet	Minimer mulighederne
Skatteberegningsformlen fungerer nogle gange ikke som forventet.	The golden rule: Do not use the word ‘Sometimes’.

Eksempel på fejlrapport

Her er et lille eksempel på en fejlrapport:

[MIN KONTO] Understregning vises, når musen føres over knappen Opdater.

Description: Vi skal fjerne understregningen, når musen overskrider knappen Opdater i Min konto-sektionen.

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

Browser/OS: Chrome 25. OSX Yosemite 10.10.2

Trin til reproduktion:

1. Gå til www.test.com

2. Log ind via login-legitimationsoplysninger

3. Naviger til Min konto

4. Hold musen over knappen Opdater

Faktisk resultat: der er en understregning.

Forventet resultat: ingen understregning.

Login data: test@test.com / mysecretpass12

Skal undgå fejl i fejlrapportskrivning

Her er nogle vigtige fejl, som du bør undgå, mens du skriver en fejlrapport:

• Do not write about your dissatisfaction, and never include your personal feelings.
• Det irriterer folk, der gerne vil fokusere på opgaven, når du overbelaster dit indlæg med mange humørikoner.
• Overbelast aldrig dit indlæg med udråbstegn; det fremskynder ikke arbejdet.
• Ingen ønsker at føle sig fornærmet. Det ødelægger motivationen og bremser realiseringen af ​​problemet.

Ofte Stillede Spørgsmål