Defect Triage:

Hvad er Defect Triage?

Defect Triage er en proces, hvor testerne finder frem til fejlen og tildeler den en grad af risiko, gentagelse og sværhedsgrad. Denne grad prioriterer i det væsentlige den fejl, der skal behandles først.

Triage er imidlertid et medicinsk begreb, der grundlæggende betyder forsøg eller en afprøvning. Når du ankommer til skadestuen, foretages den første medicinske vurdering af en sygeplejerske.

På skadestuen foregår det typisk i triagerummet. I løbet af denne tid er det meget vigtigt, at patienten beskriver sit problem for sygeplejersken, så hun præcist kan vurdere, hvad der skal ske som det næste.

Baseret på alvorligheden eller det presserende i en anden persons medicinske tilstand, kan det være, at vedkommende bliver taget hurtigere tilbage end dig. Det er præcis det samme, der sker, når en softwaretester udfører en fejl- eller fejltriage.

De tildeler en alvorlighedsgrad til hver fejl, og den fejl, der virker mest alvorlig, eller den fejl, der har større potentiale til at kompromittere systemets integritet, tages først i betragtning.

Møde om fejltriage

Møder om fejltriage faciliteres af QA-lederen, og det koordineres med forretningsanalytikere, it-leder, projektleder eller endda produktlederen.

I udviklings- eller testfasen støder testerne på en masse problemer eller fejl, som bliver ved med at genere alle. For at tage sig af disse fejl organiseres defekttriagemødet.

Det vigtigste formål med dette triagemøde er at kategorisere, prioritere og spore problemer.

Triagemøderne finder sted med jævne mellemrum, nogle gange endda 3 – 4 gange om ugen, afhængigt af projektets størrelse, projektsituationen, tidsplanen og antallet af defekter. Flere faktorer spiller en rolle for, hvor mange triagemøder der er nødvendige for at fjerne en fejl én gang for alle.

Alle disse møder indebærer diskussioner om kompleksiteten af fejlen, den risiko, der er forbundet med den, tildelinger, gentildelinger og afvisninger. Alle disse opdateringer registreres i fejlsporingssystemet.

For at opnå de bedste resultater bør QA lead sende fejlrapporten med de eksisterende fejl eller nye fejl til hvert møde.

Hver fejl bør analyseres for at se, om der er blevet tildelt korrekt prioritet og sværhedsgrad. Hovedmotivet for dette møde er at løse alle problemerne rettidigt, fast og præcist.

Under mødet kategoriseres hver fejl i en af de tre kategorier:

• Øjeblikkelig handling for at løse fejlen: Fejlen falder i denne kategori af to årsager. Den første grund er, at der er tilstrækkelige ressourcer i teamet til at rette fejlen, og den anden grund er, at fejlen kan give problemer i fremtiden, og at det derfor er vigtigt, at de retter fejlen med det samme.
• HANDLING PÅ FEJLEN PÅ ET SPÆTTERT TIDSPUNKT: En fejl falder i denne kategori, når teamet ved, at det ikke er noget større og kan behandles efter et stykke tid.
• INGEN HANDLING PÅ BUG: Dette betyder grundlæggende, at fejlen er meget lille og ikke har nogen indvirkning på hele systemet. Derfor er der ikke behov for at foretage en handling på en sådan fejl.

Strin i fejltriagering

Triageteamet består af projektleder, tester, testleder, udvikler, miljøchef, testleder og forretningsanalytiker. Der er 3 trin i fejltriage; fejlgennemgang, fejlvurdering og fejltildeling. Hvert af trinene diskuteres i detaljer nedenfor:

• DEFECT REVIEW: Alle de ovennævnte medarbejdere dykker dybt ned i oprindelsen og konsekvenserne af hver enkelt defekt i et forsøg på at rette dem.
• DEFECT ASSESSMENT (defektvurdering): Alle de nævnte medarbejdere dykker dybt ned i oprindelsen og konsekvenserne af hver enkelt defekt i et forsøg på at rette dem.
• I dette trin kategoriseres manglerne i 2 kategorier: “skal rettes” og “på vent”. Fejlens alvorlighed er det vigtigste grundlag for denne opdeling. Ovennævnte personale træffer i fællesskab beslutning om, hvilken defekt der skal behandles straks, og hvilken defekt der skal holdes i venteposition.
• DEFECT ASSIGNMENT: Nu hvor teamet har en liste over defekter, der skal behandles i første omgang, tildeler de hver enkelt defekt til den pågældende person. Alt dette gøres, efter at fejlen er blevet korrekt og omfattende evalueret.

Roller og ansvarsområder for hvert medlem i triage-teamet

• TESTLEAD: Testlead er den, der starter det hele. Test lead sender en formel invitation til alle triage-medlemmerne sammen med en detaljeret fejlrapport. Testlederen er den første person, der identificerer og tildeler en sværhedsgrad til hver enkelt defekt. Et af testlederens hovedansvarsområder er at forberede en præsentation for triage-teamet, som giver dem mere indsigt i hver enkelt defekt. Denne præsentation hjælper teamets medlemmer med hurtigt at komme til problemets rod.
• PROJEKTLEDER: Projektlederen spiller en central rolle i prioriteringen af fejl, udarbejdelsen af mangellisten og formidlingen af hele mødet. Han sørger også for, at alle medlemmer af triage-teamet er til stede under diskussionen. Nogle gange går diskussionen op i en højere enhed, og det er her, projektlederen træder ind for at lade teammedlemmerne udtrykke tingene fra deres perspektiv.
• UDVIKLINGSTEAMLEDER: Udviklingsteamlederen og projektlederen prioriterer defekter i fællesskab. Udviklingslederens hovedfunktion er at kommunikere de involverede risici og kompleksitetsniveauet for hver enkelt defekt. Det er også ham, der tildeler opgaver til de forskellige medlemmer af triageholdet.

