Meny

Process för defekthantering: Hur man hanterar en defekt effektivt

  • Huvud
  • Övrig
  • Process för defekthantering: Hur man hanterar en defekt effektivt

defect management process

Prova Vårt Instrument För Att Eliminera Problem

Introduktion till felhanteringsprocessen:

Den mer fokuserade processen och testningen tillåter mindre buggy-programvara på marknaden.

Förebyggande av defekter är mycket mer effektivt och effektivt för att minska antalet defekter och är också mycket kostnadseffektivt för att åtgärda de fel som upptäcktes under det tidiga skedet av programvaruprocessen. De flesta organisationer bedriver Defekt upptäckt , Borttagning av defekter och då Processförbättringar som kollektivt kallas a Process för defekthantering .

Process för defekthantering

alternativ till rengöringsmedel för Windows 10

Vad du kommer att lära dig:

Process of Defect Management Process (DMP)

Nedan följer de olika målen för denna process:

  • Förhindra defekten
  • Tidig upptäckt
  • Minimera påverkan
  • Lösning av defekten
  • Processförbättringar

Låt oss först förstå innan vi utforskar defekthanteringsprocessen vad är egentligen en defekt eller fel?

Livscykel för defekthantering

När ett system ger en annan produktion än det faktiska affärsbehovet, dvs. när det finns en avvikelse från det faktiska eller ursprungliga affärsbehovet, kan vi säga att det finns en defekt i systemet / programvaran.

När testteamet utför testfallet stöter de på en situation där det faktiska testresultatet skiljer sig från det förväntade resultatet. Denna variation benämns som en Defekt .

I grund och botten är en programvarufel ett villkor som inte uppfyller programvarukravet. Defekten är ett fel eller en brist som ger ett oväntat eller felaktigt beteende i systemet.

För att hantera projekten på ett lämpligt sätt måste du veta hur du ska hantera utvecklingen och släppa, men tillsammans med det måste du också veta hur man hanterar defekter.

Föreställ dig, vad händer om testteamet rapporterar defekterna muntligt och utvecklingsteamet också uppdaterar statusen för defekten muntligt? Processen kommer att bli mer komplicerad eftersom dessa defekter inkluderar alla defekter som faktiskt fixade och fungerar som förväntat, fixade men fortfarande inte fungerar, avvisade, skjutits upp och processen fortsätter.

I det ovanstående fallet, då antalet defekter ökar och kommunikationen utförs muntligt, kommer situationen snart att bli mycket värst. För att kunna kontrollera och hantera defekten effektivt behöver du en korrekt livscykel för defekter.

Defect Life Cycle säkerställer att processen är enhetlig och standardiserad. En defekt uppnår olika tillstånd i livscykeln. Efter att en defekt har hittats går den genom olika stadier under dess livstid och den är allmänt känd som Defekt livscykel .

Generellt börjar livscykeln för defekter från det stadium då defekten upptäcks eller tas upp av testteamet och slutar när en defekt stängs antingen genom att säkerställa att den inte kan reproduceras eller avvisas av ett utvecklingsteam. Antalet stater som en defekt går igenom varierar från projekt till projekt.

Vidare läsning:

Vad är defekt / bug-livscykel vid programvarutestning? Defekt livscykelhandledning

Notera: Nedanstående cykel skiljer sig något från organisation till organisation.

Nedanstående livscykel för defekter täcker alla möjliga status:

