Hur man skriver en felrapport med exempel

Vad är Bug Report? Varför behöver du en bra felrapport?

Buggrapporten är ett viktigt dokument i STLC som erbjuder olika fördelar för testteamet. Den håller track av alla defekter, buggar, fel och andra avvikelser som hittats under programvarutestning och rapporterar dem.

Syftet med denna eftertestningsdokumentation är att ge information till det berörda teamet av professionella om nivån på buggar som uppstår under testprocessen.

Dina mjukvaruutvecklingsingenjör kan bli uppmärksammad på alla fel och problem som finns i programvaran med hjälp av den här typen av rapport. Det låter dig också ta reda på vad som är fel med ett fel, så att du kan använda den bästa metoden för att åtgärda det. Det hjälper dig också att spara tid och pengar genom att hjälpaping du upptäcker buggar och problem.

Varför ska du bry dig om bra buggförklaringar?

Här är punkten som du måste tänka på för att skriva en bra, detaljerad programvarufelrapport:

• Det fungerar som en guide för att undvika samma bugg i framtida utgåvor.
• Spara tid för kommunikation (e-post, samtal).
• Less arbeta för utvecklare (de kommer att göra precis vad du vill).
• Du kommer att ha färre flaskhalsar i projektet; buggar kommer att fixas snabbare och mer effektivt sätt.

Hur man skriver felrapport (mall för felrapport)

Det finns ingen exakt mall för felrapportering, eftersom det beror på ditt fel-trackungssystem. Din mall kan vara annorlunda.

Följande vanliga fält behövs dock alltid när du vill skriva en felrapport:

• Fel-id/titel.
• Allvarlighet och prioritet.
• BESKRIVNING
• Miljö
• Steg för att reproducera.
• Förväntat resultat.
• Faktiskt resultat.
• Bilagor (skärmdumpar, videor, text)

Låt oss titta på alla dessa buggbekämpande komponenter en efter en:

1) Titel/fel-ID:

Varje bugg bör ges ett unikt identifikationsnummer. Verktyg för felrapportering bör vara unika nummer för de nyligen uppkomna buggarna så att vi enkelt kan identifiera felet.

Exempel:

❌ Dåligt: ​​"Jag kan inte se produkten när jag igen, tyrp gör det inte."

• Vag
• Aggressiv
• För ordrik

ber om att en lösning implementeras.

✅ Bra: “CART – Nya varor läggs till i varukorgen som inte dyker upp”.

• Denna typ av titel lokaliserar omedelbart problemet (CART)
• Den fokuserar på det faktiska tekniska problemet.

2) Felens svårighetsgrad:

Felens svårighetsgrad är en mycket viktig faktor i felrapporten. Den beskriver effekten av defekten på applikationens prestanda.

• Blockerare: Det här felet gör att appen misslyckas.
• Major: Ett kritiskt fel indikerar en stor förändring i affärslogiken.
• Mindre: Ett problem som inte påverkar applikationens funktionalitet men som påverkar de förväntade resultaten.
• Trivial: Det påverkar inte appens funktion eller funktion. Det kan vara ett typografiskt fel.

3) Felprioritet:

Följande är den allmänna graderingen för att bestämma bugprioritet:

• Hög: Det täcker allt som påverkar flödet eller blockerar appanvändning.
• Medium: Det påverkar användarupplevelsen negativt.
• Mindre: Alla andra fel som (stavfel, saknade ikoner, layoutproblem, etc.).

4) Miljö:

En bugg kan dyka upp i en specifik miljö och inte i andra. Till exempel, ibland dyker det upp en bugg när du kör webbplatsen på Firefox, eller ett appfel endast när den körs på en Android enhet och fungerar bra på iPhone.

Dessa buggrapporter kan endast identifieras med testning över webbläsare eller flera enheter. Så när man rapporterar felet bör QA:er kunna specificera om felet ska observeras i en eller flera specifika miljöer.

5) Sammanfattning:

Att bara lägga till titeln i felrapporten tjänar dock inte syftet. Så om din titel inte räcker till kan du lägga till en kort rapportsammanfattning.

Din sammanfattning i så få ord som möjligt inklusive när och hur felet inträffade. Din titel och buggbeskrivning bör också användas i sökningar, så du måste se till att du har täckt viktiga nyckelord.

Exempel:

• dåligt: "Jag försökte lägga till saker i testet, och ingenting dök upp när jag gjorde det eller klickade på knappen."
• Bra: "När jag försökte lägga till [PRODUKT] i butikenping varukorgen, men ingenting hände när jag klickade på knappen "lägg till" på webbsidan med den specifika produktöversikten.”

6) Steg för att reproducera:

När du rapporterar ett fel är det viktigt att specificera stegen för att återskapa det. Du bör också inkludera åtgärder som kan orsaka buggen. Här, gör inga allmänna påståenden.

Var specifik om stegen att följa:

Här är ett exempel på välskriven procedur:

Steg:

1. Välj produkt X1.
2. Klicka på Lägg till i varukorg.
3. Klicka på Ta bort för att ta bort produkten från kundvagnen.

7) Förväntat resultat:

I buggrapporter är det viktigt att beskriva det förväntade resultatet per teknisk uppgift, testfallsutfallsdesign eller enligt testarens åsikt. Allt detta hjälper utvecklare att fokusera på att snabbt hitta nödvändig information.

Till exempel:

Obligatoriska fält ska markeras i rött efter att du klickat på knappen "Skicka".

8) Faktiskt resultat:

