Meny

Hur man skriver en bra felrapport? Tips och tricks

how write good bug report

Prova Vårt Instrument För Att Eliminera Problem

Varför bra felrapport?

Om din Bug-rapport är effektiv är dess chanser att fixa sig högre. Så att åtgärda ett fel beror på hur effektivt du rapporterar det. Att rapportera en bugg är inget annat än skicklighet och jag kommer att förklara hur man uppnår denna färdighet.

'Poängen med att skriva problemrapport (bugrapport) är att få buggar fixade' - Av Cem Kaner. Om en testare inte rapporterar ett fel korrekt kommer programmeraren med stor sannolikhet att avvisa detta fel och ange det som irreproducerbart.

Hur man skriver en bra felrapport

Detta kan skada testarnas moral och ibland också egot. (Jag föreslår att du inte behåller någon typ av ego. Egon som 'Jag har rapporterat felet korrekt', 'Jag kan reproducera det', 'Varför han / hon har avvisat felet?', 'Det är inte mitt fel' etc. ,).

Vad du kommer att lära dig:

Vilka är egenskaperna hos en bra programfelrapport?

Vem som helst kan skriva en felrapport. Men inte alla kan skriva en effektiv Bug-rapport.

Du bör kunna skilja mellan en genomsnittlig felrapport och en bra felrapport. Hur skiljer man mellan en bra och dålig felrapport? Det är väldigt enkelt, använd följande egenskaper och tekniker för att rapportera ett fel.

Egenskaper och tekniker inkluderar

# 1) Att ha ett tydligt specificerat felnummer: Tilldela alltid ett unikt nummer till varje felrapport. Detta kommer i sin tur att hjälpa dig att identifiera felrapporten. Om du använder något automatiserat felrapporteringsverktyg genereras detta unika nummer automatiskt varje gång du rapporterar felet.

Notera numret och en kort beskrivning av varje fel som du rapporterade.

# 2) Reproducerbart: Om ditt fel inte kan reproduceras kommer det aldrig att fixas.

Du bör tydligt nämna stegen för att reproducera felet. Anta inte eller hoppa över något reproduceringssteg. Ett fel som beskrivs steg för steg är enkelt att reproducera och fixa.

# 3) Var specifik: Skriv inte en uppsats om problemet.

Var specifik och till sak. Försök att sammanfatta problemet i minsta ord men ändå på ett effektivt sätt. Kombinera inte flera problem även om de verkar vara lika. Skriv olika rapporter för varje problem.

Effektiv felrapportering

Felrapportering är en viktig aspekt av programvarutestning. En effektiv Bug-rapport kommunicerar bra med utvecklingsteamet och undviker förvirring eller felkommunikation.

En bra felrapport borde vara tydlig och kortfattad utan några saknade nyckelpunkter. Varje brist på tydlighet leder till missförstånd och bromsar också utvecklingsprocessen. Felskrivning och rapportering är ett av de viktigaste men försummade områdena i testets livscykel.

Bra skrivande är mycket viktigt för att arkivera ett fel. Den viktigaste punkten som en testare bör komma ihåg är att inte använda en kommandoton i rapporten. Detta bryter moral och skapar en ohälsosam arbetsrelation. Använd en suggestiv ton.

Antag inte att utvecklaren har gjort ett misstag och därmed kan du använda hårda ord. Innan du rapporterar är det lika viktigt att kontrollera om samma fel har rapporterats eller inte.

Ett dubblettfel är en börda i testcykeln. Kontrollera hela listan över kända buggar. Ibland kan utvecklarna ha känt till problemet och ignorerat för en framtida release. Verktyg som Bugzilla som automatiskt söker efter dubbletter kan också användas. Det är dock bäst att manuellt söka efter dubbletter.

Importinformationen som en felrapport måste kommunicera är 'Hur?' och var?' Rapporten ska tydligt svara på hur testet utfördes och var defekten inträffade exakt. Läsaren bör enkelt reproducera felet och hitta var felet är.

Tänk på att mål att skriva felrapporten är att göra det möjligt för utvecklaren att visualisera problemet. Han / hon bör tydligt förstå defekten från Bug-rapporten. Kom ihåg att ge all relevant information som utvecklaren söker.

Tänk också på att en buggrapport skulle bevaras för framtida bruk och bör vara välskriven med nödvändig information. Använd meningsfulla meningar och enkla ord för att beskriva dina buggar. Använd inte förvirrande uttalanden som slösar granskarens tid.

Rapportera varje fel som en separat fråga. Om det finns flera problem i en enda felrapport kan du inte stänga den om inte alla problemen är lösta.

i vilken fas av systemets livscykel programvarutestning utförs

