Sådan skriver du en fejlrapport med eksempler

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

Bug Report er et vigtigt dokument i STLC, der tilbyder forskellige fordele til testteamet. Det holder styr på alle defekter, flere fejl, fejl og andre uoverensstemmelser fundet 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 kan gøres opmærksom på alle defekter og problemer i softwaren ved hjælp af denne type rapport. Det lader dig også finde ud af, hvad der er galt med en fejl, så du kan bruge den bedste metode til at rette den. Det hjælper dig også med at spare tid og penge ved at hjælpe dig med at fange 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.

Sådan skriver du fejlrapport (skabelon for fejlrapport)

Der er ingen nøjagtig fejlrapportskabelon, da den afhænger af dit fejlsporingssystem. 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.
• Tekniske beskrivelser
• Miljø
• Trin til at reproducere.
• Forventet resultat.
• Faktisk resultat.
• Vedhæftede filer (skærmbilleder, videoer, tekst)

Lad os se på alle disse fejlbekæmpende komponenter én efter én:

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é:

Men kun at tilføje titlen i fejlrapporten tjener ikke formålet. Så hvis din titel ikke er nok, kan du tilføje et kort rapportresumé.

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 forsøgte at tilføje [PRODUKT] til indkøbskurven, men der skete ikke noget, da jeg klikkede på knappen 'Tilføj' på den specifikke produktoversigts webside."

6) Trin til at reproducere:

Når du rapporterer en fejl, er det vigtigt at specificere trinene for at reproducere den. Du bør også inkludere handlinger, der kan forårsage fejlen. Her må du ikke komme med generiske udsagn.

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: Nogle gange er det svært at beskrive fejlen med ord, så det er bedre at oprette en video, så udvikleren kan rette fejlen i programmet).

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:

• Vær specifik, når du opretter fejlrapporter. Sørg for, at du ikke medtager ubrugelige eller irrelevante fakta.
• 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.

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
• Zoho Bug 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.	Beskriv ikke kun, hvad der er galt
For eksempel: For at blive det, skal du åbne din browser og indtaste webstedets URL. Du vil finde det første felt, 'brugernavn', stavet forkert.	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, '!',
Jeg synes ikke, at hjemmesiden Ul design er god.	Brug ikke din dømmekraft.
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.	Den gyldne regel: Brug ikke ordet 'Nogle gange'.

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:

• Skriv ikke om din utilfredshed, og medtag aldrig dine personlige følelser.
• 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.