Meny

Process för defektutsläpp och sätt att hantera möte med defektutsläpp

  • Huvud
  • Övrig
  • Process för defektutsläpp och sätt att hantera möte med defektutsläpp

defect triage process

Prova Vårt Instrument För Att Eliminera Problem

En komplett guide till Defect Triage Process och effektiva sätt att hantera Defect Triage Meeting:

I dagens artikel kommer vi att lära oss om Defect Triage-möte och hur man hanterar ett triage-möte på ett enklare och effektivare sätt.

Innan jag fortsätter med den här artikeln önskar jag att alla vet vad som menas med en defekt, en defekt livscykel och hur man ställer in prioritet och svårighetsgrad för varje defekt . Och det är nödvändigt att förstå dessa grundläggande begrepp relaterade till en defekt eller fel.

Du kan också gå igenom min tidigare artikel ' Defekt livscykel och Process för defekthantering ' att förstå dessa begrepp snabbt.

Defect Triage Meeting

Vad du kommer att lära dig:

Översikt

Ordet “Triage” används i grunden inom det medicinska området. Egentligen brukade den bestämma i vilken ordning patienterna skulle behandlas. Vanligtvis på stora sjukhus, där det finns tusentals patienters metoder för konsultation eller faktisk behandling dagligen. Men inte alla patienter tas in eller behandlas omedelbart.

Sjukdomens allvar eller skadan är de viktigaste kriterierna för konsultation och baserat på detta kategoriseras alla patienter därefter. Om skadan eller hälsan hos någon patient är mycket kritisk, behandlar läkarna vanligtvis sådana patienter som en prioritet och blir inlagda vid behov.

Normala sjukdomar eller icke-kritiska skador betraktas som lägre prioritet och sådana patienter behandlas senare.

På samma sätt introduceras termen Triage i programvarutestning för defekter i applikationen eller ett projekt. Vanligtvis implementeras Defect Triage-processen i stora projekt och i många fall är den inte tillämplig för småskaliga projekt. Det finns chanser att identifiera ett stort antal fel i större projekt än medelstora eller små projekt.

Även i större projekt är frekvensen för felidentifiering ganska högre.

Ta en titt på bilden nedan som visar resultatet av mötet med defekt triage och ger svar på specifika frågor som:

Defekt Triage

Defect Triage Meeting

Huvudsyftet med ett triagemöte är att spåra alla brister och säkerställa rätt lösning i rätt tid.

Under testutförandefasen börjar testarna rapportera fel i Defect Management-verktyget som HP ALM , QC etc. Sedan Defect Triage Meeting hålls där utvecklarna och testarna måste vara närvarande eftersom dessa människor kommer att diskutera alla brister och vidta nödvändiga ytterligare åtgärder.

Främst krävs närvaron av nedanstående deltagare obligatoriskt:

  • Projektledare
  • Testledning
  • Utvecklingsledare eller utvecklare
  • Testare
  • Testchef
  • Affärsanalytiker
  • Miljöchef

Även om jag har gett en uttömmande lista över alla deltagare i mötet är det inte nödvändigt att involvera dem alla som affärsanalytiker, miljöchef, testansvarig etc i det dagliga mötet. När det är nödvändigt bjuder testledaren eller projektledaren in dem och de kan dela med sig av sin värdefulla feedback och åsikter om ett specifikt fel.

Och hela laget är känt som en Triage Team . Nu ska jag förklara den exakta processen med triage-möte och hur mötet är uppbyggt.

Tänk på ett hypotetiskt exempel :Vi har ett projekt relaterat till bankansökan, storleken är mycket stor och frekvensen för att identifiera och rapportera bristen är hög. Därför bestämmer testledaren att inrätta ett möte för defektutveckling med de deltagare som krävs.

För att ställa in ett möte skickar testledaren en mötesinbjudan via e-post till alla och anger en viss tidpunkt för Triage Meeting. Nedanstående hypotetiska bild visar mötesinbjudan som skickas av en testledare via Outlook till alla deltagare.

Här är allt imaginärt i bilden nedan - deltagarnas namn, mötesrum, konferenssamtal, datum, tid etc.

(Notera:Klicka på valfri bild för en förstorad vy)

Inbjudan till samförståndsmöte

pl / sql intervju frågor och svar

Varje dag innan triagemötet börjar skickar testledningen en lista med alla ”Öppna” defekter är ett kalkylarkformat till alla deltagare så att de kan gå igenom alla fel innan mötet och förstå vad exakt defekten är och vilken typ av fix som krävs för det.