Flödesschema för defekt livscykel

  • När testteamet hittar en defekt i applikationen höjer de defekten med status som “ NY ”.
  • När en ny defekt granskas av en QA-ledning och om defekten är giltig, skulle statusen för defekten vara “ Öppen ”Och det är redo att tilldelas utvecklingsgruppen.
  • När en QA-ledning tilldelar defekten till motsvarande utvecklare, skulle statusen för defekten markeras som “ Tilldelad ”. En utvecklare bör börja analysera och åtgärda defekten i detta skede.
  • När utvecklaren känner att defekten inte är äkta eller giltig, avvisar utvecklaren defekten. Defektens status är markerad som “ avvisade ”Och tilldelas tillbaka till testteamet.
  • Om den loggade defekten upprepas två gånger eller båda de rapporterade defekterna har liknande resultat och steg att reproducera, ändras en defektstatus till “ Duplicera ”.
  • Om det finns några problem eller hinder i den aktuella versionen för att åtgärda en viss defekt, skulle defekten tas i de kommande utgåvorna istället för den aktuella utgåvan och sedan markeras den som ” Uppskjuten ”Eller” Uppskjuten ”.
  • När en utvecklare inte kan reproducera defekten med de steg som nämns i “Steps to Reproducera” av testteamet kan utvecklaren markera defekten som “ Ej reproducerbar ” . I detta skede bör testteamet tillhandahålla detaljerade reproduceringssteg till en utvecklare.
  • Om utvecklaren inte är tydlig om stegen för att reproducera som tillhandahålls av en QA för att reproducera defekten, kan han / hon markera den som ” Behöver du mer information ”. I det här fallet måste testteamet tillhandahålla nödvändiga detaljer till utvecklingsteamet.
  • Om en defekt redan är känd och för närvarande finns i produktionsmiljön markeras defekten som ” Känd defekt ”.
  • När en utvecklare gör nödvändiga ändringar markeras defekten som ” Fast ”.
  • Utvecklaren skickar nu felet till testteamet för att verifiera, så utvecklaren ändrar status som “ Redo för omprövning ”.
  • Om defekten inte har några ytterligare problem och den är korrekt verifierad markerar testaren defekten som “ Stängd ”.
  • Medan man testade igen defekten om testaren fann att defekten fortfarande är reproducerbar eller delvis fixad skulle defekten markeras som ” Öppnade igen ”. Nu måste utvecklaren titta igen på denna defekt.

En välplanerad och kontrollerad Defect Life Cycle ger det totala antalet defekter som finns i en release eller i alla releases. Denna standardiserade process ger en tydlig bild av hur koden skrevs, hur korrekt testningen har utförts, hur defekten eller mjukvaran har släppts etc. Detta minskar antalet defekter i produktionen genom att hitta defekterna i testningen själva fasen.

Process för defekthantering

Process för defekthantering

Processen för felhantering förklaras nedan i detalj.

# 1) Förebyggande av defekter:

Förebyggande av defekter är den bästa metoden för att eliminera defekterna i det tidiga testet i stället för att hitta defekterna i det senare skedet och sedan åtgärda det. Denna metod är också kostnadseffektiv eftersom den kostnad som krävs för att åtgärda de defekter som upptäcktes i de tidiga stadierna av testningen är mycket låg.

Det är dock inte möjligt att ta bort alla defekter, men åtminstone kan du minimera påverkan av defekten och kostnaden för att åtgärda densamma.

De viktigaste stegen som är involverade i förebyggande av defekter är som följer:

c intervjufrågor och svar pdf
  • Identifiera kritisk risk : Identifiera de kritiska riskerna i systemet som kommer att påverka mer om det inträffar under testningen eller i ett senare skede.
  • Beräkna förväntad påverkan : Beräkna för varje kritisk risk hur mycket den ekonomiska effekten skulle få om risken faktiskt stött på.
  • Minimera förväntad påverkan : När du har identifierat alla kritiska risker, ta de översta riskerna som kan vara skadliga för systemet om du stöter på det och försök att minimera eller eliminera risken. För risker som inte kan elimineras minskar det sannolikheten för händelse och dess ekonomiska konsekvenser.

# 2) Leveransbaslinje:

När en leverans (system, produkt eller dokument) når sin fördefinierade milstolpe kan du säga att en leverans är en baslinje. I denna process flyttas produkten eller leveransen från ett steg till ett annat och när leveransen flyttas från ett steg till ett annat, flyttas de befintliga defekterna i systemet också vidare till nästa milstolpe eller steg.

Till exempel, överväga ett scenario med kodning, enhetstestning och sedan systemtestning. Om en utvecklare utför kodning och enhetstestning utförs systemtestning av testteamet. Här är kodning och enhetstestning en milstolpe och systemtestning är en annan milstolpe.

