Hvorfor en god fejlrapport?

Hvis din fejlrapport er effektiv, er der større chance for, at den bliver rettet. Så rettelsen af en fejl afhænger af, hvor effektivt du rapporterer den. At rapportere en fejl er intet andet end færdighed, og jeg vil forklare, hvordan du opnår denne færdighed.

“Formålet med at skrive en problemrapport (fejlrapport) er at få fejl rettet” – Af Cem Kaner. Hvis en tester ikke rapporterer en fejl korrekt, vil programmøren højst sandsynligt afvise denne fejl med den begrundelse, at den ikke kan reproduceres.

Dette kan skade testerens moral og nogle gange også egoet. (Jeg foreslår, at man ikke bevarer nogen form for ego. Ego’er som “Jeg har rapporteret fejlen korrekt”, “Jeg kan reproducere den”, “Hvorfor har han/hun afvist fejlen?”, “Det er ikke min skyld” osv.).

Hvad er kvaliteterne ved en god softwarefejlrapport?

Alle kan skrive en fejlrapport. Men ikke alle kan skrive en effektiv fejlrapport.

Du bør være i stand til at skelne mellem en gennemsnitlig fejlrapport og en god fejlrapport. Hvordan skelner man mellem en god og en dårlig fejlrapport? Det er meget enkelt, du skal anvende følgende karakteristika og teknikker til at rapportere en fejl.

Karakteristika og teknikker omfatter

#1) At have et klart specificeret fejlnummer: Tildel altid et unikt nummer til hver fejlrapport. Dette vil til gengæld hjælpe dig med at identificere fejlrapporten. Hvis du bruger et automatiseret fejlrapporteringsværktøj, vil dette unikke nummer blive genereret automatisk hver gang, mens du rapporterer fejlen.

Notér nummeret og en kort beskrivelse af hver fejl, som du rapporterer.

#2) Reproducerbar: Hvis din fejl ikke kan reproduceres, vil den aldrig blive rettet.

Du skal tydeligt nævne de trin, der skal til for at reproducere fejlen. Du må ikke antage eller springe noget reproduktionstrin over. En fejl, der er beskrevet trin for trin, er let at reproducere og rette.

#3) Vær specifik: Du skal ikke skrive et essay om problemet.

Være specifik og præcis. Prøv at opsummere problemet med et minimum af ord, men alligevel på en effektiv måde. Kombinér ikke flere problemer, selv om de synes at være ens. Skriv forskellige rapporter for hvert problem.

Effektiv fejlrapportering

Bugrapportering er et vigtigt aspekt af softwaretestning. En effektiv fejlrapport kommunikerer godt med udviklingsteamet og undgår forvirring eller fejlkommunikation.

En god fejlrapport skal være klar og kortfattet uden manglende nøglepunkter. Enhver mangel på klarhed fører til misforståelser og gør også udviklingsprocessen langsommere. Fejlskrivning og -rapportering er et af de vigtigste, men forsømte områder i testens livscyklus.

God skrivning er meget vigtig for indgivelse af en fejl. Det vigtigste punkt, som en tester bør huske på, er ikke at bruge en kommanderende tone i rapporten. Det ødelægger moralen og skaber et usundt arbejdsforhold. Brug en suggestiv tone.

Du må ikke antage, at udvikleren har begået en fejl, og derfor kan du bruge hårde ord. Før du rapporterer, er det lige så vigtigt at kontrollere, om den samme fejl er blevet rapporteret eller ej.

En dobbeltfejl er en byrde i testcyklussen. Kontroller hele listen over kendte fejl. Nogle gange kan udviklerne have kendt problemet og ignoreret det til en fremtidig udgivelse. Værktøjer som Bugzilla, der automatisk søger efter dublerede fejl, kan også bruges. Det er dog bedst at søge manuelt efter eventuelle dubletter af fejl.

De vigtige oplysninger, som en fejlrapport skal kommunikere, er “Hvordan?” og “Hvor?”. Rapporten skal klart svare på, hvordan testen blev udført, og hvor fejlen præcist opstod. Læseren skal nemt kunne reproducere fejlen og finde ud af, hvor fejlen er.

Hold dig for øje, at formålet med at skrive fejlrapporten er at sætte udvikleren i stand til at visualisere problemet. Han/hun bør klart forstå fejlen ud fra fejlrapporten. Husk at give alle de relevante oplysninger, som udvikleren søger.

Hold også for øje, at en fejlrapport vil blive bevaret til fremtidig brug, og at den skal være velskrevet med de nødvendige oplysninger. Brug meningsfulde sætninger og enkle ord til at beskrive dine fejl. Brug ikke forvirrende udsagn, der spilder reviewerens tid.

Rapporter hver fejl som et separat problem. Hvis der er flere problemer i en enkelt fejlrapport, kan du ikke lukke den, medmindre alle problemerne er løst.