Innan varje triagemöte börjar, se till att varje defekt:

  • Har tillräckligt med information för att förstå defekten för alla deltagare i mötet.
  • Har rapporterat under korrekt projekt och kategori.
  • Har nämnt defekternas prioritet och svårighetsgrad.
  • All detaljerad information som tillhandahålls i defekten för att förstå den korrekt för alla deltagare.

Rekommenderad läsning => En komplett guide till hanteringsprocessen

Defect Triage-mall

Innan kickstart för varje Defect Triage Meeting delar testledningen defektrapporten till alla deltagare i ett specifikt format och rapporten drogs ut från Defect Management Tool som HP ALM, HP QC etc. Jag visar ett exempelformat i nedanstående bild som ger en hög uppfattning om vilka fält som nämns i mall för felrapport.

Felrapport

Vanligtvis är fälten som ingår i felrapporten:

  • Fel-ID
  • Beskrivning
  • Prioritet
  • Allvarlighetsgrad
  • Upptäckt datum
  • Upptäckt av
  • Status

Listan är inte uttömmande men enligt projektbehovet kan de andra fälten i mallen för felrapporter inkluderas.

Vanligtvis används kalkylformatet som en mall för felrapportering, därför har jag gett de hypotetiska defektdetaljerna i kalkylformatet. Observera att all information som tillhandahålls i ovanstående felrapport endast är imaginär och inte relaterar till något projekt eller någon faktisk tillämpning.

Process för defekt dragning

En vanligt hörd och erfaren situation i testteam är begränsad tillgång på resurser. Defekt triage är en process som försöker göra en viss balansering till följd av detta fenomen. Så när det finns många defekter och begränsade utvecklare / testare för att åtgärda / verifiera dem, hjälper defekt triage att få så många defekter som möjligt genom att balansera teknisk personal baserat på defektparametrar som prioritet och svårighetsgrad.

Vanligtvis deltar en defekt triagesession av Product Manager, en utvecklingsledare, en testledare och ibland affärsanalytiker. I vissa fall kan vissa andra medlemmar också uppmanas att ge sina åsikter och perspektiv på vissa brister. Dessa kallas kollektivt ett triagelag.

Process för defekt dragning

De flesta system använder prioritet som huvudkriterium för att bedöma defekten, men en bra triageprocess tar också hänsyn till svårighetsgraden.

Låt oss titta närmare på triageprocessen med två exempel som vi har pratat om i föregående avsnitt. I båda exemplen ovan skulle det faktiskt vara den första defekten som skulle ges en mycket hög prioritet. Trots att det bara är en kosmetisk defekt skulle effekten av att inte fixa det vara enorm.

Den andra, å andra sidan, är en säker funktionalitetsdefekt, men dess förekomst är endast under vissa förhållanden som sällan praktiseras kundscenarier. Åtgärda det kan behöva mer tid och människor, vilket skulle kunna utnyttjas bättre för andra defekter. Därför skulle det betraktas som lägre prioritet än den första och kanske uppskjutande kandidaten till en annan släpp.

Således innebär triage-processen att triage-teamet sätter sig tillsammans och granskar alla defekter inklusive avvisade defekter. De gör en första bedömning av bristerna baserat på dess innehåll, deras respektive prioritet och svårighetsinställningar. med varje person i triagelaget som presenterar sitt perspektiv på hur man kan prioritera bristerna.

Produktchefen ställer sedan in prioriteten baserat på alla ingångar och tilldelar defekten till rätt frigöring d.v.s. i den aktuella versionen eller i framtida version. Han omdirigerar också defekten till rätt ägare / team för ytterligare åtgärder. Avvisade defekter görs också genom en liknande analys. Baserat på orsaken till avslag bestäms den futuristiska åtgärden om den behöver skjutas upp eller annulleras.

I triage-mötet bör varje defekt diskuteras inklusive defekter som kategoriseras som en lägre prioritet. Triage-teamets utvärdering utvärderar alla brister och vidtar nödvändiga åtgärder för varje defekt. Om en defekt saknar information så tilldelar utvecklaren sådana defekter till testarna och begär information.

Triagemötet kan hållas i mötesrummet om alla deltagare är på samma plats. Men i många organisationer utförs arbetet från en annan plats och alla lag är spridda över olika platser så att mötet också hålls med hjälp av telekonferens eller Skype för företag.

Telekonferensdeltagare

( bild källa )

