Fejl-/defekttriage i softwaretest

Af: Thomas Hamilton Thomas Hamilton
Hours Opdateret

⚡ Smart opsummering

Fejltriage er et gennemgangsmøde, hvor testlederen, udviklingslederen og projektlederen rangerer hver rapporteret fejl efter alvorlighed, prioritet og risiko, derefter tildeler ejere og aftaler en realistisk tidsplan for rettelser.

  • 🔘 Formål: Evaluer, prioriter og tildel hver ny defekt, så intet vigtigt overses.
  • ☑️ Frekvens: Normalt to eller tre møder om ugen, tilpasset projektets tidsplan og mængden af ​​fejl.
  • ✅ Deltagere: Projektleder, testteamleder, teknisk leder og udviklingsteamleder deltager som obligatoriske medlemmer.
  • 🧪 Alvorlighed og prioritet: Alvorlighedsmålene påvirker produktet, prioriteten bestemmer rækkefølgen af ​​rettelsen.
  • 🛠️ Møderesultat: Fejltriagemålinger fungerer som minutter og indgår i den næste triagesession.
  • ⚡ Værktøj: Enhver beslutning registreres i fejlen tracking-systemet, så revisionssporet overlever mødet.
Læs mere

Fejl- og fejltriageproces i softwaretestning

Hvad er 'Defekt Triage'?

Fejltriage er en proces, hvor hver fejl prioriteres baseret på dens alvorlighed, hyppighed, risiko osv. Triageudtrykket bruges i Software test / QA for at definere alvorligheden og prioriteten af ​​nye defekter.

Navnet er lånt fra akutmedicin, hvor triage sorterer patienter efter hvor presserende de er, når ressourcerne er begrænsede. Et kvalitetssikringsteam står over for den samme begrænsning: fejllisten er altid længere end den tid, der er tilgængelig før udgivelsesdatoen, så nogen skal beslutte, hvad der skal rettes nu, hvad der skal rettes senere, og hvad der udskydes. Triage er det møde, hvor den beslutning træffes og registreres.

Hvorfor skal vi have 'Defect Triage'?

Målet med Bug Triage er at evaluere, prioritere og tildele løsningen af ​​defekter. Teamet skal validere alvorligheden af ​​defekten, foretage ændringer efter behov, afslutte løsningen af ​​defekterne og tildele ressourcer. Anvendes hovedsageligt i agil projektledelse.

Uden triage sidder defekterne i tracker med den sværhedsgrad, som rapporteringstesteren tilfældigvis valgte, og udviklere vælger arbejde ud fra personlige præferencer snarere end forretningsmæssig indvirkning. Banneret nedenfor opsummerer grundene til, at teams holder mødet i kalenderen.

Hvorfor fejl- og defekttriage er nødvendig i et QA-projekt

Hvor ofte skal 'Defect Triage' udføres i en udgivelse?

Hyppigheden af ​​defekttriagemøder er ikke fast. Det afhænger af projektsituationen.

Her er nogle vigtige faktorer, der bestemmer hyppigheden af ​​defekttriagemøder:

Disse vigtige faktorer er:

  • I henhold til projektplanen
  • Antal fejl i systemet
  • Indvirkning på tidsplaner for teammedlemmers tilgængelighed
  • Overordnet projektsundhed

Normalt afholdes Defekt Triage-møder to eller tre gange om ugen.

Kadencen strammes, efterhånden som en udgivelse nærmer sig. Hold, der arbejder kort sagt Scrum Iterationer integrerer ofte en kort triage i den daglige rutine under det sidste sprint, mens et projekt på en længere plandrevet cyklus kan triage én gang om ugen indtil regressionstest fasen begynder.

Hvem er de obligatoriske og andre deltagere i 'Defect Triage'?

Obligatoriske deltagere

Nedenstående projektmedlemmer deltager altid i Defekt Triage-møder.

  • Project Manager
  • Test teamleder
  • Teknisk leder
  • Udviklingsteamleder

Valgfrie deltagere

  • Udviklere
  • Testere
  • Business Analyst

De valgfrie deltagere inviteres, når en specifik defekt kræver deres input, for eksempel når en forretningsanalytiker skal bekræfte, om den rapporterede adfærd faktisk modsiger et krav eller er en forklædt ændringsanmodning.

Deltageres roller og ansvar under 'Defekttriage'.

Hver obligatorisk deltager ankommer med et forskelligt ansvar, og mødet løber kun til tiden, når alle tre har forberedt sig på forhånd.

Test teamleder

  • Planlagt fejltriage-møde og send mødemeddelelse til deltagere.
  • Opret en fejlrapport og send den til alle deltagere inden mødet.
  • Tildel prioritet og sværhedsgrad af defekterne.
  • Hold en præsentation, så andre medlemmer forstår Grundårsag til defekt.
  • Hvert mødenotat fanges og sendes til mødedeltagere.

Udvikling Lead

  • Hjælper med at prioritere fejlene.
  • Diskutér sværhedsgraden af ​​defekten og forklar risikoen på grund af den defekt.
  • Tildel arbejde med at rette fejl til relevante udviklere.
  • Opdater fejlløsningen og medtag udviklingsnotater, hvis der mangler oplysninger eller yderligere oplysninger, der er nødvendige for udviklere.

Project Manager

  • Hjælp til prioritering af manglerne.
  • Diskuter den næste iterationsudgivelsesdato for QA.
  • Skal sørge for, at relaterede brugerrepræsentanter også inviteres til fejltriage-mødet.