Därför är det bäst att dela upp problemen i separata buggar . Detta säkerställer att varje fel kan hanteras separat. En välskriven buggrapport hjälper en utvecklare att reproducera felet i sin terminal. Detta hjälper dem också att diagnostisera problemet.

Hur rapporterar jag ett fel?

Använd följande enkla felrapportmall:

Detta är ett enkelt felrapportformat. Det kan variera beroende på vilket felrapportverktyg du använder. Om du skriver en buggrapport manuellt måste vissa fält nämnas specifikt som Bug-numret, som ska tilldelas manuellt.

Reporter: Ditt namn och e-postadress.

Produkt: I vilken produkt du hittade detta fel.

Version: Produktversionen om någon.

Komponent: Dessa är de viktigaste delmodulerna för produkten.

Plattform: Nämn maskinvaruplattformen där du hittade detta fel. De olika plattformarna som 'PC', 'MAC', 'HP', 'Sun' etc.

Operativ system: Nämn alla operativsystem där du hittade felet. Operativsystem som Windows, Linux, Unix, SunOS, Mac OS. Nämn de olika OS-versionerna som Windows NT, Windows 2000, Windows XP etc, om tillämpligt.

Prioritet: När ska ett fel åtgärdas? Prioritet ställs i allmänhet från P1 till P5. P1 som “fixa buggen med högsta prioritet” och P5 som “Fixa när tiden tillåter”.

Allvarlighetsgrad: Detta beskriver effekten av felet.
Typer av svårighetsgrad:

oracle pl sql intervjufrågor för 5 års erfarenhet
  • Blockerare: Inget ytterligare testarbete kan göras.
  • Kritisk: Programkrasch, förlust av data.
  • Större: Större funktionsförlust.
  • Mindre: Mindre funktionsförlust.
  • Trivial: Några UI-förbättringar.
  • Förbättring: Begäran om en ny funktion eller någon förbättring av den befintliga.

Status: När du loggar in buggen i något felspårningssystem är buggstatusen som standard ”Ny”.
Senare går buggen igenom olika stadier som Fixed, Verified, Reopen, Won't Fix, etc.

=> Klicka här för att läsa mer om den detaljerade Bug Life Cycle.

Tilldela till: Om du vet vilken utvecklare som är ansvarig för den specifika modulen där felet uppstod kan du ange e-postadressen för utvecklaren. Annars ska du hålla det tomt eftersom detta tilldelar felet till modulägaren om inte chefen tilldelar felet till utvecklaren. Lägg eventuellt till chefens e-postadress i CC-listan.

URL: Sidans URL där felet uppstod.

Sammanfattning: En kort sammanfattning av buggen mestadels i 60 ord eller lägre. Se till att din sammanfattning återspeglar vad problemet är och var det är.

Beskrivning: En detaljerad beskrivning av felet.

Använd följande fält för beskrivningsfältet:

  • Reproducera steg: Det är uppenbart att nämna stegen för att reproducera felet.
  • Förväntat resultat: Hur applikationen ska bete sig i de ovan nämnda stegen.
  • Faktiskt resultat: Vad är det faktiska resultatet av att köra ovanstående steg, dvs. felbeteendet.

Det här är de viktiga stegen i felrapporten. Du kan också lägga till 'Rapporttyp' som ett ytterligare fält som beskriver buggtypen.

Rapporttyper inkluderar:

1) Kodningsfel
2) Designfel
3) Nytt förslag
4) Dokumentationsfråga
5) Hårdvaruproblem

Viktiga funktioner i din felrapport

Nedan följer de viktiga funktionerna i felrapporten:

# 1) Felnummer / id

Ett felnummer eller ett identifieringsnummer (som swb001) underlättar felrapportering och hänvisning till ett fel. Utvecklaren kan enkelt kontrollera om ett visst fel har åtgärdats eller inte. Det gör hela test- och testprocessen smidigare och enklare.

# 2) Felrubrik

En buggtitel läses oftare än någon annan del av felrapporten. Det borde säga allt om vad som kommer i felet.

Bug-titeln bör vara tillräckligt suggestiv för att läsaren ska kunna förstå den. En tydlig buggtitel gör det lätt att förstå och läsaren kan veta om felet har rapporterats tidigare eller har åtgärdats.

# 3) Prioritet

Baserat på felets allvar kan en prioritet ställas in för den. Ett fel kan vara en Blocker, Critical, Major, Minor, Trivial eller ett förslag. En buggprioritet från P1 till P5 kan ges så att de viktiga visas först.

# 4) Plattform / miljö

OS- och webbläsarkonfigurationen är nödvändig för en tydlig felrapport. Det är det bästa sättet att kommunicera hur felet kan reproduceras.