Det er derfor bedst at opdele problemerne i separate fejl. Dette sikrer, at hver fejl kan håndteres separat. En velskrevet fejlrapport hjælper en udvikler til at reproducere fejlen på sin terminal. Dette hjælper dem også med at diagnosticere problemet.

Hvordan rapporterer man en fejl?

Brug følgende enkle fejlrapportskabelon:

Dette er et simpelt fejlrapportformat. Det kan variere afhængigt af det fejlrapporteringsværktøj, som du bruger. Hvis du skriver en fejlrapport manuelt, skal nogle felter nævnes specifikt, f.eks. fejlnummeret, som skal tildeles manuelt.

Rapporter: Dit navn og din e-mailadresse.

Produkt:

Produkt: I hvilket produkt du har fundet fejlen.

Version: Eventuel produktversion.

Komponent:

Platform: Dette er de vigtigste undermoduler i produktet.

Platform: Angiv den hardwareplatform, hvor du har fundet fejlen. De forskellige platforme som “PC”, “MAC”, “HP”, “Sun” osv.

Operationssystem: Angiv alle de styresystemer, hvor du har fundet fejlen. Operativsystemer som Windows, Linux, Unix, SunOS, Mac OS. Angiv også de forskellige OS-versioner som Windows NT, Windows 2000, Windows XP osv., hvis det er relevant.

Prioritet: Hvornår skal en fejl rettes? Prioriteten er generelt fastsat fra P1 til P5. P1 som “retter fejlen med den højeste prioritet” og P5 som “retter når tiden tillader det”.

Sværhedsgrad: Dette beskriver fejlens indvirkning.
Sværhedsgrad:
Typer af sværhedsgrad:

• Blokering: Der kan ikke udføres yderligere testarbejde.
• Kritisk: Programnedbrud, tab af data.
• Større: Større tab af funktion.
• Mindre: Mindre tab af funktion.
• Trivielt: Nogle forbedringer af brugergrænsefladen.
• Forbedring: Anmodning om en ny funktion eller en forbedring af den eksisterende funktion.

Status: Når du logger fejlen i et fejlsporingssystem, vil fejlstatus som standard være “Ny”.
Senere gennemgår fejlen forskellige stadier som f.eks. rettet, verificeret, genåbnet, vil ikke blive rettet osv.

=> Klik her for at læse mere om den detaljerede fejllivscyklus.

Assign To: Hvis du ved, hvilken udvikler der er ansvarlig for det pågældende modul, hvor fejlen er opstået, kan du angive den pågældende udviklers e-mailadresse. Ellers skal du lade det være tomt, da dette vil tildele fejlen til modulets ejer, hvis ikke Manager vil tildele fejlen til udvikleren. Tilføj eventuelt managerens e-mail-adresse i CC-listen.

URL: URL: Den side-URL, hvor fejlen opstod.

Summary: Et kort resumé af fejlen, for det meste i 60 ord eller derunder. Sørg for, at dit resumé afspejler, hvad problemet er, og hvor det opstår.

Beskrivelse: En detaljeret beskrivelse af fejlen.

Brug følgende felter til beskrivelsesfeltet:

• Reproducer trin: Angiv tydeligt trinene for at reproducere fejlen.
• Forventet resultat: Hvordan programmet skal opføre sig på de ovennævnte trin.
• Faktisk resultat:

Dette er de vigtige trin i fejlrapporten. Du kan også tilføje “Report type” som endnu et felt, der vil beskrive fejltypen.

Rapporttyperne omfatter:

1) Kodningsfejl
2) Designfejl
3) Nyt forslag
4) Dokumentationsproblem
5) Hardwareproblem

Vigtige funktioner i din fejlrapport

Nedenfor er de vigtige funktioner i fejlrapporten angivet:

#1) Fejlnummer/id

Et fejlnummer eller et identifikationsnummer (som swb001) gør det meget lettere at rapportere fejl og henvise til en fejl. Udvikleren kan nemt kontrollere, om en bestemt fejl er blevet rettet eller ej. Det gør hele test- og omtestningsprocessen smidigere og nemmere.

#2) Fejltitel

En fejltitel bliver læst oftere end nogen anden del af fejlrapporten. Den skal sige alt om, hvad der kommer i fejlen.

Fejltitlen skal være suggestiv nok til, at læseren kan forstå den. En klar bugtitel gør det let at forstå, og læseren kan vide, om fejlen er blevet rapporteret tidligere eller er blevet rettet.

#3) Prioritet

Baseret på fejlens alvorlighed kan der fastsættes en prioritet for den. En fejl kan være en Blocker, Critical (kritisk), Major (større), Minor (mindre), Trivial (triviel) eller et forslag. Der kan gives en fejlprioritet fra P1 til P5, så de vigtige fejl bliver vist først.

