Meny

Process for defektbehandling: Hvordan håndtere en feil effektivt

  • Hoved
  • Annen
  • Process for defektbehandling: Hvordan håndtere en feil effektivt

defect management process

Prøv Instrumentet Vårt For Å Eliminere Problemer

Introduksjon til feilhåndteringsprosess:

Jo mer fokusert prosess og testing vil tillate mindre buggy-programvare i markedet.

Feilforebygging er mye mer effektivt og effektivt for å redusere antall feil, og er også veldig kostnadseffektivt for å fikse feilene som ble funnet i den tidlige fasen av programvareprosessen. De fleste av organisasjonene driver Defektoppdagelse , Fjernelse av feil og så Prosessforbedring som kollektivt er kjent som en Process for defektbehandling .

Process for defektbehandling

en app for å spionere på en annen telefon

Hva du vil lære:

Goals of Defect Management Process (DMP)

Nedenfor er de forskjellige målene for denne prosessen:

  • Forhindre defekten
  • Tidlig oppdagelse
  • Minimer virkningen
  • Løsning av feilen
  • Prosessforbedring

Før vi utforsker feilbehandlingsprosessen, la oss først forstå hva er faktisk en feil eller feil?

Livsyklus for defektbehandling

Når et system gir en annen produksjon enn det faktiske forretningskravet, dvs. når det er et avvik fra det faktiske eller originale forretningskravet, kan vi si at det er en feil i systemet / programvaren.

Når testteamet utfører testsakene, kommer de over en situasjon der det faktiske testresultatet er forskjellig fra det forventede resultatet. Denne variasjonen blir betegnet som en Defekt .

I utgangspunktet er en programvaredefekt en tilstand som ikke oppfyller programvarekravet. Feilen er en feil eller en feil som gir en uventet eller feil oppførsel i systemet.

For å håndtere prosjektene på riktig måte, må du vite hvordan du skal håndtere utvikling og frigjøring, men sammen med det må du også vite hvordan du skal håndtere mangler.

Tenk deg, hva vil skje hvis testteamet rapporterer manglene muntlig og utviklingsteamet også oppdaterer statusen til feilen muntlig? Prosessen vil være mer komplisert ettersom disse feilene inkluderer alle feil som faktisk løst og fungerer som forventet, løst men fortsatt ikke fungerer, avvist, utsatt og prosessen fortsetter.

I det ovennevnte tilfellet, da antall mangler økes og kommunikasjonen utføres muntlig, vil situasjonen snart være den verste. For å kunne kontrollere og håndtere feilen effektivt, trenger du riktig livssyklus for defekter.

Defect Life Cycle sørger for at prosessen er ensartet og standardisert. En mangel oppnår forskjellige tilstander i livssyklusen. Etter at en mangel er funnet, går den gjennom forskjellige stadier i løpet av levetiden, og den er ofte kjent som Defekt livssyklus .

Generelt starter livssyklusen for defekter fra det stadiet når feilen blir funnet eller reist av testteamet, og slutter når en mangel lukkes, enten ved å sikre at den ikke kan reproduseres eller avvises av et utviklingsteam. Antall stater som en mangel går gjennom varierer fra prosjekt til prosjekt.

Videre lesning:

Hva er defekt / bug-livssyklus i programvaretesting? Defekt livssyklusopplæring

Merk: Nedenfor er syklusen litt forskjellig fra organisasjon til organisasjon.

Nedenfor defekte livssyklus dekker all mulig status:

