Meny

Prosess for mangelfrihet og måter å håndtere møter med mangler

  • Hoved
  • Annen
  • Prosess for mangelfrihet og måter å håndtere møter med mangler

defect triage process

Prøv Instrumentet Vårt For Å Eliminere Problemer

En komplett guide til Defect Triage Process og effektive måter å håndtere Defect Triage Meeting på:

I dagens artikkel vil vi lære om Defect Triage-møte og hvordan du håndterer et triage-møte på en enklere og effektiv måte.

Før jeg fortsetter videre med denne artikkelen, ønsker jeg at alle vet hva som menes med en defekt, en defekt livssyklus og hvordan du angir prioritet og alvorlighetsgrad for hver feil . Og det er nødvendig å forstå disse grunnleggende konseptene knyttet til en feil eller feil.

Du kan også gå gjennom min tidligere artikkel ' Defekt livssyklus og Process for defektbehandling ' å forstå disse konseptene raskt.

Defekt Triage-møte

Hva du vil lære:

Oversikt

Ordet 'Prioritering' brukes i utgangspunktet innen det medisinske feltet. Egentlig pleide det å bestemme i hvilken rekkefølge pasientene skulle behandles. Vanligvis på store sykehus, hvor det er tusenvis av pasienters tilnærminger for konsultasjon eller faktisk behandling på daglig basis. Men ikke alle pasientene blir lagt inn eller behandlet umiddelbart.

Alvorlighetsgraden av sykdommen eller skaden er hovedkriteriet for konsultasjon, og basert på dette er alle pasientene kategorisert deretter. Hvis skaden eller helsen til en pasient er veldig kritisk, behandler legene vanligvis slike pasienter som en prioritet og blir innlagt om nødvendig.

Normale sykdommer eller ikke-kritiske skader blir vurdert som lavere prioritet, og slike pasienter blir behandlet senere.

Tilsvarende er begrepet Triage introdusert i programvaretesting for mangler i applikasjonen eller et prosjekt. Vanligvis implementeres Defect Triage-prosessen i store prosjekter, og i mange tilfeller er den ikke aktuelt for småskalaprosjekter. Det er sjanser for å identifisere et stort antall mangler i større prosjekter enn mellomstore eller små prosjekter.

Også i større prosjekter er hyppigheten av feilidentifikasjon ganske høyere.

Ta en titt på bildet nedenfor som viser utfallet av Defect triage-møte og gir svar på spesifikke spørsmål som:

Defekt Triage

Defekt Triage-møte

Hovedmålet med et triagemøte er å spore alle manglene og sikre riktig løsning i tide.

I løpet av testutførelsesfasen begynner testerne å rapportere feil i Defect Management-verktøyet som HP ALM , QC osv. Så Defekt Triage-møte avholdes der utviklerne og testerne er pålagt å være til stede da disse menneskene vil diskutere alle manglene og ta den nødvendige videre handlingen.

Hovedsakelig er tilstedeværelsen av deltakerne nedenfor obligatorisk:

  • Prosjektleder
  • Test Lead
  • Utviklingsledelse eller utvikler
  • Tester
  • Testleder
  • Forretningsanalytiker
  • Miljøsjef

Selv om jeg har gitt en uttømmende liste over alle deltakerne i møtet, er det ikke nødvendig å involvere dem alle som Business Analyst, Environment Manager, Test Manager, etc i det daglige møtet. Når det er nødvendig, inviterer testledelsen eller prosjektlederen dem, og de kan dele sin verdifulle tilbakemelding og mening om en spesifikk feil.

Og hele teamet er kjent som en Triage Team . Nå skal jeg forklare den nøyaktige prosessen med triage-møte og hvordan dette møtet er satt opp.

Tenk på et hypotetisk eksempel :Vi har ett prosjekt relatert til banksøknaden, størrelsen er veldig stor og hyppigheten av å identifisere og rapportere feilen er høy. Testleder bestemmer seg derfor for å sette opp et Defect Triage-møte med de nødvendige deltakerne.

For å sette opp et møte sender testledelsen en møteinvitasjon via e-post til alle og setter en bestemt timing for Triage Meeting. Nedenstående hypotetiske bilde viser møteinvitasjonen sendt av en testleder via Outlook til alle deltakerne.

hvordan du kjører en torrent fil

Her er alt imaginært i bildet nedenfor som - deltakernavn, møterom, konferansesamtale, dato, klokkeslett etc.

(Merk:Klikk på et hvilket som helst bilde for en forstørret visning)

Triage møte invitere

Hver dag før triagemøtet begynner, sender testledelsen en liste over alle 'Åpne' -feil er et regnearkformat til alle deltakerne, slik at de kan gå gjennom alle manglene før møtet og forstå hva akkurat feilen er og hva slags løsning er nødvendig for det.

