Når det forventede og det faktiske resultat i en test-afvikling ikke stemmer overens, er det nødvendigt at undersøge afvigelsen for at afgøre, om der er tale om en fejl eller ej. En sådan hændelse kan bunde i misforståelser under testafvikling, misforståelse i testcasen eller i testdata.
Når der er konstateret en hændelse, som forventeligt skyldes en fejl i kode, oprettes en fejlrapport som klart beskriver den konstaterede afvigelse. Man kan også vælge at rapportere alle hændelser fundet under testen, for første derefter at foretage de nødvendige undersøgelser. Det må være en afvejning i det enkelte projekt/den enkelte udviklingsopgave og i den enkelte testfase.
En fejlrapport indeholder oplysningerne herunder.
(SKAL TILPASSES AZURE)
Fejlrapportering | Beskrivelse |
|---|---|
Assignee | Angiv hvem opgaven skal assignes til. |
Components | Components kan bruges til at markere bugs til brug ved udtræk med filtre. |
Description | Testmiljø - angiv hvilket testmiljø, fejlen er fundet i. Version - angiv hvilken version af softwaren, fejlen er fundet i. Testfase og -type - angiv hvilken testfase (specifik testtype og run), fejlen er fundet i. Udførlig beskrivelse af fejlen. Beskriv step-by-step og eventuelt i punktform, hvordan fejlen kan reproduceres. Beskriv herunder, hvad det forventede resultat er kontra det faktiske resultat. Hvis muligt, angiv den forventede impact af fejlen (i forhold til det øvrige systen, i forhold til projektet, i forhold til brugerne, etc.) |
Epic link | Link til den epic, som fejlen omhandler. |
| Issuetype (hvis JIRA) | Bug |
Linked issues | Her kan fejlrapporten linkes til relevante Jira issues. Fx. reference til den testcase, hvor fejlen er fundet. Hvis en bug oprettes fra eksekveringssiden i Zephyr vil den automatisk være linket til testcasen. |
Prioritet | Her angives den forventede prioritet (blocking, critical, major, normal, minor). Prioritet kan ændres og bør besluttes af product owner eller systemansvarlig, alt efter testniveau og den konkrete udviklingsopgave. Prioriteten har betydning for, hvornår fejlen skal løses og siger ikke nødvendigvis noget om alvorsgraden eller impact. |
| Projekt | Angiv projektnavn. |
Summary | Lav en sigende overskrift |
Vedhæftet dokumentation | Vedhæft meget gerne yderligere dokumentation af fejlen (screenshots, stacktraces etc.) |