#4) Platform/miljø

Den OS- og browserkonfiguration er nødvendig for at få en klar fejlrapport. Det er den bedste måde at kommunikere, hvordan fejlen kan reproduceres.

Og uden den nøjagtige platform eller det nøjagtige miljø kan programmet opføre sig anderledes, og fejlen i testerens ende kan ikke nødvendigvis reproduceres i udviklerens ende. Så det er bedst at nævne tydeligt det miljø, hvor fejlen blev opdaget.

#5) Beskrivelse

Bugbeskrivelsen hjælper udvikleren med at forstå fejlen. Den beskriver det problem, der er opstået. Den dårlige beskrivelse skaber forvirring og spilder både udviklernes og testernes tid.

Det er nødvendigt at kommunikere klart om virkningen af beskrivelsen. Det er altid nyttigt at bruge fuldstændige sætninger. Det er en god praksis at beskrive hvert problem separat i stedet for at smuldre dem sammen. Brug ikke udtryk som “jeg tror” eller “jeg tror”.

#6) Trin til reproduktion

En god fejlrapport bør klart nævne trinene til reproduktion. Trinene bør omfatte handlinger, der forårsager fejlen. Du må ikke komme med generiske udsagn. Vær specifik i de trin, der skal følges.

Et godt eksempel på en velskrevet procedure er givet nedenfor

Strin:

• Vælg produkt Abc01.
• Klik på Tilføj til kurv.
• Klik på Fjern for at fjerne produktet fra indkøbskurven.

#7) Forventet og faktisk resultat

En fejlbeskrivelse er ufuldstændig uden de forventede og faktiske resultater. Det er nødvendigt at skitsere, hvad resultatet af testen er, og hvad brugeren skal forvente. Læseren skal vide, hvad det korrekte resultat af testen er. Nævn klart og tydeligt, hvad der skete under testen, og hvad resultatet var.

#8) Screenshot

Et billede siger mere end tusind ord. Tag et skærmbillede af fejltilfældet med en ordentlig billedtekst for at fremhæve fejlen. Fremhæv uventede fejlmeddelelser med lys rød farve. Dette henleder opmærksomheden på det nødvendige område.

Nogle bonustips til at skrive en god fejlrapport

Nedenfor er der angivet yderligere tips til at skrive en god fejlrapport:

#1) Rapporter problemet med det samme

Hvis du finder en fejl under testning, behøver du ikke vente med at skrive en detaljeret fejlrapport senere. I stedet skal du skrive fejlrapporten med det samme. Dette vil sikre en god og reproducerbar fejlrapport. Hvis du beslutter dig for at skrive fejlrapporten senere, er der store chancer for at gå glip af vigtige trin i din rapport.

#2) Reproducer fejlen tre gange, før du skriver en fejlrapport

Din fejl skal kunne reproduceres. Sørg for, at dine trin er robuste nok til at reproducere fejlen uden nogen tvetydighed. Hvis din fejl ikke kan reproduceres hver gang, kan du stadig indsende en fejl med angivelse af fejlens periodiske karakter.

#3) Test den samme fejlforekomst på andre lignende moduler

Sommetider bruger udvikleren den samme kode til forskellige lignende moduler. Så der er større chancer for, at fejlen i et modul også forekommer i andre lignende moduler. Du kan endda forsøge at finde den mere alvorlige version af den fejl, du har fundet.

#4) Skriv et godt fejlresumé

Bugresuméet vil hjælpe udviklerne til hurtigt at analysere fejlens art. En rapport af dårlig kvalitet vil unødigt øge udviklings- og testtiden unødigt. Kommuniker godt med dit fejlrapportresumé. Husk på, at fejlresuméet bruges som reference til at søge efter fejlen i fejlfortegnelsen.

#5) Læs fejlrapporten, før du trykker på Submit-knappen

Læs alle de sætninger, formuleringer og trin, der bruges i fejlrapporten. Se, om der er nogen sætning, der skaber tvetydighed, som kan føre til fejlfortolkning. Misvisende ord eller sætninger bør undgås for at få en klar fejlrapport.

#6) Brug ikke et groft sprog

Det er rart, at du har gjort et godt stykke arbejde og fundet en fejl, men brug ikke denne kredit til at kritisere udvikleren eller til at angribe nogen person.

Konklusion

Ingen tvivl om, at din fejlrapport skal være et dokument af høj kvalitet.

Fokuser på at skrive gode fejlrapporter, og brug noget tid på denne opgave, fordi det er det vigtigste kommunikationspunkt mellem testeren, udvikleren og lederen. Lederne bør skabe en bevidsthed hos deres team om, at det at skrive en god fejlrapport er det primære ansvar for enhver tester.