Hvordan skrive en feilrapport med eksempler

Hva er feilrapport? Hvorfor trenger du en god feilrapport?

Bug Report er et viktig dokument i STLC som tilbyr ulike fordeler for testteamet. Den holder styr på alle defekter, flere feil, feil og andre avvik funnet under programvaretesting og rapporterer dem.

Hensikten med denne dokumentasjonen etter testing er å gi informasjon til det berørte teamet av fagfolk om nivået av feil som oppstår under testprosessen.

Din programvareutviklingsingeniør kan gjøres oppmerksom på alle defekter og problemer som finnes i programvaren ved å bruke denne typen rapporter. Den lar deg også finne ut hva som er galt med en feil, slik at du kan bruke den beste metoden for å fikse den. Det hjelper deg også å spare tid og penger ved å hjelpe deg med å fange feil og problemer.

Hvorfor bør du bry deg om gode feilforklaringer?

Her er poenget du må vurdere for å skrive en god, detaljert programvarefeilrapport:

• Den fungerer som en guide for å unngå den samme feilen i fremtidige utgivelser.
• Spar tid for kommunikasjon (e-post, samtaler).
• Less jobbe for utviklere (de vil gjøre akkurat det du vil).
• Du vil få mindre flaskehalser i prosjektet; feil vil bli fikset raskere og mer effektiv måte.

Hvordan skrive feilrapport (mal for feilrapport)

Det er ingen eksakt mal for feilrapportering, da den avhenger av feilsporingssystemet ditt. Malen din kan være annerledes.

Følgende vanlige felt er imidlertid alltid nødvendige når du vil skrive en feilrapport:

• Feil-ID/tittel.
• Alvorlighet og prioritet.
• Tekniske beskrivelser
• Miljø
• Trinn for å reprodusere.
• Forventet resultat.
• Faktisk resultat.
• Vedlegg (skjermbilder, videoer, tekst)

La oss se på alle disse feilsøkende komponentene én etter én:

1) Tittel/feil-ID:

Hver feil bør gis et unikt identifikasjonsnummer. Verktøy for feilrapportering bør være unike tall for de nylig registrerte feilene, slik at vi enkelt kan identifisere feilen.

Eksempler:

❌ Dårlig: "Jeg kan ikke se produktet når jeg igjen, tyrp det gjør det ikke."

• Uklar
• Aggressiv
• For ordrik

ber om at en løsning implementeres.

✅ Bra: “CART – Nye varer lagt til i handlekurven som ikke vises”.

• Denne typen tittel lokaliserer umiddelbart problemet (CART)
• Den fokuserer på det faktiske tekniske problemet.

2) Feilens alvorlighetsgrad:

Feilens alvorlighetsgrad er en svært viktig faktor i feilrapporten. Den beskriver effekten av defekten på applikasjonens ytelse.

• Blokkere: Denne feilen fører til at appen mislykkes.
• Major: En kritisk feil indikerer en stor endring i forretningslogikken.
• Liten: Et problem som ikke påvirker applikasjonens funksjonalitet, men som påvirker de forventede resultatene.
• Triviell: Det påvirker ikke funksjonaliteten eller driften av appen. Det kan være en skrivefeil.

3) Feilprioritet:

Følgende er den generelle graderingen for å bestemme feilprioritet:

• Høy: Den dekker alt som påvirker flyten eller blokkerer appbruk.
• Medium: Det påvirker brukeropplevelsen negativt.
• Liten: Alle andre feil som (skrivefeil, manglende ikoner, layoutproblemer, etc.).

4) Miljø:

En Bug kan dukke opp i et spesifikt miljø og ikke andre. Noen ganger dukker det for eksempel opp en feil når du kjører nettstedet på Firefox, eller en app-feil bare når den kjøres på en Android enhet og fungerer fint på iPhone.

Disse feilrapportene kan bare identifiseres med testing på tvers av nettlesere eller flere enheter. Så når du rapporterer feilen, bør QA-er kunne spesifisere om feilen skal observeres i ett eller flere spesifikke miljøer.

5) Sammendrag:

Men å bare legge til tittelen i feilrapporten tjener ikke formålet. Så hvis tittelen din ikke er nok, kan du legge til et kort rapportsammendrag.

Sammendraget ditt i så få ord som mulig, inkludert når og hvordan feilen oppsto. Tittelen og feilbeskrivelsen din bør også brukes i søk, så du må sørge for at du har dekket viktige søkeord.

Eksempler:

• Bad: "Jeg prøvde å legge til ting i testen, og ingenting dukket opp når jeg gjorde det eller klikket på knappen."
• Good: "Da jeg prøvde å legge til [PRODUCT] i handlekurven, men ingenting skjedde da jeg klikket på 'legg til'-knappen på den spesifikke produktoversiktssiden."

6) Trinn for å reprodusere:

Når du rapporterer en feil, er det viktig å spesifisere trinnene for å reprodusere den. Du bør også inkludere handlinger som kan forårsake feilen. Her, ikke kom med noen generelle utsagn.

Vær spesifikk på trinnene du skal følge:

Her er et eksempel på velskrevet prosedyre:

Fremgangsmåte:

1. Velg produkt X1.
2. Klikk på Legg i handlekurv.
3. Klikk Fjern for å fjerne produktet fra handlekurven.

7) Forventet resultat:

I feilrapporter er det viktig å beskrive det forventede resultatet i henhold til den tekniske oppgaven, design av testcaseresultater eller i henhold til testerens mening. Alt dette hjelper utviklere til å fokusere på raskt å finne nødvendig informasjon.

For eksempel:

Obligatoriske felt skal utheves i rødt etter å ha klikket på "Send"-knappen.

8) Faktisk resultat:

Som navnet antyder, beskriver dette feltet den faktiske effekten av feilen. Det er svært viktig å skrive en tydelig beskrivelse av det faktiske resultatet.

For eksempel:

Obligatoriske felt er uthevet i grønn farge etter å ha klikket på "Send"-knappen.

9) Vedlegg (skjermbilder og videoer):

I feilrapporter er det beste praksis å legge ved filer til feilrapporter som gjør det lettere å oppfatte informasjon når du trenger å vise den visuelt:

For eksempel:

• Skjermbilde: Skjermbilder kan enkelt utdype feil i programmet; er praktisk når feilen er uthevet med en spesifikk merknad, sirkel eller pilbilde).
• Video: Noen ganger er det vanskelig å beskrive feilen med ord, så det er bedre å lage en video slik at utvikleren kan rette opp feilen i programmet).

10) Berørt versjon:

Det er den berørte programvareversjonen der feilen rapporteres.

11) Reparer versjon:

Det er programvareversjonen der feilen er løst. Så når QA som rapporterte feilen, sjekker om den er fikset, bruker han riktig programvareversjon.

12) Target versjon:

Målversjonen der en feil skal rettes opp. Så når utviklingsteamet jobber med å fikse en feil, retter de seg stort sett mot en bestemt applikasjonsversjon.

13) Stengt dato:

Det er datoen da feilen lukkes av programvaretestteamet. Å lukke en feil er en viktig og integrert del av programvaretesting.

14) Status:

Når en ny feil opprettes, skal statusen være åpen. Etter det går den gjennom stadier som Pågår, Fixed, Running, Reopen, etc.

Tips for skriving av feilrapporter

Her er noen viktige tips du bør huske når du skriver en effektiv feilrapport:

• Vær spesifikk når du lager feilrapporter. Pass på at du ikke inkluderer ubrukelige eller irrelevante fakta.
• Du må rapportere feilen umiddelbart så snart den blir oppdaget.
• Forbered rapporten i detalj for å gi utvikleren mulighet til å bruke fakta og informasjon for å feilsøke problemet.
• Du bør teste den samme feilen på andre lignende moduler for validering.
• Revse feilrapporten minst én gang før du sender den.
• Du bør sørge for at feilrapporten inneholder beskrivelsen av kun én feil.
• Til slutt bør du ikke være redd for å spørre prosjektlederen om hjelp hvis du føler deg uklar om noe.

Verktøy for feilrapportering

Feilrapporteringsprosessen, utført manuelt, utføres nå med forskjellige feilrapporteringsverktøy tilgjengelig på markedet.

• JIRA
• Zoho Bug Tracker
• Bugzilla

Du kan sjekke vår detaljerte gjennomgang av beste feilrapporteringsverktøyet.

Vanlig problem og løsning når du skriver en feilrapport:

Her er noen vanlige problemer og deres løsninger mens du skriver en feilrapport:

Eksempel på feilrapport	Problem
Når du multipliserer 2 med 3, vil svaret være positivt.	Rapporter mønsteret, ikke et eksempel.
Listen vil bli ordnet alfabetisk når du legger til et nytt element for å unngå dette.	Ikke bare beskriv hva som er galt
For eksempel: For å bli det, må du åpne nettleseren din og skrive inn nettstedets URL. Du finner det første feltet, "brukernavn", feilstavet.	Alltid direkte til poenget (fortell aldri historien!).
Klientens navn i rapporten er feilstavet. Prioritet: Høy, alvorlighetsgrad: Høy	Bland aldri prioritet og alvorlighetsgrad.
Skatteberegningsformelen er FEIL !!??	Bruker ikke CAPS, røde bokstaver, røde sirkler, '!',
Jeg synes ikke at hjemmesiden Ul design er bra.	Ikke bruk dømmekraften din.
Eksempel på uklar beskrivelse: Om diskusjonen vår i dag, vennligst gjør den nødvendige handlingen for denne siden.	Gjør beskrivelsen din forståelig for alle.
Sidebakgrunnen skal være blå, oransje eller grønn, eller du kan gjøre den svart eller hvit. Dette er ikke bra da det er uklart hva som trengs fra webutviklings- og designteamet	Minimer alternativene
Skatteberegningsformelen fungerer noen ganger ikke som forventet.	Den gyldne regel: Ikke bruk ordet «noen ganger».

Eksempel på feilrapport

Her er et lite eksempel på en feilrapport:

[MIN KONTO] Understreking vises når musen overser Oppdater-knappen.

Description: Vi må fjerne understrekingen når musen overser Oppdater-knappen i Min konto-delen.

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

Nettleser/OS: Chrome 25. OSX Yosemite 10.10.2

Steg for å reprodusere:

1. Gå til www.test.com

2. Logg på via påloggingsinformasjon

3. Naviger til Min konto

4. Hold musepekeren på Oppdater-knappen

Faktisk resultat: det er en understreking.

Forventet resultat: ingen understreking.

Innloggingsdata: test@test.com / mysecretpass12

Må unngå feil ved skriving av feilrapporter

Her er noen viktige feil du bør unngå når du skriver en feilrapport:

• Ikke skriv om misnøyen din, og ta aldri med dine personlige følelser.
• Det irriterer folk som ønsker å fokusere på oppgaven når du overbelaster innlegget ditt med mange uttrykksikoner.
• Overbelast aldri innlegget ditt med utropstegn; det fremskynder ikke arbeidet.
• Ingen ønsker å føle seg fornærmet. Det ødelegger motivasjonen og bremser realiseringen av problemet.