Utan den exakta plattformen eller miljön kan applikationen fungera annorlunda och buggen i testarens ände kanske inte replikeras i utvecklarens ände. Så det är bäst att tydligt nämna den miljö där felet upptäcktes.

# 5) Beskrivning

Felbeskrivning hjälper utvecklaren att förstå felet. Det beskriver problemet som uppstått. Den dåliga beskrivningen kommer att skapa förvirring och slösa bort tid för utvecklarna och testarna också.

Det är nödvändigt att kommunicera tydligt om effekten av beskrivningen. Det är alltid bra att använda fullständiga meningar. Det är en bra praxis att beskriva varje problem separat istället för att smula dem helt. Använd inte termer som 'Jag tror' eller 'Jag tror'.

# 6) Åtgärder för att reproducera

En bra felrapport bör tydligt nämna stegen för att reproducera. Stegen bör innehålla åtgärder som orsakar felet. Gör inte generiska uttalanden. Var specifik i stegen som ska följas.

Ett bra exempel på ett välskrivet förfarande ges nedan

Steg:

  • Välj produkt Abc01.
  • Klicka på Lägg i kundvagn.
  • Klicka på Ta bort för att ta bort produkten från kundvagnen.

# 7) Förväntat och faktiskt resultat

En felbeskrivning är ofullständig utan de förväntade och faktiska resultaten. Det är nödvändigt att beskriva vad som är resultatet av testet och vad användaren kan förvänta sig. Läsaren borde veta vad testresultatet är korrekt. Det är tydligt att nämna vad som hände under testet och vad som blev resultatet.

# 8) Skärmdump

En bild säger mer än tusen ord. Ta en skärmdump av förekomsten av misslyckande med rätt textning för att markera defekten. Markera oväntade felmeddelanden med ljusröd färg. Detta uppmärksammar det önskade området.

Några bonustips för att skriva en bra felrapport

Nedan följer några ytterligare tips för att skriva en bra felrapport:

# 1) Rapportera problemet omedelbart

Om du hittar något fel under testningen behöver du inte vänta med att skriva en detaljrapport senare. Skriv istället felrapporten omedelbart. Detta kommer att säkerställa en bra och reproducerbar Bug-rapport. Om du bestämmer dig för att skriva felrapporten senare är det stora chanser att missa de viktiga stegen i din rapport.

# 2) Reproducera buggen tre gånger innan du skriver en bugrapport

Din bugg ska vara reproducerbar. Se till att dina steg är robusta nog för att reproducera felet utan tvetydighet. Om din bugg inte kan reproduceras varje gång kan du fortfarande skicka en bugg där den periodiska karaktären av felet nämns.

# 3) Testa samma fel förekomst på andra liknande moduler

Ibland använder utvecklaren samma kod för olika liknande moduler. Så det finns högre chanser för att felet i en modul ska uppstå i andra liknande moduler också. Du kan till och med försöka hitta den allvarligare versionen av felet du hittade.

# 4) Skriv en bra buggsammanfattning

Felöversikt hjälper utvecklarna att snabbt analysera buggen. En rapport av dålig kvalitet ökar onödigt utvecklings- och testtiden. Kommunicera bra med din bugrapportsammanfattning. Tänk på att felsammanfattningen används som en referens för att söka efter felet i bugginventeringen.

# 5) Läs felrapporten innan du trycker på knappen Skicka

Läs alla meningar, formuleringar och steg som används i felrapporten. Se om någon mening skapar tvetydighet som kan leda till misstolkning. Vilseledande ord eller meningar bör undvikas för att ha en tydlig felrapport.

# 6) Använd inte Stötande språk

Det är trevligt att du gjorde ett bra arbete och hittade ett fel men inte använda den här krediten för att kritisera utvecklaren eller för att attackera någon individ.

Slutsats

Ingen tvekan om att din felrapport ska vara ett dokument av hög kvalitet.

Fokusera på att skriva bra felrapporter och spendera lite tid på den här uppgiften eftersom det här är den viktigaste kommunikationspunkten mellan testaren, utvecklaren och chefen. Chefer bör skapa en medvetenhet om sitt team om att skriva en bra felrapport är det primära ansvaret för alla testare.

vanliga frågor om c ++ intervju

Din ansträngning för att skriva en bra Bug-rapport sparar inte bara företagets resurser utan skapar också ett bra förhållande mellan dig och utvecklarna.

För en bättre produktivitet, skriv en bättre felrapport.

Är du expert på att skriva en Bug-rapport? Dela gärna dina tankar i kommentarfältet nedan.

Rekommenderad läsning

^