Projektlederen holder fast i udgivelsesdatoen, så den afsluttende beslutning om enhver anfægtet defekt ligger normalt hos den rolle, som vist nedenfor.

Projektlederens ansvar i et møde om fejlbehandling

RELATEREDE ARTIKLER

Hvad sker der under 'Defekt Triage' møde?

  • Test Teamleder udsender en fejlrapport med de nye defekter. Under defekttriagemødet analyseres hver defekt for at se, om den er tildelt den rigtige prioritet og sværhedsgrad.
  • Prioriteterne omarrangeres, hvis det er nødvendigt.
  • Defekter analyseres og evalueres efter graden af ​​deres sværhedsgrad.
  • Dette inkluderer diskussion vedrørende kompleksiteten af ​​defekten, risici, afvisning, omfordeling af fejl er udført.
  • Opdateringer registreres i fejl trackongesystem.
  • QA-ingeniøren vil foretage ændringerne af hver defekt og diskutere dem med hver deltager.
  • "Kommentarer"-feltet opdateres korrekt ved at notere væsentlige punkter på mødet.

Det meste af diskussionstiden går med de to felter, der er nemmest at forveksle. Alvorlighed og prioritet sættes uafhængigt, og en defekt kan score højt på det ene og lavt på det andet.

Aspect Severity Prioritet
Hvad det måler Hvor alvorligt defekten skader produktet eller dets funktionalitet Hvor hurtigt fejlen skal udbedres i forhold til andet arbejde
Normalt indstillet af Den tester, der rapporterer fejlen Aftalt i triage med projektlederen og den ansvarlige produktside
Kørt af Teknisk påvirkning og den berørte funktionalitet Forretningsmæssig påvirkning, kundesynlighed og udgivelsesdato
Eksempel på en uoverensstemmelse Høj alvorlighedsgrad, lav prioritet: et nedbrud i en funktion, som ingen bruger før næste kvartal Lav alvorlighedsgrad, høj prioritet: et stavet firmanavn forkert på landingssiden

Tip: Hold diskussionen om en enkelt mangel kort. Når et punkt ikke kan løses på et par minutter, så parker det, tildel en ejer til at undersøge det, og bring det tilbage til næste session i stedet for at lade én mangel opsluge mødet.

Hvad er resultatet af 'Defekttriage'?

Ved slutningen af ​​hvert møde vil defekttriage-metrics blive udarbejdet og givet til alle deltagere. Denne rapport fungerer som mødeprotokollen, som vil være nyttig til fremtidige møder.

Rapporten er det punkt, hvor triagen forbinder sig tilbage til den bredere proces til håndtering af fejlHold registrerer typisk følgende i den:

  • Fejl gennemgås i sessionen, med den aftalte alvorlighedsgrad og prioritet for hver enkelt.
  • Nyligt tildelte mangler, sammen med den udvikler, der nu ejer dem.
  • Fejl udskudt, afvist eller markeret som dubletter med angivet årsag.
  • Åbent antal fejl efter alvorlighedsgrad, så tendensen på tværs af sessioner er synlig.
  • Handlinger overført til næste møde.

Fordi enhver ændring skrives tilbage i tracker, forbliver status for hvert element i overensstemmelse med dets position i defektens livscyklus, og den næste session starter fra en præcis liste i stedet for en forældet en.

Ofte Stillede Spørgsmål

Hold det til tredive til tres minutter. Den fejlrapport, der sendes ud på forhånd, er den primære gennemgang, så selve mødet bekræfter kun beslutninger. Alt, der kræver en dybdegående teknisk undersøgelse, parkeres hos en ejer og returneres til næste møde.

Agile teams afholder korte, hyppige møder, ofte i forbindelse med den daglige stand-up, fordi sprinthorisonten kun er to uger. Plandrevne projekter afholder længere formelle møder sjældnere, med mere omfattende dokumentation og en bredere interessentliste.

En udskudt defekt forbliver åben, men flyttes ud af den nuværende udgivelse, normalt med en registreret målversion. En afvist defekt lukkes med en skriftlig begrundelse – ikke reproducerbar, fungerer som designet eller er duplikat – så beslutningen kan tages op til fornyet overvejelse senere.

Én rapport gemmes som master, og resten linkes til den og lukkes som dubletter. Hvis de lukkes lydløst, mister du information, så linket er vigtigt: det bevarer alle reproduktionstrin og miljødetaljer, som de indberettere har leveret.

Enhver tracker med gemte filtre og masseredigering fungerer. Teams triagerer ofte fra en Jira bræt eller et MantisBT visning filtreret til nye defekter, redigering af alvorlighedsgrad, prioritet og tildelt person live under mødet.

Maskinlæringsmodeller grupperer lignende rapporter for at finde dubletter, antyder en alvorlighedsgrad ud fra formuleringen af ​​tidligere defekter og sender hvert element til komponenterejeren. Betragt outputtet som et første udkast – mødet bekræfter stadig alle beslutninger.

Ja, indirekte. GitHub Copilot kan opsummere en stak trace, udarbejde en reproduktionstest og forklare den berørte kode, som forkorter den undersøgelse, en ejer udfører efter triage, i stedet for at erstatte selve mødet.

Projektlederen, fordi tie-breaket er en forretningsmæssig beslutning om udgivelsesdatoen snarere end en teknisk. Udviklingslederen leverer indsatsestimatet, og testlederen den effektbevis, der informerer beslutningen.

Opsummer dette indlæg med: