Feil-/defekttriage i programvaretesting

Hva er "Defekttriage"?

Feiltriage er en prosess der hver feil prioriteres basert på alvorlighetsgrad, frekvens, risiko osv. Triagebegrepet brukes i Programvare testing / QA for å definere alvorlighetsgraden og prioriteten til nye feil.

Navnet er lånt fra akuttmedisin, hvor triage sorterer pasienter etter hvor raskt det haster når ressursene er begrensede. Et kvalitetssikringsteam står overfor den samme begrensningen: feillisten er alltid lengre enn tiden som er tilgjengelig før utgivelsesdatoen, så noen må bestemme hva som skal fikses nå, hva som skal fikses senere, og hva som utsettes. Triage er møtet der den avgjørelsen tas og registreres.

Hvorfor må vi ha 'Defect Triage'?

Målet med Bug Triage er å evaluere, prioritere og tildele løsningen av defekter. Teamet må validere alvorlighetsgraden av defekten, gjøre endringer etter behov, fullføre løsningen av defektene og tildele ressurser. Hovedsakelig brukt i smidig prosjektledelse.

Uten triage sitter defektene i tracker med den alvorlighetsgraden rapporteringstesteren valgte, og utviklere velger arbeid etter personlige preferanser snarere enn forretningsmessig innvirkning. Banneret nedenfor oppsummerer grunnene til at teamene holder møtet i kalenderen.

Hvor ofte må "Defektutredning" utføres i en utgivelse?

Hyppigheten av defekttriagemøte er ikke fast. Det avhenger av prosjektsituasjonen.

Her er noen viktige faktorer som bestemmer hyppigheten av defektutredningsmøter:

Disse viktige faktorene er:

• I henhold til prosjektplanen
• Antall feil i systemet
• Innvirkning på tidsplaner for teammedlemmers tilgjengelighet
• Samlet prosjekthelse

Vanligvis holdes defekttriagemøter to eller tre ganger i uken.

Kadensen strammes inn etter hvert som en utgivelse nærmer seg. Team som jobber kort sagt Scrum Iterasjoner legger ofte en kort triage inn i den daglige rutinen under den siste sprinten, mens et prosjekt på en lengre planbasert syklus kan triage én gang i uken inntil Regresjonstesting fasen begynner.

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

Obligatoriske deltakere

Prosjektmedlemmene nedenfor deltar alltid i Defect Triage Meetings.

• Project Manager
• Teamleder for test
• Teknisk leder
• Leder for utviklingsteam

Valgfrie deltakere

• Utviklere
• testere
• Business Analyst

De valgfrie deltakerne inviteres når en spesifikk mangel krever deres innspill, for eksempel når en forretningsanalytiker må bekrefte om den rapporterte oppførselen faktisk motsier et krav eller er en forkledd endringsforespørsel.

Roller og ansvar for deltakere under "Defektutredning."

Hver obligatoriske deltaker kommer med et ulikt ansvar, og møtet går bare etter planen når alle tre forbereder seg på forhånd.

Teamleder for test

• Planlagt feiltriage-møte og send møtevarsling for deltakere.
• Lag en feilrapport og send den til alle deltakere før møtet.
• Tildel prioritet og alvorlighetsgrad av manglene.
• Hold en presentasjon slik at andre medlemmer forstår Root Årsak til defekt.
• Hvert møtenotat blir fanget opp og sendt til møtedeltakerne.

Utviklingsleder

• Hjelper til med prioritering av defektene.
• Diskuter vanskelighetsgraden og forklar risikoen på grunn av den defekten.
• Tildel arbeid for å fikse feil til relevante utviklere.
• Oppdater feilløsningen og inkluder utviklingsnotater i tilfelle informasjon mangler eller tilleggsinformasjon som utviklerne trenger.

Project Manager

• Hjelp til med prioritering av mangler.
• Diskuter neste iterasjonsutgivelsesdato for QA.
• Må sørge for at relaterte brukerrepresentanter også inviteres til feilutredningsmøtet.

Prosjektlederen holder utgivelsesdatoen, så den avsluttende avgjørelsen om eventuelle omtvistede feil ligger vanligvis hos den rollen, som vist nedenfor.

Hva skjer under 'Defekttriage'-møtet?

• Testteamleder sender ut en feilrapport med de nye defektene. Under defekttriagemøtet blir hver defekt analysert for å se om den er tilordnet riktig prioritet og alvorlighetsgrad.
• Prioriteringer omorganiseres ved behov.
• Defekter blir analysert og evaluert etter graden av alvorlighetsgraden.
• Dette inkluderer diskusjon om kompleksiteten til defekten, risiko, avvisning, omfordeling av feil er gjort.
• Oppdateringer fanges opp i feilsøkingsrapporter trackongesystemet.
• QA-ingeniøren vil gjøre endringene på hver defekt og diskutere dem med hver deltaker.
• "Kommentarer"-feltet oppdateres riktig ved å notere viktige punkter i møtet.

Mesteparten av diskusjonstiden går med til de to feltene som er lettest å forveksle. Alvorlighetsgrad og prioritet settes uavhengig av hverandre, og en feil kan score høyt på det ene og lavt på det andre.

Tips: Hold diskusjonen om én enkelt feil kort. Når et punkt ikke kan løses på et par minutter, parker det, gi en eier til å undersøke det, og ta det med tilbake til neste økt i stedet for å la én feil fortære møtet.

Hva er resultatet av "Defektutredningen"?

På slutten av hvert møte vil Defect Triage Metrics bli utarbeidet og gitt til alle deltakerne. Denne rapporten fungerer som møteprotokollen som vil være nyttig for fremtidige møter.

Rapporten er punktet der triage kobles tilbake til det bredere prosess for feilhåndteringLagene registrerer vanligvis følgende i den:

• Mangler gjennomgått i økten, med avtalt alvorlighetsgrad og prioritet for hver av dem.
• Nylig tilordnede mangler, sammen med utvikleren som nå eier dem.
• Mangler utsatt, avvist eller merket som duplikater, med årsak registrert.
• Åpent antall feil etter alvorlighetsgrad, slik at trenden på tvers av økter er synlig.
• Tiltakene ble overført til neste møte.

Fordi hver endring skrives tilbake i tracker, statusen til hvert element forblir konsistent med sin posisjon i defektens livssyklus, og neste økt starter fra en nøyaktig liste i stedet for en foreldet en.

Spørsmål og svar