Flowchart for defekt livssyklus

  • Hver gang testteamet finner en mangel i applikasjonen, løfter de feilen med status som “ NY ”.
  • Når en ny mangel blir vurdert av en kvalitetsledelse, og hvis mangelen er gyldig, vil statusen til mangelen være “ Åpen ”Og den er klar til å bli tildelt utviklingsteamet.
  • Når en kvalitetsledelse tildeler mangelen til den tilsvarende utvikleren, vil statusen til feilen bli merket som “ Tildelt ”. En utvikler bør begynne å analysere og fikse feilen på dette stadiet.
  • Når utvikleren føler at mangelen ikke er ekte eller gyldig, avviser utvikleren mangelen. Defektenes status er merket som “ Avvist ”Og tilordnet tilbake til testteamet.
  • Hvis den loggede feilen gjentas to ganger, eller begge de rapporterte feilene har lignende resultater og trinn for å reprodusere, endres en feilstatus til “ Duplisere ”.
  • Hvis det er noen problemer eller hindringer i den nåværende versjonen for å fikse en bestemt feil, vil feilen bli tatt i de kommende utgivelsene i stedet for den nåværende utgivelsen, og deretter blir den merket som “ Utsatt ”Eller“ Utsatt ”.
  • Når en utvikler ikke er i stand til å reprodusere feilen ved å følge trinnene nevnt i “Fremgangsmåte for å reprodusere” av testteamet, kan utvikleren merke feilen som “ Ikke reproduserbar ” . I dette stadiet bør testteamet gi detaljerte reproduksjonstrinn til en utvikler.
  • Hvis utvikleren ikke er klar over trinnene for reproduksjon gitt av en QA for å reprodusere feilen, kan han / hun markere den som “ Trenger mer informasjon ”. I dette tilfellet må testteamet gi de nødvendige detaljene til utviklingsteamet.
  • Hvis en mangel allerede er kjent og for tiden er tilstede i produksjonsmiljøet, blir feilen merket som “ Kjent mangel ”.
  • Når en utvikler foretar de nødvendige endringene, blir feilen merket som “ Fikset ”.
  • Utvikleren sender nå feilen til testteamet for å verifisere, så utvikleren endrer status som “ Klar for ny test ”.
  • Hvis mangelen ikke har flere problemer, og den er riktig bekreftet, markerer testeren feilen som “ Lukket ”.
  • Mens testet på nytt defekten hvis testeren fant det, er mangelen fremdeles reproduserbar eller delvis løst, vil feilen bli markert som “ Åpnet igjen ”. Nå må utvikleren se nærmere på denne feilen.

En godt planlagt og kontrollert defekt livssyklus gir det totale antallet feil funnet i en utgivelse eller i alle utgivelser. Denne standardiserte prosessen gir et klart bilde av hvordan koden ble skrevet, hvor riktig testingen har blitt utført, hvordan feilen eller programvaren har blitt frigitt osv. Dette vil redusere antall mangler i produksjonen ved å finne feilene i testingen selve fasen.

Process for defektbehandling

Process for defektbehandling

Prosessen med mangelforvaltning er forklart nedenfor i detalj.

hva er en 7z fil?

# 1) Forebygging av feil:

Feilforebygging er den beste metoden for å eliminere manglene i det tidlige stadiet av testen i stedet for å finne feilene i det senere stadiet og deretter fikse det. Denne metoden er også kostnadseffektiv ettersom kostnadene som kreves for å fikse feilene som ble funnet i de tidlige stadiene av testingen, er svært lave.

Det er imidlertid ikke mulig å fjerne alle feilene, men i det minste kan du minimere virkningen av feilen og kostnadene for å fikse det.

De viktigste trinnene som er involvert i forebygging av mangler er som følger:

  • Identifiser kritisk risiko : Identifiser de kritiske risikoene i systemet som vil påvirke mer hvis det skjedde under testing eller på et senere tidspunkt.
  • Anslå forventet innvirkning : For hver kritisk risiko, beregne hvor mye som ville ha den økonomiske effekten hvis risikoen faktisk oppstod.
  • Minimer forventet innvirkning : Når du har identifisert alle kritiske risikoer, kan du ta den største risikoen som kan være skadelig for systemet hvis du opplever det, og prøv å minimere eller eliminere risikoen. For risikoer som ikke kan elimineres, reduserer det sannsynligheten for forekomst og dens økonomiske innvirkning.

# 2) Leveringsbaseline:

Når en leveranse (system, produkt eller dokument) når sin forhåndsdefinerte milepæl, kan du si at en leveranse er en grunnlinje. I denne prosessen flytter produktet eller leveransen fra ett trinn til et annet, og når det leveres fra ett trinn til et annet, blir de eksisterende feilene i systemet også ført videre til neste milepæl eller trinn.

For eksempel, vurdere et scenario med koding, enhetstesting og deretter systemtesting. Hvis en utvikler utfører koding og enhetstesting, blir systemtesting utført av testteamet. Her er koding og enhetstesting en milepæl, og systemtesting er en annen milepæl.

Så hvis utvikleren finner noen problemer under enhetstesting, blir det ikke kalt som en mangel, siden disse problemene er identifisert før møtet med milepælfristen. Når kodingen og enhetstesten er fullført, overleverer utvikleren koden for systemtesting, og så kan du si at koden er “Baselined” og klar for neste milepæl, her, i dette tilfellet, er det 'systemtesting'.