Som namnet antyder, beskriver detta fält den faktiska effekten av buggen. Det är mycket viktigt att skriva en tydlig beskrivning av det faktiska resultatet.

Till exempel:

Obligatoriska fält är markerade i grön färg efter att du klickat på knappen "Skicka".

9) Bilagor (skärmdumpar och videor):

I felrapporter är det bästa praxis att bifoga filer till felrapporter vilket gör det lättare att uppfatta information när du behöver visa den visuellt:

Till exempel:

• Skärmdump: Skärmdumpar kan enkelt utarbeta misstag i programmet; är bekvämt när felet är markerat med en specifik anteckning, cirkel eller pilbild).
• video: Ibland är det svårt att beskriva buggen med ord, så det är bättre att skapa en video så att utvecklaren kan åtgärda defekten i programmet).

10) Berörd version:

Det är den berörda mjukvaruversionen som felet rapporteras.

11) Fixversion:

Det är mjukvaruversionen där buggen åtgärdas. Så när kvalitetskontrollanten som rapporterade felet kontrollerar om det är åtgärdat, använder han rätt programvaruversion.

12) Target version:

Målversionen där en bugg ska riktas mot för att fixas. Så när utvecklingsteamet arbetar med att fixa en bugg, riktar de sig oftast mot en viss applikationsversion.

13) Stängningsdatum:

Det är datumet då buggen stängs av mjukvarutestteamet. Att stänga en bugg är en viktig och integrerad del av mjukvarutestning.

14) Status:

När en ny bugg skapas bör dess status vara öppen. Efter det går det igenom stadier som Pågår, Fixat, Running, Reopen, etc.

Tips för att skriva felrapporter

Här är några viktiga tips som du bör komma ihåg när du skriver en effektiv felrapport:

• Var specifik när du skapar felrapporter. Se till att du inte inkluderar några värdelösa eller irrelevanta fakta.
• Du måste rapportera felet omedelbart så snart det upptäcks.
• Förbered rapporten i detalj för att ge utvecklaren möjlighet att använda fakta och information för att felsöka problemet.
• Du bör testa samma buggförekomst på andra liknande moduler för validering.
• Revse felrapporten minst en gång innan du skickar in den.
• Du bör se till att felrapporten innehåller en beskrivning av endast ett fel.
• Slutligen ska du inte vara rädd för att be projektledaren om hjälp om du känner dig oklart om något.

Verktyg för felrapportering

Felrapporteringsprocessen, som utförs manuellt, utförs nu med olika felrapporteringsverktyg som finns på marknaden.

• Roundup
• Zoho-bugg Tracker
• Bugzilla

Du kan kolla vår detaljerade recension av bästa felrapporteringsverktyget.

Vanligt problem och lösning när du skriver en felrapport:

Här är några vanliga problem och deras lösningar när du skriver en felrapport:

Exempel på felrapport	Problem
När du multiplicerar 2 med 3 blir svaret positivt.	Rapportera mönstret, inte ett exempel.
Listan kommer att ordnas i alfabetisk ordning när du lägger till ett nytt objekt för att undvika detta.	Beskriv inte bara vad som är fel
Till exempel: För att bli det måste du öppna din webbläsare och skriva in webbplatsens URL. Du hittar det första fältet, "användarnamn", felstavat.	Alltid rakt på sak (berätta aldrig historien!).
Kundens namn i rapporten är felstavat. Prioritet: Hög, Allvarlighet: Hög	Blanda aldrig prioritet och svårighetsgrad.
Skatteberäkningsformeln är FEL !!??	Använder inte CAPS, röda bokstäver, röda cirklar, '!',
Jag tycker inte att hemsidan Ul design är bra.	Använd inte ditt omdöme.
Exempel på otydlig beskrivning: Om vår diskussion idag, vänligen gör den åtgärd som krävs för den här sidan.	Gör din beskrivning begriplig för alla.
Sidbakgrunden ska vara blå, orange eller grön, eller så kan du göra den svart eller vit. Detta är inte bra då det är oklart vad som behövs från webbutvecklings- och designteamet	Minimera alternativen
Skatteberäkningsformeln fungerar ibland inte som förväntat.	Den gyllene regeln: Använd inte ordet "Ibland".

Exempel på felrapport

Här är ett litet exempel på en felrapport:

[MITT KONTO] Understrykning visas när muspekaren flyttas över Uppdatera-knappen.

DescriptJon: Vi måste ta bort understrykningen när musen överskrids på knappen Uppdatera i avsnittet Mitt konto.

Länk: http://test.com/mv-account/

Webbläsare/OS: Chrome 25. OSX Yosemite 10.10.2

Steg för att reproducera:

1. Gå till www.test.com

2. Logga in via inloggningsuppgifter

3. Navigera till Mitt konto

4. För muspekaren över knappen Uppdatera

Faktiskt resultat: det finns en understrykning.

Förväntat resultat: ingen understrykning.

Inloggningsdata: test@test.com / mysecretpass12

Måste undvika misstag vid felrapportskrivning

Här är några viktiga misstag som du bör undvika när du skriver en felrapport:

• Skriv inte om ditt missnöje och inkludera aldrig dina personliga känslor.
• Det irriterar folk som vill fokusera på uppgiften när du överbelasta ditt inlägg med många uttryckssymboler.
• Överbelasta aldrig ditt inlägg med utropstecken; det påskyndar inte arbetet.
• Ingen vill känna sig kränkt. Det förstör motivationen och bromsar insikten av problemet.