Steg för steg process för mötet med defekt triage:

  • Test Lead startar mötet med defektrapporten som skickades tidigare på dagen.
  • Diskussionen inleds med de åtgärder som väntar från föregående triagemöte. De nödvändiga uppdateringarna eller åtgärderna som vidtogs för eventuella defekter diskuteras inledningsvis.
  • Om det finns nya brister i felrapporten granskas och utvärderas dessa brister. Det verifierar också om prioritet och svårighetsgrad har tilldelats korrekt, om inte, så korrigeras dessa i mötet.
  • Alla brister diskuteras i mötet och utvecklingsteamet diskuterar också komplexiteten i att åtgärda felet. Risken förknippad med defekten diskuteras också av triage-teamet.
  • Triage-teamet kommer till en slutsats om vilken defekt som kräver omedelbar uppmärksamhet och åtgärd och vilken defekt som måste vänta en stund och vid behov kan dessa defekter skjutas upp till framtida släpp.
  • Alla brister tilldelas respektive team i QC eller ALM samtidigt under mötet. Lämpliga kommentarer läggs också till i QC / ALM.
  • Alla viktiga uppdateringar och åtgärdsposter noteras och testledningen kallar till slutet av mötet.
  • Efter avslutad triagemöte skickar Test Lead ut mötesprotokoll till alla deltagare.

Roller och ansvar

Roller och ansvar baserade på varje kategori förklaras nedan:

Testledning

  • Testledare planerar ett defekt triage-möte och skickar ut en formell mötesinbjudan till det önskade teamet.
  • Skickar felrapporten före varje triage-möte.
  • Startar mötet med de väntande åtgärdspunkterna från föregående triagemöte.
  • Diskutera varje defekt och inverkan på schemat om några funktioner blockeras på grund av defekten.
  • Hjälper till att tilldela prioritet och svårighetsgrad för varje defekt om den inte tilldelades korrekt tidigare.
  • Uppdatera QC / ALM med lämpliga kommentarer.
  • Anteckna alla uppdateringar, åtgärder, risker relaterade till en defekt etc.
  • Skickar mötesprotokoll till alla deltagare.

Utvecklingsledare / utvecklare

  • Dela uppdateringar av de åtgärdsposter som väntar från det senaste triagemötet.
  • Diskutera alla brister ur ett tekniskt perspektiv.
  • Identifiera hur mycket tid det kommer att kräva för att fixa utifrån komplexiteten i defekten och funktionaliteten.
  • Diskutera komplexiteten hos defekten och risken för eventuell fel.
  • Development Lead tilldelar fel till lämplig utvecklare efter att ha validerat all tillgänglig detaljerad information.
  • Uppdaterar felet med det förväntade upplösningsdatumet.
  • Hjälper till att identifiera grundorsaken till defekten.

Projektledare

  • Se till att om alla representanter från alla områden är tillgängliga för mötet.
  • Vid behov bjuder projektledaren Business Analyst till mötet för sin åsikt om ett specifikt fel.
  • Om defekterna inte rör sig eller om det finns någon större blockerare eskaleras den med eskaleringsprocessen.
  • Om det behövs, agerar som medlare om någon tvist eller konflikt inträffar mellan lagen och fattar nödvändigt beslut.
  • Ta bekräftelsen från utvecklingsteamet för nästa släppdatum för fasta defekter.
  • Gör det uppdaterade schemat och släppdatumet för projektet till alla team.

Ibland är det också en bra idé att involvera de andra gruppmedlemmarna i triagesamtalet så att de också kan förstå och bidra till mötet och om det behövs kan de också ge sin feedback.

Slutsats

Alla inloggade defekter bör diskuteras vid triage-mötet.

Även om en defekt avvisas, bör testteamet veta orsaken till avslag. Även om någon av defekterna inte är reproducerbar kan utvecklaren under triagemötet be testarna om realtidsinformation och de kan försöka reproducera defekten.

Defekt Triage är viktigt eftersom alla vet när defekten kommer att fixas och vara tillgänglig för omprövning. Om någon av bristerna är icke-kritiska och för att åtgärda felet kräver det stora ansträngningar från utvecklingsteamet och beslutet kommer att fattas av projektledaren.

Projektledaren bestämmer prioriteten för en sådan defekt och vid behov kan defekterna skjutas upp till nästa release.

Hoppas att du skulle ha fått en klar uppfattning om Defect Triage, Defect Triage Process och sätt att effektivt hantera Defect Triage-möten!

Rekommenderad läsning

^