Der er andre medlemmer i teamet, men projektlederen, testlederen og udviklingsteamlederen er nøglepersonerne. Mødet ville ikke nå frem til en konklusion, hvis en af disse mangler.

Hvad sker der på et triagemøde?

Det er opdelt i 3 dele; før-møde, under mødet og efter-møde. Før mødet starter, sender testlederen en rapport til alle medlemmer af triageholdet, så de i nogen grad er bekendt med de seneste fejl.

• FORMØDE: Testerne har en vigtig rolle at spille i før-mødet. Testerne giver oplysninger om fejlen til teamet, og de kategoriserer hver enkelt fejl i forskellige sektioner på grundlag af sværhedsgrad og prioritet. Så i bund og grund ejes før-mødet af testerne.
• Under mødet: Det sker ikke altid, at alle problemerne på et møde bliver løst. Nogle udestående problemer fra det foregående fejltriagemøde drøftes, før man går videre til de nye problemer. Derefter drøftes fremskridtene med de tidligere problemer. Herefter noteres hvert enkelt punkt om de eksisterende manglers alvorlighed. Teammedlemmerne træffer i fællesskab en beslutning om, hvilken defekt der skal rettes med det samme, og hvilken defekt de kan udsætte til en senere dato. Hvis fristen er tæt på, vil fejlene med en højere grad af alvorlighed blive behandlet først, og de mindre alvorlige fejl vil blive holdt i bero. Men hvis der ikke er noget pres fra tidsfristerne, kan selv de mindste fejl blive rettet i starten af projektet. På baggrund heraf opdateres buglisten, og det er her, at tildelingen af opgaver kommer ind i billedet. Testlederen har det sidste ord på mødet. Han opsummerer hurtigt hele mødet og meddeler de umiddelbare handlemuligheder til de respektive teammedlemmer.
• POST-MØDE: MOM (referat af mødet) deles med fejltriageholdet efter mødets afslutning. Dette dokument indeholder de vigtigste punkter, der blev drøftet på mødet.

Indholdet af en fejltriageringsrapport

1. DEFECT-ID: Hver fejl har fået tildelt et unikt nummer, som adskiller den fra andre fejl.
2. DEFECTBESKRIVELSE: Dette er relateret til, hvordan fejlen forårsager funktionsfejl i systemet.
3. SKABELSEDATUM: Det er den dato, hvor fejlen blev bemærket første gang.
4. CREATOR: Skaberen er den person, der først bemærkede og rapporterede fejlen.
5. SEVERITY: Dette er et mål for, hvor alvorlig fejlen er.
6. PRIORITY: Prioriteten kan være høj, middel eller lav. Høj prioritet betyder, at fejlen kræver øjeblikkelig opmærksomhed, middel prioritet betyder, at fejlen kan løses efter nogen tid og ikke kræver øjeblikkelig handling, og lav prioritet betyder, at fejlen ikke har nogen væsentlig eller mærkbar indvirkning på projektet og derfor måske eller måske ikke bliver løst.
7. STATUS: Om fejlen er ny, under revision, i gang eller afsluttet afgøres ved at henvise til fejlstatus.
8. ASSIGNMENT DATE: Dette er den dato, hvor fejlen blev tildelt det respektive personale til løsning.
9. ASSIGNED TO: Dette er den dato, hvor fejlen blev tildelt det respektive personale til løsning.
10. ASSIGNED TO: Dette felt har navnet på den person, som fejlen er blevet tildelt til løsning.
11. LØSNING: Hvad der gøres for at løse fejlen.
12. DATO FOR LØSNING: Anslået dato, hvor fejlen vil være fuldstændig løst.
13. ESTIMATED TIME: Anslået tid for løsning af fejlen.
14. ACTUAL TIME: Anslået tid for løsning af fejlen.
15. ACTUAL TIME: Anslået dato, hvor fejlen er fuldstændig løst:
16. ROOT CAUSE DESCRIPTION: Dette felt indeholder oplysninger om, hvorfor fejlen overhovedet opstod.

Hvorfor har vi brug for Defect Triage?

Den største fordel, du får ud af processen, er, at dit team får mulighed for at vurdere fejlens alvorlighed, udtænke planer for at fiske den op og nå frem til en konklusion om de ressourcer, der skal tildeles til processen. Defekttriage bruges hovedsageligt i agil testmetodik

KONKLUSION

For at løse fejlen indkaldes der til et defekttriagemøde. Testlederen, projektlederen og lederen af udviklingsteamet skal være til stede blandt alle medlemmerne af triage-teamet.

Det er nødvendigt at være til stede blandt alle medlemmerne af triage-teamet.

Mødet om triage af defekter gennemføres i 3 faser; før mødet, under mødet og efter mødet. Efter alt dette udarbejder testlederen en detaljeret triageringsrapport.

Rapporten indeholder alle oplysninger fra det tidspunkt, hvor fejlen oprindeligt blev bemærket, til den grundlæggende årsag til fejlen.

Frekvensen af fejltriagering afhænger helt af projektets størrelse. Den kan organiseres på ugentlig, månedlig eller daglig basis.