10 informationer som gør din fejlrapport selvforklarende for både forretningen og programmørerne

Transkript

1 10 informationer som gør din fejlrapport selvforklarende for både forretningen og programmørerne

2 Introduktion Uanset hvor mange informationer man tilføjer en fejlrapport er det vigtigt, at man beslutter niveauet af de informationer man tilføjer. Ved at have disse 10 punkter med kan man spare tid ved at mindske tilbageløb, fjerne flaskehalse og prioriterer sine fejl bedre. 2 ud af 6

3 1. En kort, unik og beskrivende titel Titlen er det første der bliver set og bør hurtigt give læseren en idé om så mange aspekter af problemet som muligt samtidigt med at være så kort at man kan bruge den i en mundtlig dialog. For det første bør titlen beskrive en funktion eller en handling. Da det er en fejlrapport, skal den beskrive noget, som man ikke forventer af funktionen eller handlingen. Eksempel: Undgå fraser som Der er fejl i login, da man jo allerede ved at det er en fejl, giver det ingen værdi. Kom i stedet lidt mere i dybden med problemet. Dette kunne være loginfunktionen returnerer en nul-reference exception, når man logger ind med ukendt bruger. Ved hjælp af en god titel kan man næsten allerede genskabe problemet uden at gå ned i detaljerne i indholdet af fejlrapporten. Det næste som er vigtigt ved titlen er at den er let forståelig for de eller de personer som skal prioriterer fejlenene. Det er typisk en testmanager eller defektmanager, som sammen med forretningen skal prioriterer hvilke fejl, som skal prioriteres højest. 2. Konfigurationen af systemet hvori fejlen blev fundet (herunder version, miljø, data og tilstand) Det er vigtigt at tilføje til fejlrapporten, hvilken version af systemet, hvori fejlen opstod. Det kan være vanskeligt at genskabe fejl, som er afhængig af versionen. Hvis man arbejder i flere miljøer (test-, integration- og produktionsmiljø) er det også en god ide at tilføje hvilket miljø fejlen opstod i. En fejl kan ofte have grund i det data som er brugt i testen, så det er naturligvis vigtigt at have det med og beskrive hvordan det er brugt. Det er ikke blot selve dataene som er brugt, men også måden det er brugt på. Er et CPR nummer for eksempel indtastet med eller uden bindestreg, et telefonnummer med eller uden international område kode med + eller 00 osv. Den sidste ting er, at tilføje hvilken stand systemet var i, før fejlen opstod. Dette kunne være en mobil som enten holdes vandret eller lodret, når man starter og gennemfører testen. 3 ud af 6

4 3. Trinvis forløb Det trinvise forløb er en information, som skal bruges for at genskabe fejlen. Det er derfor vigtigt at beskrive trin for trin med så mange detaljer som mulighedt, for at programmøren kan genskabe og rette fejlen. Oftest refereres de enkelte trin som repro-steps, som angiver hvordan fejl er fremfundet. 4. Resultatet af forløbet Det er her at selve fejlen beskrives i dybden. Det er sjælden nødvendigt at komme med længere forklaringer, men det er altid en god idé at komme med alt det relevante information som læseren af fejlrapporten vil kunne bruge. Det kunne eventuelt være den grundlæggende årsag til problemet (root cause analysis). Det bør også nævnes, om det er muligt at genskabe fejlen, dvs. om fejlen kan reproduceres. Denne information vil hjælpe til at løse fejlen og finde årsagen til hvordan denne er opstået. Al information som kan hjælpe til fejlsøgning og eventuel rettelse af fejlen bør beskrives hér. 5. Forventede Resultat I forlængelse af resultatet er det en god idé at beskrive hvad man havde af forventet resultat. Formelt set vil det være et krav som har været specificeret på et tidligere tidspunkt i livcyklussen, men det kan også ofte være en uhensigtsmæssighed som man finder og måske på et senere tidspunkt skal forklare for en som vurderer om det skal kategoriseres som en fejl eller et ændringsønske. I det første tilfælde skal man naturligvis henvise til hvilket krav der ikke opfyldes. I det andet tilfælde hvor det er uklart om det forventede resultat rent faktisk er et krav bør man så vidt muligt give en forklaring på hvorfor man forventer det man beskriver. 4 ud af 6

5 6. Navn på personen som fandt fejlen Dit navn skal selvfølgelig på fejlrapporten så den som senere får fejlrapporten kan indgå i en dialog med dig om eventuel manglende information. Det kan anbefales at den samme som finder fejlen gentester rettelsen hvis det er muligt. 7. Navn på personen som behandler fejlen lige nu Det kan være en god ide, at man identificerer hvem som har behandlet en given fejl, hvis en lignende fejl opstår eller hvis nogen finder yderligere relevant information som kan afhjælpe rettelsen. En anden og mere simpel årsag er, at placere et ansvar for hvem der bærer fejlen videre gennem processen. 8. Nuværende status på fejlen Alt efter hvor omfattende en defekt-proces er i en given organisation, vil man have en række forskellige status angivelser. Det mest basale niveau er, at have en åben og en lukket status for at se om man skal forholde sig til den eller ej, i den nuværende version. Typisk vil man tage et skridt videre og dele lukket op i årsager til at den er lukket som f.eks. afvist by design, rettet, kan ikke genskabes, og hvad der ellers giver værdi til det enkelte projekt. I takt med projektet og niveauet af rapportering stiger kan det være nyttigt at tilføje mellemtrin på status angivelsen. Dette kunne være triage, under rettelse, rettet, under gentest, gentestet, deployet osv. Alle status angivelser, som giver en idé om hvor og hvor langt i processen fejlrettelsen er. Den primære faldgrube er dog, at jo flere mellemtrin man tilføjer des mere bureaukratisk og tidskrævende vil det være at holde processen. 5 ud af 6

6 9. Effekten af fejlen Konsekvensen af en fejl vil typisk have fokus hos de forretningsansvarlige og de har derfor en interessere i at være bevidst omkring åbne fejl og prioriteringen af fejlrettelser. Forretningens fokus har indvirkning på hvor vigtigt det er, at få rettet fejlen, men må ikke forveksles med selve prioriteringen af fejlrettelsen. Ofte vil indmelderen af en fejl angive effekten af denne, men det ses også at defektmanagers angiver en effekt på en fejl. Det er dog også en god idé at få input fra andre, såfremt disse kan give korrigere efterhånden som man finder detaljer om fejlen. 10. Prioriteten af fejlen I modsætning til effekten, som er åben for at alle kan give et bud på hvad effekten kan være, ejes prioriteten af produkt ejeren altså en person som har indsigt i hvilken værdi det vil have for organisationen at få rettet fejlen. Typisk vil den som finder fejlen give et bud på hvordan rettelsen af fejlen skal prioriteres, men den bør altid revideres af en person med forretningsindsigt. Prioriteringen afhænger til dels af konsekvensen for forretningen, men en fejl kan også blokere et udvikling- eller testteam arbejde og af den årsag kan en fejl prioriteres højt. Yderligere kan nævnes signalværdi over for slutbruger og synergieffekt med andre fejl som elementer der kan inddrages i prioritering af en fejl. Spørgsmål og kontakt Du skal altid være velkommen til at kontakte os, hvis du har nogle spørgsmål. TestHuset A/S Lautruphøj Ballerup info@testhuset.dk 6 ud af 6