JiraVejledning

Den gode fejlrapport

Målgruppe: Personer som opretter fejlrapporter direkte i Bugzilla fejlrapporteringssystemet.

Bugzilla bruges efter aftale med KST og kun af IT-afdelingerne samt de udpegede superbrugere. Du finder Bugzilla her: https://bugs.statsbiblioteket.dk/intern/

Til AU-bibliotekerne genereres der automatisk en daglig rapport fra Bugzilla. Rapporten kan ses her: http://wiki.statsbiblioteket.dk/AlephWiki/AU-bugoversigt

Indledning

Systematisk fejlrapportering er en relativt ny disciplin i SB-regi. Det er typisk brugerne af IT systemerne, der rapporterer fejlene, og det giver ikke sig selv, hvad IT har behov for at vide for at kunne rette fejlen. Dette resulterer i værste fald i, at fejlrettelsen bliver forsinket, fordi de nødvendige oplysninger først skal fremskaffes. Denne skrivelse forsøger at give nogle retningslinier for, hvad der kendetegner en god fejlrapport.

En fejls livscyklus

Når fejlen rapporteres i Bugzilla er første skridt for IT at tildele fejlen til en person. Når dette er sket, skifter fejlen status til assigned. Dette betyder ikke nødvendigvis, at der arbejdes på fejlen med det samme.

Der er forskellige scenarier for, hvordan en fejlrapport kan ende. Den mest gængse er, at fejlen bliver rettet. Dette resulterer i, at fejlen skifter status til fixed. Desuden vil der, afhængigt af hvor alvorlig fejlen er, blive lavet en ny version af den relevante applikation, som bliver lagt i staging miljøet. Staging miljøet er det sted, hvor en ny version testes, før den endeligt bliver sat i drift.

Når den nye version er lagt i stage, kan brugeren teste, at fejlen rent faktisk er blevet rettet. Hvis det er tilfældet, kan brugeren lukke fejlrapporten ved at skifte status til closed. Dette er et signal til IT om, at applikationen er klar til drift.

Hvad bliver fejlrapporten brugt til?

Det første IT-medarbejderen gør er, at forsøge at gentage det scenarie, som resulterede i fejlen. Dette er næsten altid udgangspunktet for at rette fejlen. Hvis der ikke er nok oplysninger i fejlrapporten, vil medarbejderen i stedet kontakte rapportøren indtil der er nok oplysninger til at gentage fejlscenariet.

Desuden bliver fejlrapporterne brugt til at prioritere, hvilke fejl der har højest prioritet at rette. Dette prioriteringsarbejde gøres typisk i samarbejde med slutbrugerne.

Hvad skal der stå i en fejlrapport?

Som nævnt vil IT-medarbejderen oftest forsøge at gentage fejlscenariet. Det betyder, at der i fejlrapporten skal stå oplysninger nok til, at medarbejderen kan udføre de samme handlinger, som rapportøren udførte for at udløse fejlen. Mere specifikt betyder det, at fejlrapporten skal indeholde følgende:

• Hvornår opstod fejlen? Der er typisk tilknyttet logfiler til applikationen, som IT-medarbejderen har fordel af at undersøge. Eksempel: Fejlen opstod den 5. marts ca. kl. 8:13

• Hvilke handlinger udførte jeg for at udløse fejlen? Eksempel (fortsat): Jeg klikkede på “opret depot” og lavede et nyt depot til Aarhus Kommunes Biblioteker med sprog arabisk, type e-sag og ordrenummer 123. Dernæst inddaterede jeg den første stregkode 3359950968.

• Hvad skete der? Eksempel (fortsat). Applikationen rapporterede følgende fejl tilbage: “har ingen DBC MARC post. Eksemplaret er muligvis for nyt”.

• Hvad ville jeg have forventet, at der skete? Eksempel (fortsat): Da eksemplaret er flere måneder gammelt ville jeg forvente, at inddateringen gik igennem uden problemer.

• Supplerende oplysninger. Man kan med fordel vedhæfte et screendump af fejlsituationen. Der kan være oplysninger om fejlen på skærmen, der er brugbare for IT-medarbejderen, såsom et såkaldt stack trace af, hvad der gik galt. Det er som regel den nemmeste måde at få alle de nødvendige oplysninger med, og der kan være subtile vink man ikke som slutbruger er opmærksom på, som eksempelvis hvor på siden fejlmeddelsen står, der kan være nyttige for IT-medarbejderen.

Afsluttende bemærkninger

Følger man ovenstående opskrift, vil der i næsten alle tilfælde være nok oplysninger til, at IT-medarbejderen kan gå direkte igang med at diagnosticere, hvorfor fejlen opstår. Det kan være tidsskrævende at lave en god fejlrapport, men det burde lønne sig ved, at fejl hurtigere bliver rettet.