Før starten på hvert triagemøte, må du forsikre deg om at hver feil:

  • Har nok informasjon til å forstå mangelen for alle deltakerne på møtet.
  • Har rapportert under riktig prosjekt og kategori.
  • Har nevnt prioriteten og alvorlighetsgraden av manglene.
  • All detaljert informasjon gitt i feilen for å forstå den riktig til alle deltakerne.

Anbefalt lesing => En komplett guide til feilhåndteringsprosessen

Mal for mangelfrihet

Før kickstart av hvert Defect Triage Meeting deler testledelsen defektrapporten til alle deltakerne i et bestemt format, og rapporten ble hentet fra Defect Management Tool som HP ALM, HP QC etc. Jeg viser ett eksempelformat i under bildet som vil gi et inntrykk på høyt nivå av hvilke felt som er nevnt i mal for feilrapport.

Manglerapport

Vanligvis er feltene som er inkludert i feilrapporten:

  • Defekt-ID
  • Beskrivelse
  • Prioritet
  • Alvorlighetsgrad
  • Oppdaget dato
  • Oppdaget av
  • Status

Listen er ikke uttømmende, men i henhold til prosjektets behov kan de andre feltene i malen for feilrapporter inkluderes.

Regnearkformatet brukes vanligvis som en mal for rapportering av feil, og derfor har jeg gitt de hypotetiske feilopplysningene i regnearkformatet. Vær oppmerksom på at all informasjonen som er gitt i den ovennevnte feilrapporten, kun er imaginær og ikke er relatert til noe prosjekt eller faktisk anvendelse.

Defekt Triage-prosess

En ofte hørt og erfaren situasjon i testteam er begrenset tilgjengelighet på ressurser. Defekt triage er en prosess som prøver å gjøre noe balansering som et resultat av dette fenomenet. Så når det er mange mangler og begrensede utviklere / testere for å fikse / verifisere dem, hjelper defekt triage å få så mange mangler løst som mulig ved å balansere teknisk personell basert på defektparametere som prioritet og alvorlighetsgrad.

Vanligvis deltar Product Manager i en defekt-triagesession, en utviklingsledelse, en testleder og noen ganger forretningsanalytikere. I noen tilfeller kan visse andre medlemmer også bli invitert til å gi sine meninger og perspektiver angående visse mangler. Disse kalles samlet et triagelag.

Defekt Triage-prosess

De fleste systemer bruker prioritet som hovedkriteriene for å vurdere feilen, men en god triuraprosess vurderer også alvorlighetsgraden.

La oss se nærmere på triageprosessen med to eksempler som vi har snakket om i forrige avsnitt. I begge eksemplene ovenfor vil det faktisk være den første feilen som vil bli prioritert veldig høyt. Til tross for at det bare er en kosmetisk feil, vil virkningen av å ikke fikse det være stor.

Den andre, derimot, er en sikker funksjonsfeil, men dens forekomst er bare under visse forhold som sjelden praktiseres kundescenarier. Å fikse det kan trenge mer tid og mennesker, noe som kan brukes bedre til andre feil. Derfor vil det anse lavere prioritet enn den første og kanskje utsette kandidaten til en annen utgivelse.

Dermed involverer triage-prosessen triage-teamet som setter seg sammen og gjennomgår alle feilene, inkludert avviste feil. De trekker en innledende vurdering av manglene basert på innholdet, deres respektive prioritet og alvorlighetsinnstillinger; med hver person i triage-teamet som presenterer sitt perspektiv på hvordan man kan prioritere manglene.

Produktansvarlig setter deretter prioriteten basert på alle inngangene og tildeler feilen til riktig utgivelse dvs. i den nåværende utgivelsen eller en hvilken som helst fremtidig utgivelse. Han omdirigerer også mangelen til riktig eier / team for videre handling. Avviste mangler blir også satt gjennom en lignende analyse. Basert på årsaken til avvisning, bestemmes den futuristiske handlingen om det må utsettes eller kanselleres.

I triagemøtet bør hver eneste mangel diskuteres, inkludert feilene som er kategorisert som en lavere prioritet. Triage-teamet vurderer alle manglene og tar nødvendige tiltak på hver feil. Hvis en mangel mangler informasjon, tilordner utvikleren slike feil til testerne og ber om nødvendig informasjon.

Triagemøtet kan holdes i møterommet hvis alle deltakerne er på samme sted. Men i mange organisasjoner utføres arbeidet fra et annet sted, og alle lagene er spredt over forskjellige steder, slik at møtet også holdes ved hjelp av telefonkonferanse eller Skype for virksomheten.

Telekonferansedeltakere

( bilde kilde )

