defect management process
Introduktion til fejlhåndteringsproces:
Den mere fokuserede proces og test tillader mindre buggy-software på markedet.
Fejlforebyggelse er meget mere effektiv og effektiv til at reducere antallet af mangler og er også meget omkostningseffektiv til at rette de mangler, der blev fundet i den tidlige fase af softwareprocessen. De fleste af organisationerne udfører Defekt opdagelse , Fjernelse af mangler og så Procesforbedring som kollektivt er kendt som en Process for fejlhåndtering .
de primære filadgangsrettigheder i unix er:
Hvad du lærer:
- Mål for proces til defektstyring (DMP)
- Livscyklus til defektstyring
- Process for fejlhåndtering
- Konklusion
- Anbefalet læsning
Mål for proces til defektstyring (DMP)
Nedenfor er de forskellige mål for denne proces:
- Undgå defekten
- Tidlig afsløring
- Minimer virkningen
- Løsning af manglen
- Procesforbedring
Lad os først forstå, før vi udforsker processtyringsprocessen hvad er faktisk en defekt eller fejl?
Livscyklus til defektstyring
Når et system giver et andet output end det faktiske forretningskrav, dvs. når der er en afvigelse fra det faktiske eller originale forretningskrav, kan vi sige, at der er en fejl i systemet / softwaren.
Når testteamet udfører testsagerne, støder de på en situation, hvor det faktiske testresultat er forskelligt fra det forventede resultat. Denne variation kaldes en Defekt .
Dybest set er en softwarefejl en betingelse, der ikke opfylder softwarekravet. Fejlen er en fejl eller en fejl, der frembringer en uventet eller forkert opførsel i systemet.
For at kunne håndtere projekterne korrekt skal du vide, hvordan du håndterer udviklingen og frigivelsen, men sammen med det skal du også vide, hvordan du håndterer mangler.
Forestil dig, hvad vil der ske, hvis testteamet rapporterer manglerne mundtligt, og udviklingsteamet også opdaterer status for defekten mundtligt? Processen vil være mere kompliceret, da disse mangler inkluderer alle fejl som faktisk løst og fungerer som forventet, løst, men stadig ikke fungerer, afvist, udsat, og processen fortsætter.
I ovenstående tilfælde, da antallet af mangler øges og kommunikationen udføres mundtligt, vil situationen snart være meget værst. For at kunne kontrollere og håndtere manglen effektivt, har du brug for korrekt livscyklus for defekter.
Defekt livscyklus sikrer, at processen er ensartet og standardiseret. En defekt opnår forskellige tilstande i livscyklussen. Efter at en mangel er fundet, gennemgår den forskellige stadier i løbet af dens levetid, og den er almindeligt kendt som Defekt livscyklus .
Generelt starter defektets livscyklus fra det stadium, hvor defekten findes eller rejses af testteamet, og slutter, når en defekt lukkes, enten ved at sikre, at den ikke kan reproduceres eller afvises af et udviklingsteam. Antallet af stater, som en mangel gennemgår, varierer fra projekt til projekt.
Yderligere læsning:
Hvad er defekt / bug livscyklus i softwaretest? Vejledning i defekt livscyklus
Bemærk: Nedenfor cyklus adskiller sig lidt fra organisation til organisation.
Nedenfor defekte livscyklus dækker alle mulige status:
- Når testteamet finder en defekt i applikationen, hæver de defekten med status som “ NY ”.
- Når en ny defekt gennemgås af en QA-leder, og hvis manglen er gyldig, vil status for manglen være “ Åben ”Og det er klar til at blive tildelt udviklingsholdet.
- Når en QA-lead tildeler defekten til den tilsvarende udvikler, vil status for defekten blive markeret som “ Tildelt ”. En udvikler skal begynde at analysere og rette fejlen på dette tidspunkt.
- Når udvikleren føler, at manglen ikke er ægte eller gyldig, afviser udvikleren manglen. Defektens status er markeret som “ Afvist ”Og tildelt tilbage til testteamet.
- Hvis den registrerede defekt gentages to gange, eller begge de rapporterede mangler har lignende resultater og trin til at reproducere, ændres en defektstatus til “ Duplikere ”.
- Hvis der er nogle problemer eller forhindringer i den aktuelle udgivelse til løsning af en bestemt defekt, vil fejlen blive taget i de kommende udgivelser i stedet for den nuværende udgivelse, og derefter markeres den som “ Udskudt ”Eller“ Udskudt ”.
- Når en udvikler ikke er i stand til at reproducere defekten ved hjælp af de trin, der er nævnt i 'Skridt til at reproducere' af testteamet, kan udvikleren markere defekten som ' Ikke reproducerbar ” . I dette trin skal testteamet levere detaljerede reproduktionstrin til en udvikler.
- Hvis udvikleren ikke er klar over trinnene til reproduktion leveret af en QA for at reproducere defekten, kan han / hun markere den som “ Brug for mere information ”. I dette tilfælde skal testteamet give de nødvendige detaljer til udviklingsteamet.
- Hvis en mangel allerede er kendt og i øjeblikket er til stede i produktionsmiljøet, markeres manglen som “ Kendt mangel ”.
- Når en udvikler foretager de nødvendige ændringer, markeres manglen som “ Fast ”.
- Udvikleren videregiver nu manglen til testteamet for at bekræfte, så udvikleren ændrer status som “ Klar til gentest ”.
- Hvis defekten ikke har yderligere problemer, og den er korrekt verificeret, markerer testeren defekten som “ Lukket ”.
- Mens testen testes igen, hvis testeren fandt ud af, at manglen stadig er reproducerbar eller delvist rettet, ville fejlen blive markeret som “ Åbnet igen ”. Nu skal udvikleren undersøge denne fejl igen.
En velplanlagt og kontrolleret Defect Life Cycle giver det samlede antal defekter, der findes i en frigivelse eller i alle udgivelser. Denne standardiserede proces giver et klart billede af, hvordan koden blev skrevet, hvor korrekt testningen er udført, hvordan fejlen eller softwaren er frigivet osv. Dette reducerer antallet af defekter i produktionen ved at finde manglerne i testningen selve fasen.
Process for fejlhåndtering
Fejlhåndteringsprocessen forklares nedenfor detaljeret.
# 1) Forebyggelse af defekter:
Fejlforebyggelse er den bedste metode til at fjerne manglerne i den tidlige fase af testen i stedet for at finde manglerne i det senere stadium og derefter rette dem. Denne metode er også omkostningseffektiv, da omkostningerne, der kræves til afhjælpning af de mangler, der blev fundet i de tidlige stadier af testningen, er meget lave.
Det er imidlertid ikke muligt at fjerne alle manglerne, men i det mindste kan du minimere virkningen af defekten og omkostningerne ved at rette op på den.
De vigtigste trin involveret i defektforebyggelse er som følger:
- Identificer kritisk risiko : Identificer de kritiske risici i systemet, som vil påvirke mere, hvis der opstod under test eller i det senere stadium.
- Anslået forventet virkning : For hver kritisk risiko skal du beregne, hvor meget den økonomiske virkning ville have, hvis risikoen faktisk stødte.
- Minimer forventet effekt : Når du har identificeret alle kritiske risici, skal du tage de største risici, der kan være skadelige for systemet, hvis du oplever det, og forsøge at minimere eller eliminere risikoen. For risici, som ikke kan elimineres, reducerer det sandsynligheden for forekomst og dens økonomiske indvirkning.
# 2) Leveringsbaseline:
Når en leverance (system, produkt eller dokument) når sin foruddefinerede milepæl, kan du sige, at en leverance er en baseline. I denne proces flytter produktet eller den leverbare fra et trin til et andet, og når det leveres fra et trin til et andet, føres de eksisterende fejl i systemet også videre til den næste milepæl eller fase.
For eksempel, overvej et scenario med kodning, enhedstest og derefter systemtest. Hvis en udvikler udfører kodning og enhedstest, udføres systemtest af testteamet. Her er kodning og enhedstest en milepæl, og systemtest er en anden milepæl.
Så hvis udvikleren finder nogle problemer under enhedstest, kaldes den ikke som en fejl, da disse problemer identificeres inden mødet med milepælsfristen. Når kodningen og enhedstesten er afsluttet, overleverer udvikleren koden til systemtest, og så kan du sige, at koden er “Baselined” og klar til næste milepæl, her i dette tilfælde er det 'systemtest'.
Nu, hvis problemerne identificeres under test, kaldes det som defekten, da det identificeres efter afslutningen af den tidligere milepæl, dvs. kodning og enhedstest.
.net c # interviewspørgsmål
Dybest set er leverancerne udgangspunktet, når ændringerne i leverancerne er afsluttet, og alle mulige fejl identificeres og løses. Derefter videresendes den samme levering til den næste gruppe, der vil arbejde på den.
# 3) Defektopdagelse:
Det er næsten umuligt at fjerne alle defekter fra systemet og oprette et system som et fejlfrit. Men du kan identificere manglerne tidligt, før de bliver dyrere for projektet. Vi kan sige, at den opdagede defekt betyder, at den formelt bliver gjort opmærksom på udviklingsteamet, og efter analyse af det accepterede defektudviklingsteamet den også som en defekt.
Fremgangsmåden involveret i opdagelse af mangler er som følger:
- Find en defekt : Identificer fejl, før de bliver et stort problem for systemet.
- Rapporter fejl : Så snart testteamet finder en defekt, er deres ansvar at gøre udviklingsteamet opmærksom på, at der er et problem identificeret, der skal analyseres og løses.
- Bekræft fejl : Når testteamet tildeler defekten til udviklingsholdet, er det udviklingsholdets ansvar at anerkende manglen og fortsætte med at rette op på den, hvis det er en gyldig fejl.
# 4) Fejlopløsning:
I ovenstående proces har testteamet identificeret fejlen og rapporteret til udviklingsteamet. Her skal udviklingsholdet fortsætte med at løse manglen.
Trinene involveret i mangelopløsningen er som følger:
- Prioriter risikoen : Udviklingsteam analyserer manglen og prioriterer afhjælpning af manglen. Hvis en defekt har større indflydelse på systemet, gør de afhjælpningen af manglen højt prioriteret.
- Ret fejlen : Baseret på prioriteten løser udviklingsteamet fejlen, defekter med højere prioritet løses først, og defekter med lavere prioritet løses i slutningen.
- Rapporter opløsningen : Dens udviklingsteams ansvar for at sikre, at testteamet er opmærksom på, hvornår fejlene skal rettes, og hvordan fejlen er rettet, dvs. ved at ændre en af konfigurationsfilerne eller foretage nogle kodeændringer. Dette vil være nyttigt for testteamet at forstå årsagen til manglen.
# 5) Procesforbedring:
Selvom defekterne prioriteres og rettes i procesopløsningsprocessen, betyder det ikke set fra et procesperspektiv, at lavere prioritetsfejl ikke er vigtige og ikke påvirker systemet meget. Fra procesforbedringsmæssigt synspunkt er alle identificerede mangler de samme som en kritisk defekt.
Selv disse mindre defekter giver mulighed for at lære, hvordan man forbedrer processen og forhindrer forekomster af enhver defekt, der kan påvirke systemfejl i fremtiden. Identifikation af en defekt, der har en mindre indvirkning på systemet, er muligvis ikke en big deal, men forekomsterne af en sådan defekt i selve systemet er en big deal.
For at forbedre processen skal alle i projektet se tilbage og kontrollere, hvor fejlen opstod. Baseret på det kan du foretage ændringer i valideringsprocessen, basisforingsdokumentet, gennemgangsprocessen, der muligvis fanger manglerne tidligt i processen, som er billigere.
Konklusion
Defektstyringsprocessen skal følges under den samlede softwareudviklingsproces og ikke kun for specifikke test- eller udviklingsaktiviteter.
Hvis en defekt findes i testfasen, kan der rejses et spørgsmål om, at hvis defekten er fanget i denne fase, hvad så med de andre fejl, der er i live i systemet, som kan forårsage systemfejl, hvis den opstår og endnu ikke er opdaget.
Så alle processer som gennemgangsproces, statisk test, inspektion osv. Skal styrkes, og alle i projektet skal være seriøse omkring processen og bidrage, hvor det er nødvendigt. Den øverste ledelse i organisationen skal også forstå og understøtte defektstyringsprocessen.
Testmetoder, gennemgangsproces osv. Skal vælges ud fra projektmål eller organisationsproces.
Håber, at denne informative artikel om proces til defektstyring er til enorm hjælp for dig.
Anbefalet læsning
- Hvad er defektbaseret testteknik?
- Proces med mangelfrihed og måder at håndtere defekttilslutningsmøde på
- Hvad er defekt / bug livscyklus i softwaretest? Vejledning i defekt livscyklus
- Bugzilla Tutorial: Defect Management Tool Hands-on Tutorial
- Metoder og teknikker til forebyggelse af defekter
- IBM Rational Team Concert Defect Management Tool Tutorial
- Sådan reproduceres en ikke-reproducerbar defekt og gør din testindsats det værd
- Softwaretest handler om ideer (og hvordan man genererer dem)