Så om enhetsprovningen, om utvecklaren hittar några problem, kallas det inte som en defekt eftersom dessa problem identifieras före mötesfristens milstolpe. När kodningen och enhetstestningen har slutförts överlämnar utvecklaren koden för systemtestning och sedan kan du säga att koden är 'Baslinje' och redo för nästa milstolpe, här, i det här fallet, är det 'systemtestning'.

Nu, om problemen identifieras under testning kallas det som defekten eftersom det identifieras efter avslutad tidigare milstolpe, dvs. kodning och enhetstestning.

I princip baseras leveranserna när förändringarna i leveranserna är slutgiltiga och alla möjliga defekter identifieras och åtgärdas. Då går samma leverans vidare till nästa grupp som kommer att arbeta med den.

# 3) Defektupptäckt:

Det är nästan omöjligt att ta bort alla defekter från systemet och göra ett system som ett felfritt. Men du kan identifiera bristerna tidigt innan de blir dyrare för projektet. Vi kan säga att den upptäckta defekten innebär att den formellt informeras om utvecklingsteamet och efter analys av detta accepterade också defektutvecklingsteamet det som en defekt.

Stegen involverade i Defect Discovery är som följer:

  • Hitta en defekt : Identifiera brister innan de blir ett stort problem för systemet.
  • Rapportera fel : Så snart testteamet finner en defekt är deras ansvar att göra utvecklingsgruppen medveten om att det finns en fråga som måste analyseras och åtgärdas.
  • Bekräfta defekt : När testteamet tilldelat defekten till utvecklingsteamet är det utvecklingslagets ansvar att erkänna defekten och fortsätta att åtgärda den om det är en giltig defekt.

# 4) Defektlösning:

I ovanstående process har testteamet identifierat bristen och rapporterat till utvecklingsteamet. Nu här måste utvecklingsteamet fortsätta för att lösa defekten.

Stegen som är inblandade i felupplösningen är som följer:

  • Prioritera risken : Utvecklingsteam analyserar defekten och prioriterar fixningen av defekten. Om en defekt har större inverkan på systemet gör de att fixeringen av defekten har hög prioritet.
  • Åtgärda defekten : Baserat på prioriteringen fixar utvecklingsteamet defekten, defekter med högre prioritet löses först och defekter med lägre prioritet fixas i slutet.
  • Rapportera resolutionen : Det är utvecklingsgruppens ansvar att se till att testteamet är medveten om när bristerna ska fixas och hur felet har åtgärdats, dvs genom att ändra en av konfigurationsfilerna eller göra några kodändringar. Detta kommer att vara till hjälp för testteamet att förstå orsaken till defekten.

# 5) Processförbättring:

Även om defekterna prioriteras och fixas i processupplösningsprocessen betyder det inte att defekter med lägre prioritet inte är viktiga och inte påverkar systemet mycket. Ur processförbättringssynpunkt är alla identifierade defekter samma som en kritisk defekt.

Till och med dessa mindre defekter ger möjlighet att lära sig att förbättra processen och förhindra eventuella fel som kan påverka systemfel i framtiden. Identifiering av en defekt som har lägre inverkan på systemet är kanske inte en stor sak, men förekomsten av en sådan defekt i själva systemet är en stor sak.

För processförbättring måste alla i projektet se tillbaka och kontrollera var defekten härstammar. Baserat på det kan du göra ändringar i valideringsprocessen, basfodringsdokument, granskningsprocess som kan fånga defekterna tidigt i processen som är billigare.

Slutsats

Processen för defekthantering bör följas under den övergripande programvaruutvecklingsprocessen och inte bara för specifika test- eller utvecklingsaktiviteter.

Om en defekt upptäcktes i testfasen kan en fråga tas upp att om defekten fastnar i denna fas, hur är det med de andra defekterna som finns i systemet som kan orsaka systemfel om det inträffar och ännu inte upptäcks.

Så alla processer som granskningsprocesser, statisk testning, inspektion etc. måste stärkas och alla i projektet bör vara seriösa om processen och bidra där det behövs. Ledningen i organisationen bör också förstå och stödja processen för defekthantering.

Testmetoder, granskningsprocesser etc. bör välja baserat på projektets mål eller organisationsprocessen.

Hoppas den här informativa artikeln om Defect Management Process är till stor hjälp för dig.

Rekommenderad läsning

^