Menu

Proces med mangelfrihed og måder at håndtere defekttilslutningsmøde på

  • Vigtigste
  • Andet
  • Proces med mangelfrihed og måder at håndtere defekttilslutningsmøde på

defect triage process

Prøv Vores Instrument Til At Fjerne Problemer

En komplet guide til Defekt Triage-proces og effektive måder at håndtere Defekt Triage-møde på:

I dagens artikel vil vi lære om Defect Triage-møde og hvordan man håndterer et triage-møde på en lettere og effektiv måde.

Før jeg fortsætter med denne artikel, ønsker jeg, at alle ved, hvad der menes med en defekt, en defekt livscyklus og hvordan man indstiller prioritet og sværhedsgrad for hver defekt . Og det er nødvendigt at forstå disse grundlæggende begreber relateret til en defekt eller fejl.

Du kan også gennemgå min tidligere artikel ' Defekt livscyklus og Process for fejlhåndtering ' at forstå disse begreber hurtigt.

Møde om mangelfrihed

Hvad du lærer:

Oversigt

Ordet “Triage” bruges dybest set inden for det medicinske område. Faktisk plejede det at bestemme rækkefølgen, i hvilken patienterne skulle behandles. Normalt på store hospitaler, hvor der er tusindvis af patienters tilgange til konsultation eller faktisk behandling på daglig basis. Men ikke alle patienter indlægges eller behandles med det samme.

Alvorligheden af ​​sygdommen eller skaden er de vigtigste kriterier for konsultation, og på baggrund heraf er alle patienter kategoriseret i overensstemmelse hermed. Hvis en patients skade eller helbred er meget kritisk, behandler lægerne normalt sådanne patienter som en prioritet og bliver indlagt, hvis det kræves.

Normale sygdomme eller ikke-kritiske skader betragtes som en lavere prioritet, og sådanne patienter behandles senere.

Tilsvarende introduceres udtrykket Triage i softwaretest for mangler i applikationen eller et projekt. Normalt implementeres Defekt Triage-processen i store projekter, og i mange tilfælde er den ikke anvendelig til mindre projekter. Der er chancer for at identificere et stort antal fejl i større projekter end mellemstore eller små projekter.

Også i større projekter er hyppigheden af ​​identifikation af mangler ret højere.

Se nedenstående billede, der viser resultatet af et defekt triage-møde og giver svar på specifikke spørgsmål som:

Defekt forstyrrelse

Møde om mangelfrihed

Hovedformålet med et triagemøde er at spore alle manglerne og sikre den korrekte løsning rettidigt.

I løbet af testudførelsesfasen begynder testerne at rapportere fejl i Defect Management-værktøjet som f.eks HP ALM , QC osv. Derefter Møde om mangelfrihed afholdes, hvor udviklere og testere kræves at være til stede, da disse mennesker vil diskutere alle mangler og tage den nødvendige yderligere fremgangsmåde.

Hovedsageligt er tilstedeværelsen af ​​nedenstående deltagere obligatorisk:

  • Projektleder
  • Test bly
  • Udviklingsledelse eller udvikler
  • Tester
  • Test Manager
  • Business analytiker
  • Miljøchef

Selvom jeg har givet en udtømmende liste over alle deltagerne i mødet, er det ikke nødvendigt at inddrage dem alle som Business Analyst, Environment Manager, Test Manager osv. I det daglige møde. Når det er nødvendigt, inviterer testledelsen eller projektlederen dem, og de kan dele deres værdifulde feedback og mening om en specifik defekt.

Og hele holdet er kendt som en Triage Team . Nu skal jeg forklare den nøjagtige proces med triage-møde, og hvordan dette møde er sat op.

Overvej et hypotetisk eksempel :Vi har et projekt relateret til bankapplikationen, størrelsen er meget stor, og hyppigheden af ​​at identificere og rapportere manglen er høj. Derfor beslutter testledningen at oprette et defektforbrugsmøde med de krævede deltagere.

For at oprette et møde sender testledelsen en mødeinvitation via e-mail til alle og indstiller en bestemt timing for Triage Meeting. Nedenstående givne hypotetiske billede viser mødeinvitationen sendt af en testledelse via udsigten til alle deltagerne.

Her er alt imaginært i nedenstående billede som - deltagernavne, mødelokale, konferenceopkald, dato, klokkeslæt osv.

(Bemærk:Klik på et hvilket som helst billede for at se et forstørret billede)

Invitation til drægtighedsmøde

Hver dag inden starten af ​​triagemødet sender testledningen en liste over alle ”åbne” defekter er et regnearkformat til alle deltagerne, så de kan gennemgå alle manglerne før mødet og forstå, hvad nøjagtigt manglen er og hvilken slags løsning der kræves for det.

