At vide, hvordan man udarbejder en effektiv fejlrapport, er en stor del af en softwaretesters arbejde med at opretholde kvalitetssikringen, så vi bruger meget tid på at logge fejl i vores fejlsporingsværktøjer. Det kan føles spændende at finde en fejl, især hvis det er et interessant scenarie. Men måden, vi rapporterer den på, kan være lige så vigtig som dens indvirkning på systemet.
En dårligt skrevet fejlrapport kan skabe meget friktion mellem teammedlemmer, især mellem testere og udviklere, hvilket kan skabe blokeringer for fejlrettelserne og i sidste ende ødelægge brugeroplevelsen.
I denne artikel vil jeg gennemgå vigtige detaljer, f.eks. hvordan man:
- Bliver god til fejlrapporter: Lær de vigtigste elementer, som enhver effektiv fejlrapport bør indeholde, for at strømline kommunikationen og fremskynde fejlrettelser.
- Styrker samarbejdet i teamet: Opdag, hvordan velskrevne fejlrapporter forebygger friktion mellem testere og udviklere og fører til mere smidige arbejdsgange.
- Gratis skabelon til download: Få en gratis fejlsporingsskabelon, som kan downloades, og kom hurtigt i gang med en effektiv fejlrapporteringsproces.
Vigtige elementer i en fejlrapport
Uanset hvilken type applikation du tester, hvad enten det er en desktop-, web- eller mobilapplikation eller et API-projekt, er der nogle vigtige elementer, som enhver god fejlrapport bør indeholde. De fleste fejlsporingssoftwareløsninger indeholder felter til disse elementer, herunder:
- ID: Hvis du bruger et projektstyringsværktøj som f.eks. Jira, tildeles der automatisk et ID til alle nye problemer, der oprettes. Der findes også teststyringsværktøjer til Jira til fejlsporing
- Titel/beskrivelse: Dette er en kort beskrivelse af problemet. Den bør være kortfattet nok til at være let at læse, men samtidig beskrivende nok til, at andre kan forstå, hvor problemet ligger. For eksempel: “sortering af elementer efter pris fungerer ikke, når der er anvendt et filter.”
- Trin til reproduktion: Medtag så mange relevante detaljer som muligt her. Sørg for, at enhver, der forsøger at reproducere problemet eller kontrollere rettelsen, kan gøre det ved blot at følge trinnene. Spring ikke trin over, fordi du antager, at alle implicit ved, at de skal udføre bestemte handlinger, selv hvis de ikke er nævnt; medtag dem i fejlrapporten.
- Forventede resultater: Antag igen ikke, at folk allerede ved, hvordan applikationen skal fungere. Hvis du naturligvis får en undtagelse i brugergrænsefladen, når du trykker på en knap, ved du, at det ikke er forventet. Jeg ville dog ikke sige, at det forventede resultat er “der udløses ingen undtagelse”, men snarere hvilken handling knappen skal udføre, dvs. “dialogboksen med indstillinger åbnes.”
- Faktiske resultater: Dette siger sig selv—du bør beskrive, hvad der sker i applikationen, når alle reproduktionstrinnene er udført.
- Alvorlighedsgrad: Dette repræsenterer den indvirkning, fejlen har på AUT.
- Prioritet: Hvor hurtigt fejlen bør rettes. En højere prioritet betyder, at fejlen skal placeres højere i backloggen og rettes hurtigere.
Have an account? Log In
Andre vigtige oplysninger, der bør medtages
Ud over de elementer, der er nævnt ovenfor, kan andre oplysninger være relevante, især når du indtaster data i et fejlrapporteringsværktøj. De kan afhænge af projekttypen, projektkravene eller endda selve fejlen:
- Softwareversion: Buildnummeret, hvor fejlen blev identificeret. Dette kan hjælpe med at isolere de builds, hvor problemet potentielt blev introduceret, og identificere den kode, der forårsagede det.
- Vedhæftede filer: Disse er måske ikke altid nødvendige eller tilgængelige, men de tilfører normalt stor værdi. Overvej at vedlægge skærmbilleder eller optagelser af det fundne problem, logfiler, stack-traces, netværksanmodninger og -svar osv.
- Testdata: Nogle gange kan de fejl, vi finder, kun reproduceres for bestemte datasæt. Hvis det er tilfældet, skal du sørge for at medtage dem, enten i trinnene til reproduktion (f.eks. “log ind med brugeren andreea@theqalead.com”) eller i et specifikt felt i fejlsporingsværktøjet.
- Miljøoplysninger: Hvis fejlen kun kan reproduceres på et bestemt operativsystem, i en bestemt browser eller i et bestemt udviklingsmiljø, skal du nævne det.
Tips til at udarbejde en god fejlrapport
- Begræns dig selv til én enkelt fejl pr. rapport. Hvis du opdager flere fejl i de samme områder, kan du linke dem til dit system til fejlsporing. Hvis du inkluderer mere end én fejl, kan det skabe forvirring og forsinke de potentielle fejlrettelser.
- Kontrollér dit system til fejlsporing for at sikre, at fejlen ikke allerede er blevet rapporteret. Hvis den allerede er oprettet, skal du tilføje alle relevante oplysninger, du har fundet, og som ikke blev indsendt i den oprindelige fejlrapport.
- Prøv at genskabe fejlen mere end én gang. Du kan forsøge at finde den korteste måde at genskabe den på (ved at bruge så få trin som muligt).
- Fortab dig ikke i irrelevante detaljer. Fejlrapporten og trinnene skal være nemme at læse og følge.
- Gør dig ikke antagelser om, hvorfor fejlen opstår (medmindre du er 100 % sikker på, at du ved, hvad der forårsagede den).
Skabelon til fejlrapport
Nu vil jeg gerne dele nogle skabeloner til fejlrapporter med dig. Du kan kopiere eller ændre dem i overensstemmelse med dit projekts behov.
Skabelon til Jira-fejlsporing
Jira er et meget almindeligt værktøj til problemsporing fra Atlassian. Hvis dit team bruger det, er fejltypen sandsynligvis allerede konfigureret. Som tester eller leder af et softwareudviklingsteam kan du opsætte en arbejdsgang til fejlsporing for fejlens livscyklus (denne funktion er en af de mange fordele ved software til problemsporing).
Du kan også tilføje brugerdefinerede felter i Jira, f.eks. til miljøet eller et unikt felt, hvor den testede funktionalitet tilføjes. Eller du kan tilføje en standardbeskrivelse med alle de oplysninger, du ønsker skal inkluderes i hver fejlrapport. Her er en, jeg har oprettet:
Når jeg nu vil oprette en ny fejl, vil disse oplysninger være udfyldt på forhånd. Her er min fejlskabelon i Jira, der bruger brugerdefinerede felter og en standardbeskrivelse:
Den indeholder de vigtige oplysninger, som vi sagde, at fejlen skal indeholde:
- En titel (”Eksempelfejl”)
- I beskrivelsen: forudsætningerne, trinnene til at genskabe fejlen samt de forventede og faktiske resultater
- Et brugerdefineret felt til miljøet
- En alvorlighedsgrad og en prioritet, valgt fra rullemenuer med foruddefinerede værdier
- Jeg lod feltet for ansvarlig stå tomt. Afhængigt af konventionerne i dit projekt kan nye fejl automatisk tildeles et bestemt teammedlem, eller den, der begynder at arbejde på den, kan tildele den til sig selv
- En etiket – dette kan f.eks. være nyttigt, hvis du vil spore, hvilken funktionalitet der er påvirket
- En frist – den kan muligvis ikke færdiggøres, før opgaveefterslæbet er blevet prioriteret
- Rapportøren (som i dette tilfælde automatisk udfyldes med den Jira-bruger, der oprettede fejlen)
Jira har valgfrit flere integrationer, og fejlen kan linkes til testcases, Git-grene eller endda pull requests.
Du kan også bruge deres skabelon til fejlsporing som projektskabelon, hvis du kun har brug for Jira til fejlsporing og ikke arbejder i et agilt miljø.
More Articles
Excel-skabelon til fejlsporing
Nogle teams bruger muligvis regneark til deres system til fejlsporing. Jeg synes, de er nyttige til meget små projekter, hvor det simpelthen ikke kan betale sig at opsætte et værktøj til problemsporing, eller til rapportering af fejl i nye funktioner, der stadig er under udvikling.
Du kan bruge Google Sheets/Docs eller Microsoft Excel/Word – uanset hvad kan en fejlskabelon se sådan ud:
Kolonnerne afspejler de oplysninger, rapporten bør indeholde:
- ID'et (Excel ved, hvordan værdien automatisk øges, hver gang en ny række tilføjes)
- En titel
- Trinnene til at reproducere
- Forventede og faktiske resultater
- Indberetterens navn
- Alvorlighedsgrad og fejlens prioritet—her brugte jeg rullemenuer, fordi værdierne bør være forudindstillet
- Miljø
- Yderligere oplysninger: Dette er til alt andet, der er værd at bemærke, og som ikke passer ind i de andre kolonner
Afsluttende tanker
At skrive en god fejlrapport for software er en vigtig færdighed for softwaretestere, så vær ekstra opmærksom på de bedste praksisser, der er forklaret ovenfor. Du kan også bruge eksemplerne på skabeloner til fejlsporingsværktøjer, som jeg har angivet. De kan tilpasses de forskellige værktøjer, du bruger, såsom Trello eller Asana.
Hvis du kunne lide dette indhold, så abonner på The QA Lead-nyhedsbrevet for at holde kontakten med flere nyheder og tendenser inden for softwaretestprocessen!