Nå, hvis problemene blir identifisert under testing, blir det kalt som feilen som det ble identifisert etter fullføring av den tidligere milepælen, dvs. koding og enhetstesting.

I utgangspunktet er resultatene basert på når endringene i leveransene er avsluttet og alle mulige feil identifiseres og løses. Så videreføres den samme leveransen til neste gruppe som skal jobbe med den.

# 3) Feiloppdagelse:

Det er nesten umulig å fjerne alle feilene fra systemet og lage et system som feilfritt. Men du kan identifisere feilene tidlig før de blir dyrere for prosjektet. Vi kan si at den mangelen som ble oppdaget, betyr at den formelt blir gjort oppmerksom på utviklingsgruppen, og etter analyse av at mangelutviklingsteamet også godtok den som en mangel.

Fremgangsmåten som er involvert i Defect Discovery er som følger:

  • Finn en feil : Identifiser feil før de blir et stort problem for systemet.
  • Rapporter feil : Så snart testteamet finner en mangel, er deres ansvar å gjøre utviklingsteamet oppmerksom på at det er et problem identifisert som må analyseres og løses.
  • Bekjenn defekt : Når testteamet tildeler mangelen til utviklingsteamet, er det utviklingsteamets ansvar å erkjenne feilen og fortsette å fikse den hvis det er en gyldig feil.

# 4) Feiloppløsning:

I den ovennevnte prosessen har testteamet identifisert feilen og rapportert til utviklingsteamet. Nå her må utviklingsteamet fortsette for å løse mangelen.

Trinnene som er involvert i feiloppløsningen er som følger:

  • Prioriter risikoen : Utviklingsteam analyserer mangelen og prioriterer å fikse feilen. Hvis en defekt har større innvirkning på systemet, gjør de at fikseringen av feilen har høy prioritet.
  • Løs feilen : Basert på prioriteten løser utviklingsteamet feilen, feil med høyere prioritet løses først og feil med lavere prioritet løses på slutten.
  • Rapporter oppløsningen : Det er utviklingsteamets ansvar å sørge for at testteamet er klar over når feilene skal repareres, og hvordan feilen er løst, dvs. ved å endre en av konfigurasjonsfilene eller gjøre noen kodeendringer. Dette vil være nyttig for testteamet å forstå årsaken til feilen.

# 5) Prosessforbedring:

Selv om feilene i prioritetsoppløsningen prioriteres og løses, sett fra et prosessperspektiv, betyr det ikke at mangler med lavere prioritet ikke er viktige og ikke påvirker systemet mye. Fra prosessforbedringssynspunkt er alle identifiserte feil de samme som en kritisk feil.

Selv disse mindre feilene gir en mulighet til å lære hvordan du kan forbedre prosessen og forhindre forekomster av feil som kan påvirke systemfeil i fremtiden. Identifisering av en defekt som har lavere innvirkning på systemet, er kanskje ikke så viktig, men forekomsten av en slik mangel i selve systemet er en stor avtale.

For prosessforbedring, må alle i prosjektet se tilbake og sjekke hvor feilen oppsto. Basert på det kan du gjøre endringer i valideringsprosessen, basisfôringsdokument, gjennomgangsprosess som kan fange feilene tidlig i prosessen som er billigere.

Konklusjon

Defektadministrasjonsprosessen skal følges under den samlede programvareutviklingsprosessen og ikke bare for spesifikke test- eller utviklingsaktiviteter.

Hvis en feil funnet i testfasen, kan det reises et spørsmål om at hvis feilen blir fanget i denne fasen, hva med de andre feilene som er i live i systemet som kan forårsake systemfeil hvis det oppstår og ennå ikke er oppdaget.

Så alle prosesser som gjennomgangsprosess, statisk testing, inspeksjon, etc., må styrkes, og alle i prosjektet bør være seriøse om prosessen og bidra når det er nødvendig. Ledelsen i organisasjonen bør også forstå og støtte prosessen med mangelforvaltning.

Testtilnærminger, gjennomgangsprosess etc., bør velge ut fra prosjektets mål eller organisasjonsprosessen.

Håper denne informative artikkelen om Defect Management Process er til stor hjelp for deg.

Anbefalt lesing

^