Varför en bra felrapport?

Om din felrapport är effektiv är chansen större att den åtgärdas. Så att åtgärda ett fel beror på hur effektivt du rapporterar det. Att rapportera ett fel är inget annat än skicklighet och jag kommer att förklara hur man uppnår denna skicklighet.

”Poängen med att skriva en problemrapport (felrapport) är att få fel åtgärdat” – av Cem Kaner. Om en testare inte rapporterar ett fel på rätt sätt kommer programmeraren sannolikt att avvisa felet och säga att det inte går att reproducera.

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

Vad är egenskaperna hos en bra felrapport om programvara?

Alla kan skriva en felrapport. Men alla kan inte skriva en effektiv felrapport.

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

Kännetecken 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 verktyg för felrapportering kommer detta unika nummer att genereras automatiskt varje gång du rapporterar felet.

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

#2) Reproducerbar: Om felet inte kan reproduceras kommer det aldrig att åtgärdas.

Du bör tydligt ange stegen för att reproducera felet. Du får inte anta eller hoppa över något steg för att reproducera felet. Ett fel som beskrivs steg för steg är lätt att reproducera och åtgärda.

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

Var specifik och gå rakt på sak. Försök att sammanfatta problemet med ett minimum av ord men ändå på ett effektivt sätt. Kombinera inte flera problem även om de verkar vara likartade. Skriv olika rapporter för varje problem.

Effektiv felrapportering

Felrapportering är en viktig aspekt av programvarutestning. En effektiv felrapport kommunicerar väl med utvecklingsteamet och undviker förvirring eller missförstånd.

En bra felrapport ska vara tydlig och kortfattad utan att viktiga punkter saknas. Bristande tydlighet leder till missförstånd och fördröjer även utvecklingsprocessen. Att skriva och rapportera fel är ett av de viktigaste men försummade områdena i testningslivscykeln.

Godt skrivande är mycket viktigt för att lämna in ett fel. Den viktigaste punkten som en testare bör tänka på är att inte använda en kommenderande ton i rapporten. Detta bryter moralen och skapar en osund arbetsrelation. Använd en suggestiv ton.

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

Ett dubbelt fel är en belastning i testcykeln. Kontrollera hela listan över kända buggar. Ibland kan utvecklarna ha känt till problemet och ignorerat det till en framtida version. Verktyg som Bugzilla som automatiskt söker efter dubbla fel kan också användas. Det är dock bäst att manuellt söka efter alla dubbla fel.

Den viktiga information som en felrapport måste förmedla är ”Hur?” och ”Var?”. Rapporten ska tydligt svara på hur testet utfördes och var felet inträffade exakt. Läsaren ska enkelt kunna reproducera felet och hitta var felet finns.

Håll i minnet att syftet med att skriva felrapporten är att göra det möjligt för utvecklaren att visualisera problemet. Han/hon bör tydligt förstå felet utifrån felrapporten. Kom ihåg att ge all relevant information som utvecklaren söker.

Tänk också på att en felrapport ska bevaras för framtida användning och bör vara välskriven med den information som krävs. Använd meningsfulla meningar och enkla ord för att beskriva dina felrapporter. Använd inte förvirrande uttalanden som slösar bort granskarens tid.

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

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

Hur rapporterar man ett fel?

Använd följande enkla mall för felrapportering:

Detta är ett enkelt format för felrapportering. Det kan variera beroende på vilket felrapporteringsverktyg du använder. Om du skriver en felrapport manuellt måste vissa fält anges specifikt, t.ex. felnummer, som ska tilldelas manuellt.

Reporter: Ditt namn och din e-postadress.

Produkt:

Version: Produkt: I vilken produkt du hittade felet: Produktversionen i förekommande fall.

Komponent:

Plattform: Detta är de viktigaste undermodulerna i produkten: Ange den maskinvaruplattform där du hittade felet. De olika plattformarna är ”PC”, ”MAC”, ”HP”, ”Sun” etc.

Operativsystem: Ange alla operativsystem där du hittade felet. Operativsystem som Windows, Linux, Unix, SunOS, Mac OS. Nämn även de olika operativsystemsversionerna, t.ex. Windows NT, Windows 2000, Windows XP etc., om tillämpligt.

Prioritet: När ska ett fel åtgärdas? Prioriteten fastställs i allmänhet från P1 till P5. P1 står för ”åtgärda felet med högsta prioritet” och P5 för ”åtgärda när tiden tillåter”.

Sverity (allvarlighetsgrad): Detta beskriver felets inverkan.
Typer av allvarlighetsgrad:

• Blocker: Inget ytterligare testarbete kan göras.
• Kritiskt: Applikationen kraschar, förlust av data.
• Störst: Större förlust av funktion.
• Mindre: Minor förlust av funktion.
• Trivialt: Vissa förbättringar av användargränssnittet.
• Förbättring: Begäran om en ny funktion eller en förbättring av en befintlig funktion.

Status:
Senare går felet igenom olika stadier som Fixed, Verified, Reopen, Won’t Fix, etc.

=> Klicka här för att läsa mer om den detaljerade livscykeln för fel.

Assign To: När du loggar felet i ett felspårningssystem är felets status som standard ”New”: Om du vet vilken utvecklare som är ansvarig för den modul där felet uppstått kan du ange den utvecklarens e-postadress. Annars kan du låta den vara tom, eftersom detta kommer att tilldela felet till modulägaren, annars kommer chefen att tilldela felet till utvecklaren. Lägg eventuellt till chefens e-postadress i CC-listan.