Steg for trinn prosess for defekt triage møtet:

  • Test Lead starter møtet med feilrapporten som ble sendt tidligere på dagen.
  • Diskusjonen starter med handlingene som venter fra forrige triagemøte. Nødvendige oppdateringer eller handlinger som ble utført på en hvilken som helst mangel, diskuteres først.
  • Hvis det er nye mangler i feilrapporten, blir disse manglene gjennomgått og evaluert. Det verifiserer også om prioritet og alvorlighetsgrad er tildelt riktig, hvis ikke, blir disse korrigert i møtet.
  • Alle manglene blir diskutert i møtet, og utviklingsteamet diskuterer også kompleksiteten ved å fikse feilen. Risikoen forbundet med mangelen diskuteres også av triage-teamet.
  • Triage-teamet kommer til en konklusjon om hvilken mangel som krever øyeblikkelig oppmerksomhet og løsning, og hvilken mangel som må vente en stund, og om nødvendig kan disse manglene utsettes til fremtidige utgivelser.
  • Alle feilene tildeles det respektive teamet i QC eller ALM samtidig under møtet. Passende kommentarer er også lagt til i QC / ALM.
  • Alle viktige oppdateringer og handlingselementer noteres og testledelsen roper på slutten av møtet.
  • Etter at triagemøtet er fullført, sender Test Lead ut møteprotokoll til alle deltakerne.

Roller og ansvar

Roller og ansvar basert på hver kategori er forklart nedenfor:

Test Lead

  • Test Lead planlegger et defekt triage-møte og sender ut en formell møteinvitasjon til det nødvendige teamet.
  • Sender feilrapporten før hvert triagemøte.
  • Start møtet med de ventende handlingselementene fra forrige triage-møte.
  • Diskuter hver feil og innvirkning på timeplanen hvis noen funksjoner er blokkert på grunn av feilen.
  • Hjelper med å tildele prioritet og alvorlighetsgrad for hver defekt hvis den ikke ble tildelt riktig tidligere.
  • Oppdater QC / ALM med passende kommentarer.
  • Noter ned alle oppdateringene, handlingselementene, risikoen knyttet til en feil, etc.
  • Sender møtereferat til alle deltakerne.

Utviklingsleder / utvikler

  • Del oppdateringer om handlingselementene som er ventet fra det siste triagemøtet.
  • Diskuter alle feilene i et teknisk perspektiv.
  • Identifiser hvor mye tid det vil kreve å fikse basert på kompleksiteten i feilen og funksjonaliteten.
  • Diskuter kompleksiteten til mangelen og risikoen forbundet med mangelen, hvis noen.
  • Development Lead tildeler feil til den aktuelle utvikleren etter å ha validert all tilgjengelig detaljert informasjon.
  • Oppdaterer feilen med forventet oppløsningsdato.
  • Hjelper med å identifisere årsaken til feilen.

Prosjektleder

  • Sørg for at hvis alle representanter fra alle områder er tilgjengelige for møtet.
  • Om nødvendig inviterer prosjektleder Business Analyst til møtet for sin mening om en spesifikk mangel.
  • Hvis manglene ikke beveger seg, eller hvis det er noen større blokkeringer, eskalerer den med opptrappingsprosessen.
  • Hvis det er nødvendig, fungerer som megler hvis det oppstår tvist eller konflikt mellom lagene og tar den nødvendige avgjørelsen.
  • Ta bekreftelsen fra utviklingsteamet for neste utgivelsesdato for faste mangler.
  • Gjør deg oppmerksom på den oppdaterte tidsplanen og utgivelsesdatoen for prosjektet til alle teamene.

Noen ganger er det også en god ide å involvere de andre teammedlemmene i triage-samtalen, slik at de også kan forstå og bidra til møtet, og om nødvendig kan de også gi tilbakemelding.

Konklusjon

Hver defekt som logges, bør diskuteres på triagemøtet.

Selv om en mangel avvises, bør testteamet vite årsaken til avvisning. Også hvis noen av manglene ikke er reproduserbare, kan utvikleren under triagemøtet be testerne om sanntidsdetaljer, og de kan prøve å reprodusere feilen.

Defekt Triage er viktig ettersom alle vil vite når feilen blir løst og være tilgjengelig for omprøving. Hvis noen av manglene ikke er kritiske, og for å fikse feilen, krever det enorm innsats fra utviklingsteamet, og avgjørelsen vil bli tatt av prosjektlederen.

Prosjektlederen vil bestemme prioriteten til en slik mangel, og om nødvendig kan manglene utsettes til neste utgivelse.

Håper du ville ha fått en klar ide om Defect Triage, Defect Triage Process og måter å effektivt håndtere Defect Triage-møter på!

Anbefalt lesing

^