Inden starten på hvert triagemøde skal du sikre dig, at hver defekt:

  • Har nok information til at forstå manglen for alle deltagerne i mødet.
  • Har rapporteret under korrekt projekt og kategori.
  • Har nævnt prioriteten og sværhedsgraden af ​​manglerne.
  • Alle detaljerede oplysninger leveret i defekten for at forstå det korrekt til alle deltagerne.

Anbefalet læsning => En komplet guide til fejlhåndteringsprocessen

Skabelon til defekt træk

Før kickstart af hvert Defect Triage-møde deler testledningen defektrapporten til alle deltagerne i et specifikt format, og rapporten blev trukket ud af Defect Management Tool som HP ALM, HP QC osv. Jeg viser et eksempelformat i nedenstående billede, som giver et indtryk på højt niveau af, hvilke felter der er nævnt i skabelonen til fejlrapporter.

Fejlrapport

Normalt er felterne i fejlrapporten:

  • Defekt-id
  • Beskrivelse
  • Prioritet
  • Alvorlighed
  • Registreret dato
  • Opdaget af
  • Status

Listen er ikke udtømmende, men alt efter projektets behov kan de andre felter i skabelonen til fejlrapporter inkluderes.

Normalt bruges regnearkformatet som en skabelon til rapportering af mangler, hvorfor jeg har givet de hypotetiske defektoplysninger i regnearkformatet. Bemærk, at alle de oplysninger, der er angivet i ovenstående fejlrapport, kun er imaginære og ikke er relateret til noget projekt eller faktisk anvendelse.

Process for defekt træk

En almindeligt hørt og erfaren situation i testteam er begrænset tilgængelighed af ressourcer. Defekt triage er en proces, der forsøger at foretage en ny afbalancering som et resultat af dette fænomen. Så når der er mange defekter og begrænsede udviklere / testere til at rette / verificere dem, hjælper defekt triage med at få så mange defekter løst som muligt ved at afbalancere det tekniske personale baseret på defektparametre som prioritet og sværhedsgrad.

Typisk deltager en defekt-triagesession af Product Manager, en udviklingsledelse, en testledelse og undertiden forretningsanalytikere. I nogle tilfælde kan visse andre medlemmer også opfordres til at give deres meninger og perspektiver vedrørende visse mangler. Disse kaldes samlet et triage-team.

Process for defekt træk

hvordan man får hurtigbøger gratis

De fleste systemer bruger prioritet som de vigtigste kriterier for at vurdere manglen, men en god triageproces overvejer også sværhedsgraden.

Lad os se nærmere på triageprocessen med to eksempler, som vi har talt om i det foregående afsnit. I begge eksemplerne ovenfor ville det faktisk være den første defekt, der ville blive prioriteret meget højt. På trods af at det kun er en kosmetisk defekt, ville virkningen af ​​ikke at rette op være enorm.

Den anden er på den anden side helt sikkert en funktionsfejl, men dens forekomst er kun under visse betingelser, som sjældent praktiseres kundescenarier. At rette op på det kan have brug for mere tid og mennesker, hvilket bedre kunne bruges til andre mangler. Derfor vil det betragtes som lavere prioritet end den første og måske udsættelse af kandidaten til en anden frigivelse.

Således involverer triage-processen triage-team, der sidder sammen og gennemgår alle manglerne inklusive afviste mangler. De tegner en indledende vurdering af manglerne baseret på dens indhold, deres respektive prioritet og sværhedsindstillinger; hvor hver person i triage-teamet præsenterer deres perspektiv på, hvordan man prioriterer manglerne.

Produktchefen indstiller derefter prioriteten baseret på alle input og tildeler defekten til den korrekte frigivelse dvs. i den aktuelle udgivelse eller enhver fremtidig udgivelse. Han omdirigerer også manglen til den korrekte ejer / hold for yderligere handling. Afviste mangler gennemføres også gennem en lignende analyse. Baseret på årsagen til afvisning bestemmes den futuristiske handling om det skal udsættes eller annulleres.

I triagemødet skal hver eneste mangel diskuteres inklusive de mangler, der er kategoriseret som en lavere prioritet. Triage-teamets evaluering evaluerer alle manglerne og træffer de nødvendige handlinger for hver defekt. Hvis en mangel mangler information, tildeler udvikleren sådanne fejl tilbage til testerne og anmoder om nødvendig information.

Triagemødet kan afholdes i mødelokalet, hvis alle deltagerne er på samme sted. Men i mange organisationer udføres arbejdet fra et andet sted, og alle holdene er spredt på forskellige steder, så mødet også afholdes ved hjælp af telekonference eller forretning Skype.

Telekonferencedeltagere

( billede kilde )