URL: Sidans URL där felet inträffade.

Summary: En kort sammanfattning av felet, oftast i 60 ord eller mindre. Se till att sammanfattningen återspeglar vad problemet är och var det finns.

Beskrivning:

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

• Reproducera steg: Ange tydligt de steg som behövs för att reproducera felet.
• Förväntat resultat: Ange tydligt de steg som behövs för att reproducera felet:
• Hur programmet ska bete sig vid de ovan nämnda stegen.
• Faktiskt resultat: Ange det faktiska resultatet:

Detta är de viktiga stegen i felrapporten. Du kan också lägga till ”Rapporttyp” som ytterligare ett fält som beskriver felrapportens typ.

Rapporteringstyperna inkluderar:

1) Kodningsfel
2) Konstruktionsfel
3) Nytt förslag
4) Dokumentationsproblem
5) Hårdvaruproblem

Väsentliga funktioner i din felrapport

Nedan anges de viktiga funktionerna i en felrapport:

#1) Felnummer/id

Ett felnummer eller ett identifikationsnummer (t.ex. swb001) gör det mycket enklare att rapportera fel och hänvisa till ett fel. Utvecklaren kan enkelt kontrollera om ett visst fel har rättats eller inte. Det gör hela testnings- och omtestningsprocessen smidigare och enklare.

#2) Feltitel

En feltitel läses oftare än någon annan del av felrapporten. Den bör säga allt om vad som kommer i felrapporten.

Felrapportens titel bör vara tillräckligt suggestiv för att läsaren ska kunna förstå den. En tydlig feltitel gör det lätt att förstå och läsaren kan veta om felet har rapporterats tidigare eller om det har rättats.

#3) Prioritet

Baserat på felets allvarlighetsgrad kan en prioritet sättas för det. Ett fel kan vara en Blocker, Critical, Major, Minor, Trivial eller ett förslag. En felprioritering från P1 till P5 kan ges så att de viktiga ses först.

#4) Plattform/miljö

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

Och utan den exakta plattformen eller miljön kan programmet bete sig annorlunda och felet hos testaren kanske inte kan reproduceras hos utvecklaren. Därför är det bäst att tydligt nämna den miljö där felet upptäcktes.

#5) Beskrivning

Felbeskrivning hjälper utvecklaren att förstå felet. Den beskriver det problem som uppstått. En dålig beskrivning skapar förvirring och slösar bort både utvecklarnas och testarnas tid.

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 metod att beskriva varje problem separat i stället för att smula sönder dem tillsammans. Använd inte uttryck som ”jag tror” eller ”jag tror”.

#6) Steg för att reproducera

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

Ett bra exempel på en välskriven procedur ges nedan

Steg:

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

#7) Förväntat och faktiskt resultat

En felbeskrivning är ofullständig utan förväntat och faktiskt resultat. Det är nödvändigt att beskriva vad som är resultatet av testet och vad användaren bör förvänta sig. Läsaren bör veta vad det korrekta resultatet av testet är. Nämn tydligt vad som hände under testet och vad resultatet blev.

#8) Skärmbild

En bild säger mer än tusen ord. Ta en skärmdump av feltillfället med korrekt textning för att belysa felet. Markera oväntade felmeddelanden med ljusröd färg. Detta drar uppmärksamheten till det område som krävs.

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

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

#1) Rapportera problemet omedelbart

Om du upptäcker ett fel när du testar, behöver du inte vänta med att skriva en detaljerad felrapport senare. Skriv istället felrapporten omedelbart. Detta kommer att säkerställa en bra och reproducerbar felrapport. Om du bestämmer dig för att skriva felrapporten senare är risken stor att du missar viktiga steg i din rapport.

#2) Reproducera felet tre gånger innan du skriver en felrapport

Ditt fel bör vara reproducerbart. Se till att dina steg är tillräckligt robusta för att reproducera felet utan tveksamheter. Om felet inte kan reproduceras varje gång kan du ändå skicka in en felrapport där du nämner felets periodiska karaktär.

#3) Testa samma felhändelse på andra liknande moduler

Ibland använder utvecklaren samma kod för olika liknande moduler. Det finns alltså större chanser att felet i en modul även uppstår i andra liknande moduler. Du kan till och med försöka hitta en allvarligare version av det fel du hittat.

#4) Skriv en bra sammanfattning av felet

En sammanfattning av felet hjälper utvecklarna att snabbt analysera felets karaktär. En rapport av dålig kvalitet kommer att öka utvecklings- och testtiden i onödan. Kommunicera väl med din sammanfattning av felrapporten. Tänk på att felresumén används som referens för att söka felet i felförteckningen.

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

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

#6) Använd inte kränkande språkbruk

Det är trevligt att du gjorde ett bra arbete och hittade ett fel, men använd inte denna förtjänst för att kritisera utvecklaren eller för att angripa någon enskild person.

Slutsats

Ingen tvekan om att din felrapport ska vara ett högkvalitativt dokument.

Fokusera på att skriva bra felrapporter och lägg lite tid på denna uppgift eftersom detta är den viktigaste kommunikationspunkten mellan testaren, utvecklaren och chefen. Cheferna bör skapa en medvetenhet hos sitt team om att skriva en bra felrapport är det främsta ansvaret för varje testare.