Trin for trin proces af defekt triage møde:

  • Test Lead starter mødet med fejlrapporten, der blev sendt tidligere på dagen.
  • Diskussionen starter med de handlinger, der afventes fra det forrige triagemøde. De nødvendige opdateringer eller handlinger, der blev foretaget på en defekt, diskuteres indledningsvis.
  • Hvis der er nye mangler i fejlrapporten, gennemgås og evalueres disse mangler. Det verificerer også, om prioriteten og sværhedsgraden er tildelt korrekt, hvis ikke, så rettes disse på mødet.
  • Alle mangler diskuteres i mødet, og udviklingsteamet diskuterer også kompleksiteten ved at rette manglen. Risikoen forbundet med manglen diskuteres også af triageholdet.
  • Triage-teamet kommer til en konklusion om, hvilken defekt der skal kræves øjeblikkelig opmærksomhed og afhjælpes, og hvilken defekt skal vente et stykke tid, og om nødvendigt kan disse mangler udsættes til fremtidige frigivelser.
  • Alle fejlene tildeles det respektive hold i QC eller ALM samtidigt under mødet. Passende kommentarer tilføjes også i QC / ALM.
  • Alle væsentlige opdateringer og handlingspunkter noteres, og testledelsen opfordrer til afslutningen af ​​mødet.
  • Efter afslutning af triagemødet sender testledningen referat af mødet til alle deltagerne.

Roller og ansvar

Roller og ansvar baseret på hver kategori forklares nedenfor:

Test bly

  • Test Lead planlægger et defekt triage-møde og sender en formel invitation til et krævet team.
  • Afsender manglerapporten inden hvert triage-møde.
  • Start mødet med de afventende handlingspunkter fra det forrige triagemøde.
  • Diskuter hver defekt og indvirkning på tidsplanen, hvis nogen funktioner er blokeret på grund af defekten.
  • Hjælper med at tildele prioritet og sværhedsgrad for hver defekt, hvis den ikke blev tildelt korrekt tidligere.
  • Opdater QC / ALM med passende kommentarer.
  • Noter alle opdateringer, handlingspunkter, risiko relateret til en fejl osv.
  • Sender referat af mødet til alle deltagerne.

Udviklingsleder / udvikler

  • Del opdateringer om handlingselementerne, der afventer fra det sidste triagemøde.
  • Diskuter alle fejlene i et teknisk perspektiv.
  • Identificer, hvor meget tid det vil kræve at rette, baseret på kompleksiteten af ​​defekten og funktionaliteten.
  • Diskuter kompleksiteten af ​​manglen og risikoen forbundet med manglen, hvis nogen.
  • Development Lead tildeler defekt til den relevante udvikler efter validering af alle tilgængelige detaljerede oplysninger.
  • Opdaterer fejlen med den forventede løsningstid.
  • Hjælper med at identificere grundårsagen til defekten.

Projektleder

  • Sørg for, at hvis alle repræsentanter fra alle områder er tilgængelige for mødet.
  • Hvis det er nødvendigt, inviterer projektleder Business Analyst til mødet til deres mening om en bestemt defekt.
  • Hvis manglerne ikke bevæger sig, eller hvis der er nogen større blokering, eskalerer den med eskaleringsprocessen.
  • Hvis det er nødvendigt, fungerer som mægler, hvis der opstår tvist eller konflikt mellem holdene og træffer den nødvendige beslutning.
  • Tag bekræftelsen fra udviklingsteamet til den næste udgivelsesdato for faste mangler.
  • Vær opmærksom på den opdaterede tidsplan og udgivelsesdato for projektet til alle holdene.

Til tider er det også en god ide at involvere de andre teammedlemmer i triage-opkaldet, så de også kan forstå og bidrage til mødet, og hvis det er nødvendigt, kan de også give deres feedback.

Konklusion

Enhver logget defekt skal drøftes på triage-mødet.

Selv hvis en defekt afvises, skal testteamet kende årsagen til afvisning. Også hvis nogen af ​​manglerne ikke er reproducerbare, kan udvikleren under triagemødet bede testerne om realtidsoplysninger, og de kan forsøge at reproducere manglen.

Defektforstyrrelse er vigtig, da alle vil vide, hvornår manglen bliver løst og være tilgængelig til gentest. Hvis nogen af ​​manglerne ikke er kritiske, og for at afhjælpe manglen, kræver det enorm indsats fra udviklingsteamet, og beslutningen vil blive taget af projektlederen.

Projektlederen beslutter prioriteten for en sådan mangel, og manglerne kan om nødvendigt udsættes til næste udgivelse.

Håber du ville have fået en klar idé om Defect Triage, Defect Triage Process og måder til effektivt at håndtere Defect Triage-møder!

Anbefalet læsning

^